Challenge 3: Why Gradle Sync Genuinely Takes Real Time — Solution Walkthrough

Why this is a real process, not an instant refresh:

Per this chapter's own material, Gradle Sync doesn't just re-read
files already sitting on disk the way opening a file does. It actually
runs Gradle itself, which has to resolve every declared dependency
across the whole project, check whether each one is already cached
locally, and download any that aren't — a genuine network operation
that depends on file sizes and connection speed, not something that
completes instantly regardless of circumstances.

What else it's doing beyond downloading:

Beyond fetching new libraries, Gradle Sync also regenerates the IDE's
own internal understanding of the project's entire module and
dependency graph — the structural information code completion,
error-checking, and navigation all rely on being accurate. Rebuilding
that internal model is real computational work, separate from, and in
addition to, any network activity involved in fetching dependencies.

Why this explains variable sync times:

A sync after adding a brand-new dependency for the first time
genuinely has more real work to do (downloading something not yet
cached) than a sync after a small code-only change with no dependency
changes at all — which is why sync times can vary noticeably rather
than being a fixed, predictable duration every time.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that Gradle Sync's own real network-and-disk
mechanics from this chapter are understood well enough to explain WHY
it takes time, not just that it sometimes does.