Building Agent-Generated UIs with A2UI in Android
How PocketCommunity bridges AI composition with native Jetpack Compose components
1AI-composed UI architecture
PocketCommunity demonstrates how Gemini generates interfaces using A2UI protocol without direct Kotlin output. The system separates responsibilities: Gemini produces JSON compositions, a server validates them, and Android renders using native Jetpack Compose components. This three-layer architecture maintains app ownership while enabling AI-assisted UI generation. The implementation specifically handles developer event preparation checklists with interactive elements.
2Protocol vs implementation
A2UI operates as a rendering protocol, not an inference provider, requiring no Gemini API key for basic functionality. The sample app uses Gemini as a producer but could work with any compliant message source. The renderer processes developer-authored messages identically to AI-generated ones. This separation allows teams to prototype AI features without committing to specific models or vendors during early development phases.
3Surface state management
PocketCommunity implements A2UI's three-message pattern for stateful surfaces: createSurface identifies components, updateDataModel supplies initial values, and updateComponents defines the UI tree. Checkbox interactions demonstrate how bound values change without server roundtrips. The implementation uses specification v0.9 with Material basic catalog, deliberately matching pinned dependency versions rather than documentation headings.
4Component catalog constraints
The server restricts components to eight types including Text, Column, and CheckBox - a subset of A2UI's full vocabulary. Android's communityCatalog() implements these with custom constraints: images only load bundled assets, URL openers block direct navigation. This maintains app security while allowing AI composition within defined boundaries. Generated interfaces can't create arbitrary remote requests or navigation.
5State preservation challenges
Initial testing revealed a critical state management bug where checkbox values reset during refinement. The fix involved mapping previous component states to new surfaces by exact label matching. This application-level solution handles basic persistence without A2UI protocol changes. The limitation becomes apparent when labels change or duplicate - a deliberate tradeoff for the preview implementation.
6Validation layers
The system implements multiple validation stages: server checks component syntax and references, Android verifies message envelopes, and business logic confirms event IDs against source data. These layers address different concerns than factual accuracy - a valid Text component could still display incorrect information. The sample includes 10 Node tests and 5 Android instrumentation tests for validation logic.
7Request ownership patterns
ViewModel manages conversation state and request generation counters to prevent stale responses. While coroutine cancellation handles local request abandonment, it doesn't guarantee immediate transport termination. The implementation uses synchronous OkHttp calls on Dispatchers.IO, demonstrating how network cancellation remains a separate concern from UI state management.
8Context forwarding mechanics
For state-aware interactions like checklist updates, PocketCommunity forwards component trees, surface snapshots, and action context alongside conversation history. This provides the agent with actual UI state rather than just chat text. The implementation samples retain up to 12 text turns, 3 component trees, and 6 value snapshots - practical limits rather than complete conversation memory systems.
9Testing strategy
The published checkpoint passed debug/release builds, JVM tests, instrumentation tests on physical devices, and live Gemini exercises. Notably, UI tests use fake repositories with real renderers, separating rendering correctness from inference reliability. This distinction proves particularly valuable for AI-integrated features where either layer might fail independently.
10Current limitations
As a learning preview, PocketCommunity lacks production features like process death recovery, user authentication, or rate limiting. The companion service binds to localhost without cloud deployment. The A2UI dependencies remain alpha versions, intentionally pinned together. These constraints make the sample ideal for education but require significant expansion for production use.
11Implementation roadmap
The project documentation outlines 12 learning units covering catalogs, protocol state, validation, and a capstone project. Developers can follow the codelab to implement validator improvements or explore related samples in the Android+AI Cookbook. The emphasis remains on observable interactions - how user changes propagate through AI context to subsequent native screens.
Original article: ProAndroidDev - Medium — Building Agent-Generated UIs with A2UI in Android