Challenge 2: Skipping Real-Device Testing Based on Emulator Performance — Solution Walkthrough

The risk in this decision:

Per this chapter's own warning box, the emulator typically runs on the
development machine's own far more powerful CPU and RAM than an actual
phone has, and it doesn't replicate real-world conditions like thermal
throttling under sustained use or memory pressure from other apps
running in the background. Smooth emulator performance genuinely does
not guarantee smooth performance on real hardware, since the emulator
simply isn't subject to the same physical and resource constraints a
real device is.

What could go wrong specifically:

The app could perform noticeably worse, stutter, or even crash under
real-world conditions the emulator never exposed it to — a real
device's own CPU throttling down after sustained heavy use, or other
apps competing for the same limited RAM, are exactly the kinds of
conditions that don't show up in an emulator's own more generous
resource environment.

Why this isn't excessive caution:

Per this chapter's own material, testing on at least one real device
before release is described as standard, necessary practice — not an
optional extra step. Treating emulator-only testing as sufficient
skips a category of real, common issue that specifically only shows up
under real hardware constraints.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise directly applies this chapter's own warning box to a
realistic team decision, correctly identifying specific real-world
conditions (thermal throttling, background memory pressure) the
emulator doesn't replicate, rather than a vague "testing more is
always better" answer.