Learning outcome
Identify what the agent generates and what Android owns.
PocketCommunity is a developer-event companion: ask for nearby events, inspect a venue, and prepare with an interactive checklist. The interesting output is not a paragraph describing a screen. Gemini chooses a component tree; the server validates it; AndroidX A2UI turns that description into native Compose components. Follow one request through every boundary before extending the implementation.
Real Gemini-generated UI on a physical Android phone
This is a run–understand–extend course using a completed preview, not a blank-project tutorial. You will configure your own server, inspect source and protocol messages, reproduce the app flow, fix a validator gap with failing tests, then design an independent extension. Expect several focused sessions. The app is a live-agent preview: production hosting, durable conversations and streaming transport are outside its current scope.
Separate the responsibilities
| Layer | Owns | Does not prove |
|---|---|---|
| Gemini | Assistant text and component composition | That event facts are correct |
| Companion server | Published event context, validation, A2UI envelopes | That every valid screen is usable |
| AndroidX A2UI | Protocol parsing, native catalog rendering, bound state | That an LLM produced a message |
| App shell and ViewModel | Navigation-free conversation, endpoint, jobs, action authorization | That a checked item verifies registration |
A2UI is independent of Gemini credentials. A developer-authored message can exercise a renderer without a key. This app deliberately requires a live agent endpoint at runtime; deterministic messages exist only in instrumentation tests. Missing configuration shows setup. A model error never silently substitutes scripted event cards.
Evidence you can rely on
At this revision, debug/release builds, 2 JVM tests, 3 physical-device UI tests and 10 Node tests passed. Live Gemini event, venue, preparation and checkbox-aware refinement ran on a OnePlus DN2101 with Android 13. These are baseline results, not a guarantee for all model projects or devices.
Request, server validation and native rendering.
Official reference
- Android Compose A2UI guide — Official protocol and renderer overview; sample behavior is documented separately.
Practice and checkpoint
Explain why a screenshot alone cannot prove inference. Your answer should distinguish model calls, server wrapping, real native rendering and test fixtures. Create a learning log recording the commit, device, model name, checks and unresolved limitations. Do not record your API key.
Source and next steps
- Pinned implementation — The exact app and server revision used by this lesson.