androidengineers.Book a session LEARN WITH A CLEAR DIRECTION
Learn agent-generated native Compose UI through a real Gemini event companion: catalogs, surfaces, bindings, action feedback, validation and device evaluation.
Follow one source-pinned app from private Gemini server setup to native UI rendering and checkbox-aware follow-ups. Read the protocol and architecture, implement a red-to-green validator improvement, evaluate real responses, and finish with an independent state-identity capstone. This is a complete learning path for a verified live-agent preview, not a production hosting course.
Work through four stages over several focused sessions. Time varies with toolchain downloads, model access and prior Android experience.
YOUR PROGRESSION
Complete the labs and keep the evidence. Use each checkpoint to decide whether to move forward or revisit a skill.
Units 1–3
Reproduce the live baseline and read surface messages
Evidence: Build log, connection evidence and component graph
Go to this stage’s final module →Units 4–7
Trace catalogs, agent context, ownership and checkbox feedback
Evidence: Real action trace and preserved checkbox state
Go to this stage’s final module →Units 8–10
Validate generated UI and prove a policy change with tests
Evidence: Red/green tests and failure-recovery log
Go to this stage’s final module →Units 11–12
Assess live quality and build an independent extension
Evidence: Evaluation matrix, capstone diff and scored assessment
Go to this stage’s final module →THE CURRICULUM
12 lessons across 12 modules. Open a module to explore its lessons and practical work.
Identify what the agent generates and what Android owns.
Ready to move on when: 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.
Clone the exact source, configure the private server and connect a phone.
Ready to move on when: Ask for Android events in Bengaluru, request a venue, and then a checklist. Save the build result and a screenshot without credentials. Stop the server and send another request: the app must show a retryable error rather than a new event card. Restart the server and retry. Record actual results; a working /health response is insufficient.
Read A2UI messages as a component graph and a separate data model.
Ready to move on when: Draw the four-node graph and predict the result of replacing pack.value.path with /missing. Then explain the difference between an absent bound value and a missing child ID. Verify that the baseline server initializes accepted checkbox paths and rejects missing child references.
Understand the contract between allowed JSON components and Compose.
Ready to move on when: Identify two changes that require app code and two that Gemini can choose within the existing contract. Expected: a new native media renderer and local styling require app code; a different heading and a permitted Card/Column composition can come from the model. Inspect a generated screen at large font size and record one UX risk.
Separate trusted instructions, public event data and provider credentials.
Ready to move on when: Trace where the Gemini key enters an HTTP header and show that it never appears in AgentRequest. Ask for an unsupported action such as buying a ticket: the app must not claim a purchase. Compare event title, date, venue and sponsored label against the feed; record mismatches instead of treating protocol validity as factual accuracy.
Follow state, concurrency and lifecycle boundaries through the Android client.
Ready to move on when: Trace two quick Send taps and a New conversation action while the network is slow. Explain which guards prevent duplicate requests and stale appends. Propose a repository change that connects coroutine cancellation to OkHttp Call.cancel(), but keep it separate from the tested baseline unless you implement and verify it.
Send native interactions back to the agent without inventing side effects.
Ready to move on when: Check one item, press Update my plan and inspect the new surface: both progress text and the checkbox must reflect completion. Reorder a fixture checklist with the same labels and verify preservation. Rename the label and predict false. Explain why stable domain item IDs would be a stronger production identity than label matching.
Treat model output as untrusted structure before it reaches native rendering.
Ready to move on when: Read the 10 server tests and classify each as structural, action or state validation. Construct a missing-child example and a fabricated-event action; both should throw. Then create two different checkbox IDs bound to /ready0 and explain why the baseline currently accepts them.
Implement a real red-to-green policy change for independent checklist items.
Ready to move on when: Keep the failing output, implementation diff and passing output in your learning log. Add a third test calling validateSurface twice with /ready0 to prove the set is scoped per request. Explain why changing component IDs would not fix shared binding state.
Diagnose a failed request without hiding it behind a fake result.
Ready to move on when: Run two failure drills and one recovery on your own debug build. Record the exact error and whether the composer becomes usable. Distinguish a repository failure test from a live provider failure: they exercise different boundaries and should be reported separately.
Collect evidence for software behavior, generated facts and mobile usability.
Ready to move on when: Produce a small evidence report with separate columns for automated tests, live inference and UX. Block release if the app invents registration success, leaks a key, silently uses fixtures or routes an action to the wrong event. Record remaining alpha SDK and production limitations even when the baseline flow passes.
Demonstrate understanding with an independent extension and scored evidence.
Ready to move on when: Submit your source diff, red/green test logs, device/model evidence and short evaluation report. Explain one remaining limitation you would prioritize next and the test that would demonstrate its improvement.
PROVE YOUR SKILLS
Use the final review rubric to identify gaps. Lesson completion tracks study progress; readiness comes from independently demonstrating the work.
Open the portfolio review rubric →