# Building Agent-Generated UIs with A2UI in Android

How PocketCommunity bridges AI composition with native Jetpack Compose components

- **Source:** [ProAndroidDev - Medium](https://brifing.si/source/d9553fa9-7b72-4b9b-bc73-c6bf9a40dd5f)
- **Published:** 2026-09-27
- **Topic:** [Software & Engineering](https://brifing.si/c/engineering)
- **Original article:** <https://proandroiddev.com/from-a-prompt-to-native-compose-ui-building-pocketcommunity-with-a2ui-95a3643baed8?source=rss----c72404660798---4>
- **On Brifing:** https://brifing.si/s/67d45f2e-8510-4071-97c1-0659f040bedd

## AI-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.

## Protocol 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.

## Surface 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.

## Component 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.

## State 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.

## Validation 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.

## Request 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.

## Context 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.

## Testing 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.

## Current 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.

## Implementation 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.

## Sources covering this story

- https://proandroiddev.com/from-a-prompt-to-native-compose-ui-building-pocketcommunity-with-a2ui-95a3643baed8?source=rss----c72404660798---4 — 

---

_Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._
