Explain without opening the solution
Answer these questions in your evidence log, then compare with the answer guide below. Use the pinned code rather than generic Android vocabulary.
- Which operation needs network access and which is intended to run locally?
- Why can a verified model still fail when a conversation is created?
- Why does the downloader truncate on 200 after requesting a Range?
- Why are draft text and accepted scenes stored separately?
- Does cancelling a Job guarantee that native generation has stopped?
- Is the 4,500-character selection budget equal to the model context window?
- What survives rotation versus process death?
- What does the emulator's 128 MiB limit actually measure?
- What proves offline inference rather than offline history viewing?
- What evidence is still missing before calling this a completed AI sample?
Answer guide
- Initial model acquisition uses the network; the intended inference path uses private files and local LiteRT-LM. There is no cloud fallback.
- Integrity checks establish exact bytes, not supported operators, memory allocations or device backend compatibility.
- A 200 response is a complete response; appending it after a saved prefix would duplicate bytes and corrupt the assembled file.
- Only explicit acceptance makes a draft part of story continuity. Stopped or rejected prose must not silently influence later scenes.
- No. The adapter requests SDK cancellation and waits for terminal callback before close. Real-device termination behavior remains to be checked.
- No. It limits selected scene text/actions; additional instructions, images and output occupy context too.
- Rotation retains ViewModel ownership. Process death destroys it and native state; Room restores persisted story data, with possible loss since the last checkpoint.
- One GPU buffer allocation, independent of free disk and different from total RAM.
- A newly generated scene after installing weights and disabling network, with observed output and runtime evidence.
- Successful real output, native stop/retry, offline inference, quality evaluation and device-specific performance checks remain outstanding in the author baseline.
Completion rubric
Award yourself one point for each correct explanation. Revisit the associated lesson for every missed answer. Then check the practical evidence: pinned build, downloader failure test, red/green context extension, saved-story recovery, diagnosis matrix and capstone tests. A score alone cannot replace those artifacts.
You may mark the learning material complete with a clearly documented blocked hardware track. Do not convert a self-reported completion certificate into a claim that Google certified the app, that a particular phone is supported, or that native inference passed. Keep author evidence and your own evidence separate.
What comes next
With working hardware, complete the live quality matrix and replace unverified rows with measured results. Future learning extensions can investigate CPU vision, retained engines, PDF export or retrieval, each with explicit scope and tests. Return to the codelab to reproduce the implementation exercise or the published preview to compare your changes.