On Nov 5, 2026 the Android team published its Android Developer Summit round-up for intelligent apps. Strip away the product names and one idea remains: users now state a goal ("check my calendar, book a ride, and message Jingyu my ETA") and a system agent orchestrates apps to finish it. Android gives you three ways to take part, with very different costs. This post sorts them by what they demand from you, using the Android docs and the Dev Summit post, and then covers the other half: putting an agent inside your own app.
Status check: the Android docs label the intelligence-system features as Preview, and Computer Control as an "upcoming" API that currently works with a limited set of target apps. Treat this as a design decision to prepare for, not a feature to promise in a release.
The two modes: prompted and proactive
Per the Dev Summit post, the intelligence system offers prompted assistance, where the user explicitly asks an agent for something, and proactive assistance, where the system surfaces contextual suggestion chips on lock screens, notifications, virtual keyboards and inside apps. The three integration paths below serve the prompted flow. The system covers phones, wearables, XR glasses, TVs and cars.
Path 1: AppFunctions (Android MCP)
AppFunctions is a platform API with a Jetpack library that exposes specific capabilities of your app as discrete functions that agents can discover and execute on-device. The blog calls this "Android MCP", built on the familiar MCP standard. You write the functions, so you control exactly what an agent can do. If you adopted it earlier, my rc01 migration guide lists the API churn.
Google recommends it when your user journey:
- uses end-to-end encryption or sensitive local device data,
- needs device sensors or hardware,
- must execute locally, or
- has no server endpoint available.
It can also connect your own on-device in-app agent, not only the system agent.
Path 2: a remote MCP server
With the server-side approach your backend exposes capabilities to agents directly. The docs describe it as complementary and a good fit for coverage across Android and other platforms. Nothing runs on the phone, so there is no app release to ship and no on-device data. The trade-off is the mirror image of path 1: if the journey depends on local state or hardware, a server cannot see it.
Path 3: Computer Control
Computer Control lets an OEM-preloaded assistant drive your app's UI, with no integration on your side. According to the framework docs:
- The assistant needs the privileged
ACCESS_COMPUTER_CONTROLpermission, so this is not an API third-party assistants can adopt. - A session covers up to six target apps for sequential execution, and only one session is active at a time.
- The first time it touches your app, the system shows a permission dialog to the user.
- Your app runs on a secure background virtual display. The assistant captures screenshots, infers actions and simulates taps, swipes and text input.
- Control can be handed back to the user, for example for transaction confirmation.
Because the agent reads screenshots, the docs' advice for target apps is the unglamorous kind: follow adaptive design and lifecycle best practices. Stable, labeled, predictable screens are your integration. An assistant may also choose to limit which apps it automates, so you cannot opt yourself in by polishing the UI.
The Dev Summit post describes Computer Control as the fallback: agents can use it "to complete actions without requiring any app-side integration" when neither MCP route exists. That makes the first two paths the ones where you decide the behavior and the third the one where you do not.
Choosing: a heuristic, not an API
This snippet is my own summary of the guidance above, not a library call. It is useful as a team checklist:
enum class AgentPath { ANDROID_MCP, REMOTE_MCP, COMPUTER_CONTROL_ONLY }
data class Journey(
val usesLocalSensitiveData: Boolean,
val needsDeviceHardware: Boolean,
val mustRunLocally: Boolean,
val hasServerEndpoint: Boolean,
val needsOtherPlatforms: Boolean,
)
fun pickPath(j: Journey): AgentPath = when {
j.usesLocalSensitiveData || j.needsDeviceHardware || j.mustRunLocally ->
AgentPath.ANDROID_MCP
j.hasServerEndpoint || j.needsOtherPlatforms ->
AgentPath.REMOTE_MCP
else -> AgentPath.COMPUTER_CONTROL_ONLY
}
The two are not exclusive. The Connected Apps Platform, which targets Gemini and Search, combines Android MCP for native on-device execution with remote MCP servers for cross-platform reach. You can test locally today with Gemini Apps Developer Mode; production access is a preview waitlist, and capacity is currently limited to selected production-ready apps in supported categories.
The other half: agents inside your app
The same post covers building intelligence in:
- ML Kit GenAI Agentic API. With function calling in Gemini Nano 4, ML Kit adds an Agentic API that auto-executes functions, saves conversation history, manages the orchestration loop and includes automatic guardrails. The Prompt API gives direct model access, including thinking mode and system instructions. The reference is the Jetpacker sample in the
android/ai-samplesrepository. - Gemini Nano 4 is built on Gemma 4. Google reports up to 3x inference speedup and up to 4x lower memory use versus the previous Gemini Nano, in internal testing benchmarks. Opt in to the AICore Developer Preview to test preview-model capabilities.
- Embeddings API (alpha), powered by EmbeddingGemma 2.
- LiteRT in Google Play services removes the runtime from your APK, making it about 8 MB smaller, and is now also on Wear OS and Android Automotive OS.
- Firebase AI Logic for hybrid cloud plus on-device calls, protected by App Check, server prompt templates and spend caps.
- A2UI Compose renderer (alpha) so your agent can stream native Compose UI from a JSON protocol; see my A2UI post.
What I would do this quarter
- List your top three user journeys and run each through the heuristic above.
- For any journey touching local or private data, prototype with AppFunctions using the official skill and sample agent.
- For everything else, check whether an existing backend endpoint can become a remote MCP tool.
- Audit screens for Computer Control readiness: stable lifecycle handling, adaptive layouts, no flows that break when run on a virtual display.
- Keep in-app agents on-device only where latency or privacy demands it; use Firebase AI Logic hybrid otherwise.
Sources: the Android Developers Blog post "From in-app agents to the Android intelligence system" (Nov 5, 2026) and the Android docs pages on the intelligence system and Computer Control, retrieved Nov 6, 2026.
No comments yet. Be the first to leave one!