Deliver a small, complete improvement
Start after the six lessons, practices and the codelab's chunk-size exercise. Keep the working voice baseline intact. Your capstone is a source change with observable behavior and an evaluation report, not a collection of screenshots or a speculative architecture diagram.
Choose one extension: add a fourth local recipe with correct selection, steps, context and progress; or add user-controlled transcript clearing with a test proving that clearing text does not stop or restart voice. Neither requires camera tools or a server. Keep your change independent of the teaching exercise so you demonstrate transfer rather than copying the provided solution.
Option A: a fourth recipe
Use a unique stable ID, nonempty ingredients, at least three steps and clear instructions. Inspect the UI before assuming it lists arbitrary recipes: the baseline highlights one recipe and explicitly selects the other two. Update that presentation deliberately so the new recipe is discoverable without dropping an existing one. Supply an original or licensed image only if the UI requires one and record its provenance.
Verify first/last step bounds, finish behavior, progress after leaving/reopening, and the recipe/current-step context passed to Gemini. Manual navigation remains authoritative; do not introduce automatic model-driven step changes as an accidental part of this extension. Recipe content should avoid unsupported dietary or safety guarantees.
Option B: clear transcript
Add a clear action with an accessible label and a state update owned by the appropriate controller. Define whether new fragments appear immediately afterward and what happens if the action is pressed while connecting. Keep the socket, microphone and playback unchanged. Use a fake connection or controller test to prove resource counts do not change. Do not add persistence to solve a text-clearing feature.
Acceptance criteria
- The selected extension is reachable and understandable in the UI.
- New behavior has a focused automated test and existing tests still pass.
- Manual cooking works without a key or network.
- Backgrounding never silently resumes capture on return.
- Debug credentials and generated build files stay outside the submitted diff.
- An evaluation report separates local tests, device observations and live model results.
- The README or change note includes reproduction steps and limitations.
./gradlew :app:testDebugUnitTest :app:lintDebug :app:assembleDebug :app:assembleRelease
# On an isolated configured test device:
./gradlew :app:connectedDebugAndroidTest
Submit a reviewable result
Include your baseline revision and final commit, a short diff explanation, build/test output, three app screenshots or a brief recording, and the task-evaluation sheet. Document which device/model/route was used. If you could not run live voice, mark that part unverified rather than substituting a fake.
The instrumented suite resets recipe progress in its test app, so use an isolated emulator. Do not run a destructive test against a user's saved personal data. A clean-source walkthrough should start without project build outputs or a checked-in SDK path; an existing dependency cache is acceptable if disclosed.
Review rubric
Score behavior and correctness out of 8, ownership and lifecycle out of 4, meaningful tests out of 4, and documentation/evaluation out of 4. A strong submission earns at least 16/20 with no missing core acceptance criterion. This is a self-review rubric, not an external qualification. Camera, tools and a token service are optional later projects; they do not compensate for a broken core path.
Course study guide · Hands-on codelab · Pinned Android source