Three ways AI agents will call your Android app
Preface
(Image)
Tell Gemini "Order a latte with XX App" and the Agent completes the entire flow inside your app.
Your Android app has three ways to be called by an Agent, each with different integration costs, capability limits, and risks.
Table of Contents
- 1: What is the Android Intelligent System?
- 2: How to choose among the three paths?
- 3: Path 1: Android MCP - How to proactively expose functionality to Agents?
- 4: Path 2: Agentic API - How to embed an Agent inside your app?
- 5: Path 3: Do nothing, and the Agent can still control your app?
- 6: A2UI Compose Renderer - Can the Agent draw its own UI?
- 7: What does this mean for Android developers?
🤔 What is the Android Intelligent System?
(Image)
Android is shifting from an "operating system" to an intelligent system. Google's definition is clear: a system-level infrastructure that connects AI Agents with apps on the device while protecting users.
It covers more than just phones; the entire Android ecosystem: phones, watches, XR glasses, TVs, and cars.
Two assistance modes
| Mode | Trigger | Example |
|---|---|---|
| Prompt assistance | User proactively tells the Agent a goal | "Help me hail a ride with Didi" |
| Proactive assistance | System predicts user needs and proactively pushes | Lock screen suggests "Time to leave for the airport" |
Prompt assistance execution has priority:
- 1: First, remote MCP (cross-platform, server-side execution);
- 2: Then Android MCP (local native execution);
- 3: If neither exists, Computer Control Framework - the Agent directly operates the screen.
The third is a fallback. Your app doesn't need to do anything; the Agent can still use it by looking at the screen.
🗺️ Overview of the Three Paths
(Image) There are three paths:
- Path 1: Android MCP
- Path 2: Agentic API
- Path 3: Computer Control
| Dimension | 1. Android MCP | 2. Agentic API | 3. Computer Control |
|---|---|---|---|
| Brief | App proactively exposes capabilities to Agent | App runs its own Agent internally | Agent controls the app via the screen |
| Principle | System Agent → Your App | Your App → On-device model | System Agent → Your screen |
| Integration | AppFunctions | Integrate ML Kit API | Zero (nothing to do) |
| Capability ceiling | High (structured data exchange) | High (full Agent experience inside app) | Low (can only see screen and tap buttons) |
| User experience | Fast, accurate, reliable | Native in-app experience | Slow, may cause misoperations |
| Current status | AppFunctions available | Agentic API newly released | Live (fallback) |
The three paths are not mutually exclusive. Most apps will eventually combine the first two.
🔌 Path 1: Android MCP + AppFunctions
(Image)
This is Google's most recommended approach: your app proactively tells the Agent "what I can do".
What is Android MCP?
MCP = Model Context Protocol. An app exposes its capabilities to an AI Agent via a standard protocol.
AppFunctions: How to expose capabilities?
Android MCP's underlying library is AppFunctions (androidx.appfunctions).
It's Android's unified tool-calling framework, where annotations declare what your app can do:
// 👈 Declare an AppFunction: order coffee
@AppFunction
suspend fun orderCoffee(
@AppFunctionParameter(description = \"Coffee type, e.g., latte, americano\")
coffeeType: String,
@AppFunctionParameter(description = \"Cup size: small/medium/large\")
size: String
): OrderResult {
// ✅ Your business logic
return coffeeService.placeOrder(coffeeType, size)
}
The Agent doesn't see your UI; it sees structured function signatures and parameter descriptions.
It knows what you can do, what parameters you need, and what results you return. Far more accurate than manipulating the screen.
Connected Apps Platform
(Image)
After exposing capabilities, your app can appear in two places:
- Gemini app - when users talk to Gemini, the Agent directly invokes your feature;
- Google Search - when users search, your app's actions are embedded directly in the search results.
When to use Android MCP?
| Scenario | Recommended? |
|---|---|
| End-to-end encryption or sensitive local data | ✅ Android MCP (data stays on device) |
| Needs device sensors/hardware | ✅ Android MCP (local execution) |
| Has a ready server-side API | ✅ Remote MCP (broader cross-platform reach) |
| Have both | ✅ Integrate both (complementary) |
Android MCP is the right way to "turn your app into an Agent's tool." Integration cost is low, and the benefit is clear: you control what's exposed, and the Agent calls it in a structured way: fast and accurate.
🧠 Path 2: Embedding an Agent in Your App (ML Kit Agentic API)
Path 1 is "being called by an external Agent." Path 2 reverses it: your app runs its own Agent. (Image)
Three core APIs
| API | Capability | Status |
|---|---|---|
| Prompt API | Directly invoke on-device model inference | Released |
| Agentic API | Automatic function calling + conversation history + orchestration loop + automatic guardrails | Newly released |
| Embeddings API | Embedding vectors powered by EmbeddingGemma 2 | Alpha |
Agentic API is the new thing: the normal Prompt API is one ask, one answer. Agentic API gives the model a goal, and the model plans steps, calls functions, checks results, and loops until completion.
Specific capabilities:
- Automatic function calling - the model decides which function to call and calls it;
- Conversation history - multi-turn context is preserved;
- Orchestration loop management - plan → execute → verify → retry, run automatically;
- Built-in guardrails - prevent the Agent from performing undesired actions.
Gemini Nano 4 performance
(Image)
These APIs run on Gemini Nano 4, an on-device model with no cloud calls.
| Metric | Data |
|---|---|
| Inference speed | 3x faster than previous Nano |
| Memory usage | up to 4x lower |
| Language support | 140+ languages |
| Multimodal | text + image + audio |
| New capability | Function calling |
What does 3x faster mean? The previous Nano took about 2-3 seconds for a medium-length answer; now under 1 second.
The biggest advantage of on-device models isn't speed; it's privacy. Data never leaves the phone. For payments, health, and communications apps, that's a hard requirement.
Use cases
Suitable for teams that want to build a "native Agent experience" inside their app. Users never leave your app; the Agent completes everything within it.
👁️ Path 3: Do Nothing, and the Agent Can Still Use Your App
(Image)
This is Google's fallback plan.
Computer Control Framework works like this:
- 1: The Agent sees the content on the user's screen;
- 2: Recognizes UI elements (buttons, input boxes, lists);
- 3: Simulates clicks, swipes, typing, etc.;
- 4: Completes the user's task.
No integration needed from your app.
Sounds good? Don't get too excited
| Dimension | Computer Control | Android MCP |
|---|---|---|
| Speed | Slow (screenshot → recognize → act → screenshot again) | Fast (direct function call) |
| Accuracy | Low (UI changes can cause misrecognition) | High (structured parameter passing) |
| Data exposure | Agent sees everything on screen | You expose only what you allow |
| User experience | Like someone remotely controlling your phone | Invisible, runs in the background |
| Reliability | Fragile (depends on stable UI layout) | Stable (depends on API contract) |
- Computer Control is like someone looking through a window at your app and poking the screen with a finger.
- Android MCP is like handing them a key and an instruction manual.
So Computer Control is relatively imprecise.
Why does Google still build it?
Because in reality, most apps haven't integrated MCP yet. So Computer Control is a transitional solution.
Summary
Your app does nothing, and the Agent can indeed use it. But the experience is poor, slow, and data exposure is uncontrolled. That's not the way you want to be "used by an Agent."
🎨 A2UI Compose Renderer: The Agent Draws Its Own UI
(Image)
This is what surprised Carson the most at this Dev Summit.
A2UI (Agent-to-UI): The Agent streams native Jetpack Compose UI via a JSON protocol.
What does it mean?
- Traditional approach: you write all the UI layouts, and show different screens when users trigger different actions.
- A2UI approach: the Agent dynamically generates UI based on the user's request.
In the Dev Summit demo, a "real-time booking assistant":
- User says "book a flight for next Friday";
- The Agent dynamically generates date pickers, seat selection, payment form — all native Compose components, not WebView;
- The entire interface has no pre-written layout code.
What does the code look like?
// 👈 A2UI: Agent outputs JSON, Compose renders native UI
val a2uiRenderer = A2UIComposeRenderer.create()
// ✅ Agent's JSON stream input → native Compose UI output
a2uiRenderer.render(
jsonStream = agent.streamResponse(userPrompt),
modifier = Modifier.fillMaxSize()
)
A2UI Compose Renderer is currently Alpha. Docs: goo.gle/a2ui-compose-docs
Summary
A2UI opens a new door: UI no longer must be pre-designed by developers; the Agent can generate it dynamically based on context. This has huge potential in customer service, forms, booking, and similar scenarios.
🧑💻 What Does This Mean for Android Developers?
(Image)
| Your situation | Recommended path | Reason |
|---|---|---|
| Have a clear feature to expose to Gemini | ✅ Android MCP | Structured calls, good experience, you control boundaries |
| Want to build an intelligent assistant inside your app | ✅ Agentic API | On-device, privacy-safe, no cloud dependency |
| Want the Agent to dynamically generate UI | ✅ A2UI (Alpha) | Good for customer service/forms/booking, prototype first |
| Don't want to do anything | ⚠️ Computer Control fallback | Works, but poor experience and uncontrolled data exposure |
| Have sensitive data (payments/health) | ✅ Android MCP + Agentic API | Data stays on device, you control exposure |
| Want to appear in both Search and Gemini | ✅ Connected Apps Platform | Currently in preview; can join the waitlist |
Feature status quick reference
| Feature | Status |
|---|---|
| AppFunctions Jetpack library | ✅ Released |
| Connected Apps Platform | Developer preview (waitlist) |
| ML Kit Agentic API | Newly released |
| ML Kit Embeddings API | Alpha |
| A2UI Compose Renderer | Alpha |
| Gemini Nano 4 new capabilities | AICore developer preview |
| Computer Control Framework | ✅ Live |
| LiteRT in Google Play Services | ✅ Released (added Wear OS / Auto) |
What to do now?
- 1: Assess which features in your app are suitable for exposing to Agents - not everything needs it; pick high-frequency, clear operations;
- 2: Learn about the AppFunctions Jetpack library - this is the underlying implementation of Android MCP, and the API is available;
- 3: Try Agentic API + Gemini Nano 4 - experience it via AICore developer preview;
- 4: Don't rely on Computer Control as a long-term solution - it's a fallback, not the right path;
- 5: Watch Connected Apps Platform opening progress - currently preview, will open self-service later.
Android is shifting from "users operating apps" to "Agents operating apps on behalf of users."