AI on Android at Google I/O 2026: Gemini Nano 4 & More

At Google I/O 2026, Google presented a clear shift in how it talks about Android. The platform is no longer described only as an operating system that runs apps. It is now framed as an intelligence system, one in which Gemini completes task automation across apps and the apps themselves become part of that system. That framing matters because it changes what developers are being asked to build, and it changes what users should expect from the apps already on their phones.

The announcements collected in the official Android Developers Blog post, “Top AI on Android updates for building intelligent experiences from Google I/O ’26,” cover several distinct pieces: a new way for apps to expose their capabilities to agents, new on-device models and production tooling, and new options for routing work between on-device and cloud models. None of these pieces is a single feature. Together, they describe an architecture in which intelligence is distributed across the device, the app, and the cloud, and in which the developer’s job is to decide where each task should run and what each app should offer to the system.

From Operating System to Intelligence System

The phrase “intelligence system” is doing a lot of work in Google’s I/O 2026 framing. An operating system, in the traditional sense, manages hardware, runs apps, and mediates permissions. An intelligence system, as Google describes it here, adds a layer in which Gemini can complete tasks across apps on the user’s behalf. The difference is not only about adding a chatbot to the phone. It is about the system understanding what apps can do and being able to invoke those capabilities as part of a larger task.

For users, the practical meaning is straightforward to state and harder to predict in detail: instead of opening one app at a time and performing each step manually, a user may ask for an outcome and have the system coordinate the steps across apps. Google’s framing positions Gemini as the coordinator in that picture. For developers, the practical meaning is that an app’s value is no longer limited to its own interface. An app that exposes its tools and services to the system can be used in flows the developer did not design end to end.

AppFunctions and Android MCP: Apps as On-Device MCP Servers

The most structurally important announcement for developers is AppFunctions, described as a new platform API with a Jetpack library, currently in experimental preview. AppFunctions lets an app act as an on-device Model Context Protocol (MCP) server, sharing its tools, services, and data with the system and with agents.

What an MCP server on the device means in practice

Model Context Protocol, or MCP, is a general approach for letting models and agents discover and use tools and data sources through a standard interface. In the Android context described at I/O 2026, the notable point is that the server runs on the device, inside the app’s own boundary, rather than only in the cloud. That on-device placement matters for several reasons that developers will recognize immediately: data that never leaves the device stays under the app’s existing privacy and permission model, latency can be lower for local operations, and the app’s tools can work with state that only the app holds.

The Early Access Program and the path to production

Alongside the experimental preview, Google announced an Early Access Program for deploying app functions in production. The distinction between preview and early access is important. A preview is for learning and experimentation. An early-access production path is for developers who are ready to ship a real implementation to real users under program terms. Developers interested in production use should look for the program’s enrollment details and requirements in the official announcement and documentation, and should not assume that preview access alone grants production deployment.

On-Device AI: Gemma 4, Gemini Nano 4, and ML Kit GenAI

The second group of announcements concerns on-device models and the tooling around them. According to the Android Developers Blog summary, Gemma 4 open models launched last month, and Gemini Nano 4 is available in preview via the AIcore developer preview. ML Kit GenAI APIs add features intended to make productionizing with Gemini Nano more reliable and performant, and the Prompt API lets developers move from AICore preview prototyping to production with Gemini Nano 4 launching in flagship devices later this year. A Structured Output API is upcoming, which will let developers define object classes to return from the Prompt API.

Gemma 4 and the open-model option

Gemini Nano 4 in preview through AICore

Gemini Nano is Google’s smallest Gemini model family, designed to run on device. The I/O 2026 update places Gemini Nano 4 in preview via the AIcore developer preview, with the Prompt API as the route from prototyping in that preview to production as Gemini Nano 4 launches in flagship devices later this year. That sequencing is worth noting: preview first, then production availability tied to device launches. Developers should not assume that a model in preview is available on every device today, or that preview behavior will match production behavior on launch devices.

Structured Output: an upcoming API worth planning for

The upcoming Structured Output API will let developers define object classes to return from the Prompt API. That is a practical capability for anyone who has tried to use a generative model as part of an app workflow. A model that returns free-form text is useful for display, but an app that needs to act on a result — to save a record, update a list, or pass data to another function — needs output in a predictable shape. Structured output addresses that need by letting the developer specify the shape in advance.

Hybrid Inference and Multi-Agent Workflows

The third group of announcements addresses a question every developer working with on-device models eventually faces: what happens when the on-device model is not enough? Some tasks need more capability, more context, or access to data and services that live in the cloud. Others need to stay on device for privacy, latency, or offline reasons. Google’s answer at I/O 2026 has two parts: a hybrid inference API and a multi-agent development kit for Android.

The Firebase AI Logic Hybrid Inference API provides simple routing between on-device models and cloud infrastructure. In general terms, routing means the app does not have to hard-code a single model location for every task. Instead, the app can send simpler or more sensitive work to the on-device model and send heavier or broader work to the cloud, under rules the developer defines. The announcement describes the routing as simple, which suggests the aim is to reduce the boilerplate developers would otherwise write to manage two model paths, two sets of errors, and two fallback behaviors. Developers should confirm the exact routing controls, supported models, and pricing or quota behavior in the official documentation, because those details were not part of the grounded facts for this article.

