On this page · 12 sections
- What is A2UI?
- Why A2UI matters to Android developers
- How A2UI works with Jetpack Compose
- The AndroidX A2UI libraries
- How to add A2UI to an Android project
- Is A2UI secure?
- A2UI vs traditional Jetpack Compose development
- A2UI protocol status vs AndroidX library status
- What this means for AI-powered Android apps
- Conclusion
- How eCorpIT can help
- References
Summary. On 23 September 2026 Google released the first AndroidX libraries for A2UI, its open protocol that lets an AI agent describe an interface as data while the app renders it with its own components. There are three library groups, all at 1.0.0-alpha01: androidx.a2ui for message parsing and validation, androidx.a2ui.compose for rendering in Jetpack Compose, and androidx.compose.material3:material3-a2ui, a ready-made catalog built from Material 3 components. The Compose renderer supports version 0.9.1 of the A2UI specification, which the A2UI project lists as its current production release, with version 1.0 still a candidate.
AI-powered apps are moving beyond text. Instead of replying only with paragraphs, an AI assistant can show a form, a product card, a selection menu or another interactive view built for the user's request.
A2UI, short for Agent-to-UI, is designed to make that possible across platforms. With the new AndroidX libraries, an Android app can take an agent's interface description and turn it into native Compose UI, using components the app has approved in advance.
This article covers what A2UI is, how it works with Jetpack Compose, what each AndroidX library does, and what to know before you experiment with it.
About this article. This guide is based on the A2UI project's documentation, the AndroidX release notes for the A2UI, A2UI Compose and Compose Material 3 libraries, and Google's Jetpack Compose A2UI guides, as checked on 17 October 2026. The libraries are alpha releases and their APIs will change. Researched with AI assistance and reviewed by our editorial team.
What is A2UI?
A2UI is an open, declarative protocol that lets AI agents describe interactive user interfaces for a client app to render. Google created it, with contributions from CopilotKit and the open-source community, and publishes it under the Apache 2.0 licence.
The problem it solves is easy to see. A text-only assistant needs several turns to collect the details for a simple task. With a generative UI approach, the assistant can present an interface that lets the user complete the task directly.
Say a user asks: "Help me schedule a meeting with my team tomorrow afternoon." Instead of a string of follow-up questions, an agent could send an interface with:
- A date selector.
- Available time slots.
- A participant selector.
- A confirmation button.
The user works with those components, and the app sends the resulting actions back to the agent.
The agent sends JSON messages that describe the components and their data; it does not send code. Those messages can travel over any transport, such as A2A, AG-UI, server-sent events or WebSockets, and the client renders them with its own native widgets. The A2UI project lists renderers for Angular, Flutter, Lit and other frameworks, and names Jetpack Compose among the mobile targets. Our guide to the Flutter GenUI SDK and A2UI covers the Flutter side.
Why A2UI matters to Android developers
The AndroidX libraries give Android developers a documented, Google-maintained route for adding A2UI to a Compose app. Google lists the Jetpack Compose A2UI renderer among the new features on its AI on Android page, as a way for agents to render UIs built from native Compose and Material 3 components. Instead of building every AI-driven screen by hand, you supply a catalog of approved components and let the renderer turn agent messages into native UI.
Consider a shopping assistant. A user asks for a laptop suited to programming within a budget. The agent returns an interface description with a product comparison, prices and selection actions, and the app renders it with its own Compose components and design system.
The same pattern could support:
- Booking and scheduling forms.
- Product comparisons.
- Customer support flows.
- Data summaries and interactive charts.
- Personalised onboarding.
- AI-assisted search and filtering.
These are possible uses, not features that arrive out of the box. What you get depends on the agent, the components in your catalog and the renderer your app implements.
How A2UI works with Jetpack Compose
A2UI separates the description of an interface from the code that renders it. At a high level:
- A user sends a request to an AI agent.
- The agent generates A2UI messages describing the interface and its data.
- The app receives those messages.
- The A2UI libraries parse and validate the messages against the catalog.
- The Compose renderer maps the components to native Compose UI.
- The user interacts with the rendered interface.
- The app sends the relevant action back to the agent, which can update the interface.
The key point is that the agent describes the UI, and the app decides how it renders.
Google's guide adds two details that matter in practice. Updates use the Compose snapshot state system, so only the components affected by a streamed update or a user interaction recompose. And the data layer validates each payload against its schema, so a malformed message from the agent shows an error state instead of corrupting the screen, with the error reported back to the agent so it can correct itself.
The app still needs its own networking, action handling, state management and security controls. A2UI provides the protocol and rendering building blocks, not a complete AI backend.
The AndroidX A2UI libraries
The release covers three groups with distinct roles.
Core protocol: androidx.a2ui
The core group has two artifacts, a2ui-engine and a2ui-model. Google's release notes describe them as handling protocol message parsing and schema validation, and providing the foundational APIs for building renderers. This layer also deals with protocol-version-specific parsing.
Compose rendering: androidx.a2ui.compose
The Compose group has three artifacts: compose-runtime, compose-ui and compose-ui-testing. The runtime handles the fine-grained reactive updates. The UI layer provides the pattern for defining catalogs of components that map the protocol's JSON schemas to your own Compose UI, including two-way data bindings that send values back to the agent. The testing artifact lets you test components and whole surfaces with a test controller and real message processors.
Material 3 Basic Catalog: material3-a2ui
The A2UI project defines a standard Basic Catalog of common components, such as buttons, text, text fields, cards and lists. The androidx.compose.material3:material3-a2ui library implements that catalog with Material 3 components, so you can render agent UI without writing a catalog first. The libraries deliberately leave out image loading and media playback: you plug in your own image loader, video and audio players, a URL opener and a message formatter, so Coil or Media3 code you already have can be reused.
How to add A2UI to an Android project
Step 1: configure the Google Maven repository
Make sure your project can reach Google's Maven repository, as the release notes require.
Step 2: add the dependencies
For a Kotlin Gradle build file, the release notes list these coordinates for 1.0.0-alpha01. The Material 3 catalog is optional if you build your own catalog.
dependencies {
implementation("androidx.a2ui:a2ui-engine:1.0.0-alpha01")
implementation("androidx.a2ui:a2ui-model:1.0.0-alpha01")
implementation("androidx.a2ui.compose:compose-runtime:1.0.0-alpha01")
implementation("androidx.a2ui.compose:compose-ui:1.0.0-alpha01")
// Optional: the Basic Catalog built with Material 3 components
implementation("androidx.compose.material3:material3-a2ui:1.0.0-alpha01")
androidTestImplementation("androidx.a2ui.compose:compose-ui-testing:1.0.0-alpha01")
}
Check the release notes for newer versions before you use these in a project.
Step 3: choose a component catalog
Every A2UI surface is driven by a catalog: a contract that lists the components, property schemas and client functions the agent may use. The agent can build interfaces only from what the catalog declares. You can start with the Basic Catalog, build a custom catalog for your own design system, or combine the two by overriding individual components. For a production app with its own design system, a custom catalog keeps the agent inside your visual language.
Step 4: connect the agent and the renderer
Your app needs a channel that receives A2UI messages from the agent and sends user actions back. Google's guide shows a pattern that lives in a ViewModel: an A2uiMessageParser and an A2uiMessageProcessor take each incoming message, expose the active surfaces as state, and publish outbound events for the agent. An A2uiSurface composable then renders each surface, with its own loading, error and animated transition states. The protocol does not require a particular network stack, and these are alpha APIs, so expect names to change.
Step 5: test the rendered interface
Check that messages parse correctly, components render as expected, data updates propagate and user actions reach the right handlers. The compose-ui-testing artifact supports both isolated component tests and full surface tests.
Is A2UI secure?
Security is one of A2UI's design principles. Instead of running UI code produced by a model, the agent sends a declarative description, and the client renders only components from its own trusted catalog. That removes the risk of executing model-generated code inside your app.
Declarative UI does not make the whole app secure, though. You still need to validate incoming data, authorise actions on the backend, protect sensitive information and make sure an agent cannot trigger privileged operations without proper checks.
An AI-generated confirmation button, for example, is not authorisation to transfer money, delete an account or change sensitive records. The backend must validate the requested action and the user's permissions on its own. Text that reaches the agent from outside sources can also carry prompt injection, so treat agent output as untrusted input; our article on prompt injection controls for agents lists the defences.
A2UI gives you a useful boundary, and security still depends on how the whole system is built.
A2UI vs traditional Jetpack Compose development
A2UI and Jetpack Compose solve different problems. Compose is Android's declarative UI toolkit. A2UI is a protocol that lets an agent describe an interface for a compatible renderer to build.
| Aspect | Traditional Jetpack Compose | A2UI with Jetpack Compose |
|---|---|---|
| UI definition | Developers define UI in Compose code | An agent sends a declarative UI description |
| Rendering | Compose renders the app's UI | The A2UI renderer maps catalog components to Compose |
| Dynamic interfaces | Developers implement UI logic and state changes | Agents can update the interface through protocol messages |
| Design control | The app controls its Compose code | The app still controls its component catalog and rendering |
| Best fit | Conventional, developer-defined screens | Agent-driven interfaces that change with context |
A2UI does not replace Jetpack Compose; it builds on it. A production app can use both: conventional Compose screens for core navigation and predictable flows, and A2UI surfaces for selected AI-assisted experiences.
A2UI protocol status vs AndroidX library status
Keep the protocol's maturity separate from the libraries'. The A2UI project lists version 0.9.1 as its current production release and version 1.0 as a release candidate. The AndroidX libraries are at 1.0.0-alpha01, released on 23 September 2026, and the Compose renderer supports specification 0.9.1.
These are different numbering schemes. An AndroidX version of 1.0.0-alpha01 does not mean the protocol has reached 1.0.
Google's guide also explains how the libraries will handle change. Once the public API reaches a stable 1.0.0, AndroidX binary compatibility rules forbid breaking changes. New protocol capabilities arrive as additions with default implementations. Incompatible protocol changes are handled by deprecating old interfaces and adding new ones alongside them. Your app can declare several supported catalog versions, which the agent learns when the two sides negotiate capabilities.
Before you adopt the libraries, review the specification, the release notes, API stability and your compatibility needs, and decide whether you are experimenting, prototyping or building for production.
What this means for AI-powered Android apps
A2UI points to agents that do more than write text: they propose task-specific interfaces that help users finish things in fewer steps. For Android developers, the opportunity is to combine the flexibility of AI with the consistency of native components.
Picture a finance app that shows a spending breakdown when a user asks about monthly expenses, or a travel assistant that produces an editable itinerary. In each case the agent describes the interface, and the app controls how it looks, which components exist and which actions are allowed. A2UI also sits alongside Android's other agent work, such as AppFunctions, which lets agents call an app's functions; our guide to AI agents in Android app development covers that side.
The hard part will be making these interfaces reliable, accessible, understandable and consistent with the product's design system. A valid UI description is only the start: clear action semantics, error handling, data validation and careful interaction design matter as much.
Conclusion
The A2UI libraries in AndroidX give developers a supported way to explore AI-driven interfaces in Jetpack Compose. Instead of asking a model to generate and run UI code, an agent describes an interface as structured data, and the app maps it to approved native components.
That suits context-aware forms, interactive assistants, personalised workflows and other screens that need to adapt to a request. For now, the practical step is to learn the protocol, experiment with the alpha libraries, and prove the whole agent-to-renderer flow before you rely on it in production.
How eCorpIT can help
eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our Android team builds Jetpack Compose apps and can prototype an A2UI surface against your own design system, with a custom component catalog and the backend checks that agent-driven actions need, through our AI mobile app development services. Talk to us at /contact-us/.
Last updated: 17 October 2026.
