Capstone: A Complete Workflow From New Project to a Debugged, Profiled Build

Every prior chapter covered one specific tool in isolation. This capstone follows one realistic session end to end — a bug report comes in, and every tool this course covered gets used in the order a real investigation would actually use it.

The Scenario

A bug report arrives: "Tapping Submit sometimes does nothing." No crash, no error dialog — just silence, some of the time.

Step 1 — Starting From a Gradle-Synced Project (Chapter 2)

Opening the existing project, the first check is simply confirming Gradle Sync completed cleanly — no red banner, no unresolved-symbol warnings anywhere obviously related to this feature. Per Chapter 2's own warning box, ruling this out first avoids chasing a phantom "bug" that's actually just a missed sync.

Step 2 — Reproducing the Bug in the Layout Editor First (Chapter 3)

Before assuming this is a logic bug, the submit button's own layout is checked in Blueprint view — confirming it isn't, say, another invisible view silently overlapping it and intercepting the tap. The constraints look correct; this rules out a layout-level explanation and points the investigation toward the button's own click-handling code instead.

Step 3 — Finding the Bug with Logcat and a Breakpoint (Chapter 4)

Logcat shows nothing at Error level when the bug reproduces — no crash, no exception. A breakpoint set directly on the submit button's click handler, followed by stepping through with Step Into, reveals the real cause: a null check on a form field silently returns early under one specific condition, swallowing the tap with no log output and no visible feedback to the user at all.

Step 4 — Confirming There's No Performance Angle (Chapter 5)

Before finalizing this as a straightforward logic bug, a quick Profiler check — per Chapter 5's own caution against assuming which resource is responsible before checking — rules out a slow background network call disguising itself as "the button does nothing." Nothing unusual appears in CPU, Memory, or Network; this confirms the null-check logic really is the entire story, not a symptom of something else.

Step 5 — Verifying the Fix on a Real Device (Chapter 6)

The fix — handling the null case explicitly with visible user feedback instead of silently returning — is verified on the emulator first for fast iteration, then confirmed again on a real physical device before being considered done, per Chapter 6's own warning that emulator behavior doesn't always guarantee identical real-device behavior.

Step 6 — Letting Lint Confirm No New Issues (Chapter 7)

Running Analyze > Inspect Code on the changed file confirms the fix introduced no new lint warnings. While already in this area of the code, a poorly-named local variable is cleaned up with Rename — a small, safe improvement made possible exactly because it's already the focus of attention, not a separate detour.

Step 7 — Committing the Fix Through the IDE (Chapter 8)

The Commit tool window's own diff view confirms exactly what changed before committing — just the intended fix, nothing accidental swept in alongside it. A clear commit message describing the actual bug and fix, then Commit and Push, closes out the session.

Hands-On Exercises