Alongside that, ADK for Android arrives in a first version aimed at experimentation. ADK is Google’s Agent Development Kit, and the Android version is for building multi-agent workflows across on-device and cloud models. A multi-agent workflow, in general background terms, is a task broken into steps handled by different agents: one agent may gather context, another may plan, another may call tools, and another may check the result. The kit gives developers a structure for building those workflows rather than wiring each step by hand.

At a Glance: The New APIs and Tools

The table below summarizes the announcements discussed so far, using only the facts given in the official blog summary. Availability notes are included because several items are previews or early-access programs, and that status affects how developers should plan around them.

What Developers Should Build First

With several new tools arriving at once, the temptation is to try all of them. A more practical approach is to pick one narrow use case and ship it well. The announcements point to a natural order, and developers can use it as a starting sequence rather than a strict rule.

First, pick one on-device feature and build it with the Prompt API. The reason to start on device is that the constraints are concrete: the model runs on the phone, the feature must work within the device’s limits, and the user gets the privacy and latency benefits of local processing. A summarization, rewrite, suggestion, or classification feature that uses text the app already holds is a natural starting point. Keep the prompt narrow, validate the output before acting on it, and give the user a clear way to see and correct the result.

Second, use the test agent before shipping AppFunctions. The test agent exists so developers can observe how an agent interacts with their functions in a simulated environment. Use it to check the basics: does the agent choose the right function, does it pass the right inputs, what happens when an input is missing or invalid, and what does the user see when a function fails? Fixing those issues in simulation is far cheaper than fixing them after real users encounter them.

On-Device vs. Cloud: The Trade-Offs Developers Must Weigh

Every decision about where intelligence runs involves trade-offs, and the I/O 2026 announcements make those trade-offs more visible rather than removing them. On-device processing keeps data on the phone, can respond quickly, and can work without a network connection. Cloud processing can use larger models, broader context, and services that only exist on a server. Neither is better in every case, and the right choice depends on the task, the data, and the user’s expectations.

Privacy is the most commonly cited reason to prefer on-device work, and it is a real one: data that never leaves the device is not exposed to network transit or server storage. But privacy is not the only factor. A task that needs to pull information from many sources, coordinate across services, or reason over a large amount of context may be impractical on device even if the model itself could run there. A task that is simple, repetitive, and tied to data already on the phone is often a strong on-device candidate.

What This Means for Users

For users, the I/O 2026 announcements are best understood as infrastructure rather than as features to look for by name. No user will open their phone and tap a button labeled “AppFunctions” or “Hybrid Inference.” What they may notice, over time, is that asking the phone to do something involves fewer manual steps, that apps cooperate more smoothly, and that some AI features work quickly and privately on the device while others draw on the cloud when needed.

Frequently Asked Questions

What did Google announce about AI on Android at I/O 2026?

Google framed Android as an intelligence system in which Gemini completes task automation across apps. The announcements covered AppFunctions and Android MCP, on-device models including Gemma 4 and Gemini Nano 4, ML Kit GenAI APIs, the Prompt API and an upcoming Structured Output API, the Firebase AI Logic Hybrid Inference API, and ADK for Android for multi-agent workflows.

What are AppFunctions?

AppFunctions are a new platform API with a Jetpack library, currently in experimental preview, that let an app act as an on-device Model Context Protocol (MCP) server. That means the app can share its tools, services, and data with the system and with agents, so those tools can be invoked as part of a larger task rather than only through the app’s own interface.

How can developers test AppFunctions?

Google released a new test agent for experimenting with and debugging AppFunctions in a simulated agent environment. Developers can use it to see how an agent discovers and calls their functions before shipping to real users. There is also an Early Access Program for deploying app functions in production.

What is Gemini Nano 4, and when is it available?

Gemini Nano 4 is the newest on-device Gemini model, available in preview via the AIcore developer preview. The Prompt API lets developers move from AICore preview prototyping to production with Gemini Nano 4 launching in flagship devices later this year. No specific device list or launch date was part of the grounded facts for this article, so none is given here.

What is the difference between on-device and hybrid inference?

On-device inference runs the model on the phone, which keeps data local and avoids a network round trip. Hybrid inference, through the Firebase AI Logic Hybrid Inference API, routes work between on-device models and cloud infrastructure, so simpler or more sensitive tasks can stay on device while heavier tasks use the cloud. Developers choose the routing based on the task.

Verdict

Google I/O 2026 gives Android developers a coherent set of building blocks: a way for apps to offer tools to agents, newer on-device models with production tooling, and a hybrid path for work that needs the cloud. The pieces are at different stages — some in preview, some in early access, some upcoming — and that matters for planning. The developers who will get the most from these announcements are the ones who start narrow: one callable operation, one on-device feature, tested in simulation and on real devices, with a clear fallback when the model or the network does not cooperate. The intelligence-system framing will be judged not by the announcement but by whether those first features are reliable enough for users to trust. On the facts announced, the direction is clear and the tooling is real; the work of proving it now belongs to developers.