Challenge 2: New Classes Showing "Cannot Resolve Symbol" After a Pull — Solution Walkthrough

The likely cause:

Per this chapter's own warning box, this is almost certainly a missed
Gradle Sync, not a broken IDE. Pulling the teammate's commits brought
in the updated app/build.gradle with the new dependency already
declared in the file — but simply having those lines present in the
file isn't the same as Gradle actually having resolved and downloaded
that dependency and updated the IDE's own internal project
understanding. Until a sync happens, the new library's classes
genuinely aren't available to the IDE yet, so it correctly reports
them as unresolved.

Why this isn't a sign the IDE itself is broken:

The dependency lines exist in the file, but per this chapter's own
"What Gradle Sync Is Actually Doing" section, only an actual sync
resolves dependencies, downloads anything not already cached, and
rebuilds the dependency graph the editor relies on for code
completion and resolution. Simply having pulled the file change
doesn't trigger any of that automatically unless Android Studio's own
sync-prompt banner appeared and was acted on — and it's easy to miss
or dismiss that banner without noticing.

The fix:

Trigger Gradle Sync manually (the toolbar's own Sync Now action),
rather than assuming the IDE needs to be restarted or reinstalled.
Once the sync completes, the new dependency's classes should resolve
normally.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies this chapter's own warning box to a very
realistic, common team scenario — pulling a teammate's dependency
change — correctly identifying the missed-sync explanation over an
assumption of IDE malfunction.