I have spent the last year and a half building against Android's agentic APIs, not reading about them from a keynote seat. Be nice got an AppFunction so Gemini could invoke createAppPair directly; a few months later, bumping a single alpha broke it, because alpha10 quietly stopped shipping the service component alpha08 depended on. That scar tissue is a decent filter for keynote language. So when Android's president, Sameer Samat, describes the platform moving from an operating system to an intelligent system, I try not to start with whether that's true. I start with which layer of the stack that sentence is describing, because "Intelligence System" covers at least three very different things at once, and only one of them is finished enough to build on.
Layer one is the model runtime: what executes on the device, which APIs call it, how stable those APIs are. Layer two is app integration: how an app exposes itself to an agent, and how much of that exposure the app developer controls versus how much Android does for them without asking. Layer three is distribution: who gets to be the agent standing in front of the user, and whether that's a genuinely open contest or a foregone one.
Google's own framing blurs all three into a single narrative arc. The February 2026 "Intelligent OS" post redefined what success means for an app: not opens, but completed tasks, with or without a human touching the UI. Android's May I/O recap made the platform claim explicit: agents like Gemini can already "complete task automation" on Android, navigating an app on the user's behalf without anyone tapping through it themselves. One sentence, three separate engineering claims bundled together. I want to pull them apart in the order I trust them least to most, which also happens to be the order in which the marketing runs furthest ahead of the shipping code.
Start with distribution, since that's where the keynote wants your attention least. Android Halo is the new status-bar slot for that. Google describes it as making "your agent's status visible by bringing subtle communication to the top of your phone screen as it takes on a task, goes into live mode or sends you a message." It ships with Android 17 later this year. Samat's own language around it, in a July interview, was carefully agent-agnostic: Halo, as he put it, is a dedicated spot for whichever agent a person chooses to use, Gemini or otherwise.
Taken at face value, that's a real platform commitment. A status-bar slot isn't an API, though, and good intentions in an interview aren't a capability list. What would it take for an assistant that isn't Gemini to occupy that slot on equal footing? At minimum: the same wake-word rights, the same background-execution allowance, the same access to on-device context, and the same permission to perform integrated actions, such as sending an email or booking a ride, that Google's own agent gets by default.
That list isn't hypothetical. On July 16, 2026, the European Commission adopted a decision under Article 6(7) of the DMA ordering Alphabet to provide eleven Android features to third-party AI assistants "free of charge" and on terms "equally effective to those available to Google." Those eleven fall into four buckets: invocation (the long-press home-button handle, always-on hotword detection), context (centralized access to on-device app data, context-aware intelligence, ambient sensor data), actions (structured on-device app integration, screen automation, system integration), and resources (system-level on-device models such as Gemini Nano, on-device model implementation, background execution). Google has to ship most of it with Android 18, by August 1, 2027. The one holdout is concurrent hotword detection, letting a second assistant listen for its own wake word at all, pushed back to Android 19, by August 1, 2028.
Line up the two dates and the pattern is hard to miss: Halo ships in 2026 carrying a one-line promise of neutrality. The regulatory floor that would let a third party verify that promise, rather than take Google's word for it, lands roughly a year later, and only inside the EU. Everywhere else, that openness is a line from an interview, revocable, on a schedule Google sets, on a platform Google also uses to distribute its own competing product. I watched a smaller version of this pattern play out with sensitive permissions and Play policy: a platform owner deciding unilaterally what counts as fair, on its own clock. Halo's openness claim deserves the same skepticism until there's an API surface and a compliance deadline behind it, not just a quote in a video interview.
History offers a reason to keep that skepticism even after the deadline passes. The Commission forced a similar remedy years earlier with Android's browser and search-engine choice screens, mandated at first boot for exactly this kind of default problem. Mozilla's own account of the rollout calls it "fairly inconsistent" across the EEA, and the clearest gains it can point to are on iOS, not Android. A one-time prompt during setup is a weak opponent for an incumbent that's pre-installed, pre-authorized, and, after this year, sitting in a status-bar slot the user checks by habit every few minutes. If Halo's third-party parity follows the same arc, we'll get the API surface the DMA demands and still end up with a Gemini-shaped default, because the remedy targets access, not habit.
This is the layer I've shipped against, and it's the one place I'll say plainly: the architecture is genuine. An app extends AppFunctionService, annotates callable methods with @AppFunction, marks their parameter and return types with @AppFunctionSerializable, and an annotation processor turns that into an XML schema the OS indexes. An agent queries AppFunctionManager to discover what a package offers (including the KDoc description, which doubles as the natural-language contract the agent reasons over) and invokes it, gated behind the EXECUTE_APP_FUNCTIONS permission. It's Android's on-device answer to an MCP tool server, except the transport is the platform itself and the "server" is an app the user already installed. Worth being clear about what that permission doesn't buy you: it's one blanket grant, not a per-function one, and the platform doesn't do rate limiting for you. Argument validation stops at the type level: a malformed call throws AppFunctionInvalidArgumentException before your code ever runs, but nothing stops an agent from asking Be Nice to book a ride in the past, since that's business logic, not a schema check, and it's still on you. Past that single check, the safety model is "notify the user and let them intervene," the same posture MCP itself gets criticized for. That's an architectural gap, not a preview-stage rough edge, and it's worth watching whether Android closes it before agentic use of AppFunctions scales up.
What I'd tell another developer before building on it: treat every surface here as provisional. AppFunctions requires Android 16 (API 36) at minimum, Gemini's platform integration was still a private preview with trusted testers as of May 2026, and my own alpha08-to-alpha10 jump is a small case study in what "experimental preview" costs you: a component the library used to host for you simply stopped existing, and the fix was to host it yourself. Samsung has production usage to point to: Calendar, Notes, and Tasks AppFunctions ship on Galaxy S26 under OneUI 8.5. That's proof the model works end to end. It isn't proof the surface is stable, and anyone building a roadmap item on top of it should budget for at least one more breaking rename before this settles.
Google also previewed a rougher, more aggressive path at I/O: an agent that operates ordinary apps through UI automation, with zero code from the app developer, currently in beta on Galaxy S26 and select Pixel 10 devices for food delivery, grocery, and rideshare in the US and Korea. Where AppFunctions asks the app to opt in and describe itself, this asks nothing of the app at all: the agent drives the existing UI the way a person would. Those are philosophically opposite bets on the same problem, and Google is running both at once, which tells you it doesn't yet know which one wins either.
A policy question sits directly on top of the technical one, and I've been through a version of it before with Play's high-risk rules for READ_CALL_LOG and READ_CONTACTS. An @AppFunction that hands an agent read access to a calendar, a contact list, or call history is functionally a new distribution channel for exactly the data Play already treats as sensitive, except that the party deciding whether to ask is another piece of software, not a human tapping "allow." Google moved on this in July: a Play Console policy update dated July 15, 2026 states plainly that third-party AI integrations fall under the existing User Data policy, closing that loophole before it fully opened. What it doesn't yet say is whether an agent's invocation counts as the "compelling, critical feature that has no alternative" Play already demands to justify broad data access, or whether exposing a function is itself something Play will want declared. Given how deliberately Google has tightened that particular screw over the last two years, I'd be surprised if that stays unanswered for long.
The model and runtime layer is the least visible part of this stack, and I'd argue the part most likely to still matter in three years regardless of what happens to Spark, Halo, or any other assistant brand. AICore picked up a developer preview of Gemini Nano 4. More telling: ML Kit's GenAI Prompt API graduated from prototyping tool to production-ready, backed by that same Nano 4 rolling out to flagship devices later this year: a real API-maturity milestone, not a preview repackaged with new marketing copy. A Structured Output API is coming so on-device generation returns typed objects instead of strings you regex apart. Prefix caching reuses intermediate LLM state across recurring prompt sections instead of recomputing it on every call: unglamorous latency-and-battery work that never makes a keynote, and exactly why I trust it. LiteRT-LM lets you bring your own fine-tuned small model instead of being stuck with Google's.
Firebase AI Logic's hybrid inference is the piece I'd reach for first in a real app: explicit routing modes (PREFER_ON_DEVICE, PREFER_CLOUD, ONLY_ON_DEVICE, ONLY_CLOUD) let you choose the privacy/latency/quality tradeoff per call site instead of hardcoding it once and living with the consequences. An ADK for Android handles multi-agent orchestration across on-device and cloud models, and an upcoming A2UI renderer lets an agent describe UI declaratively and have it materialize as native Jetpack Compose, instead of an agent trying to tap through your existing screens pixel by pixel. That's a more honest fix for the UI-automation problem above than anyone said out loud at I/O.
Nothing in this layer needs Spark, Halo, or the word "agent" to justify itself. A production Prompt API and an explicit on-device/cloud routing knob are useful even in an app that never talks to an assistant at all. That durability is why I'd tell anyone planning against this ecosystem to build here first, and treat everything in layers two and three as subject to change without much notice.
Who gets this first is also worth being honest about. Gemini Nano 4 is arriving on flagship devices later this year, which on Android's install base is a small and slowly growing slice of the phones people hold. Firebase's hybrid inference modes exist precisely because Google knows this: ONLY_CLOUD and PREFER_CLOUD aren't fallbacks for edge cases, they're the default reality for most of the fleet for the next several years. A demo running smoothly on this year's Pixel is quietly describing a minority of Android users. The interesting engineering question isn't whether Nano 4 impresses on a flagship (it clearly does); it's whether your app degrades gracefully on the mid-range device your median user is holding, where the same prompt is going to a server instead.
Collapse the three layers back into "Intelligence System" and you get a sentence that's true about layer one, unfinished about layer two, and unverified about layer three. Google's keynote spends the least time on the layer that's solid and the most time on the layer that isn't. I don't think that's dishonest, exactly; it's what every platform vendor does with a stack still being built while it's being announced. I say this as someone who's happily spent most of a career on this platform, fond of what Android's community and ecosystem have built together, and it's precisely because I care where it's headed that I don't want to wave the bundle through unexamined. The job for the rest of us, the developers who'll build on this, is not to accept it wholesale.
Concretely, that means asking a different question depending on which layer a given announcement belongs to, instead of one generic "is AI real" question the marketing invites. For runtime and model APIs (AICore, ML Kit GenAI, Firebase's hybrid inference modes), the right question is simply "production-ready or preview," because the architecture itself isn't in doubt; build here with normal confidence once that box is checked. For app-integration APIs like AppFunctions, the right question is "what breaks on the next alpha, and what's my rollback," because the model is sound but the surface is still moving under real developers' feet, mine included. For distribution claims like Halo's promise of agent choice, the right question is neither of those: it's "show me the API, and show me who else is shipping against it," because a status-bar slot and a quote from an interview aren't a platform commitment until a competitor can build on them without Google's cooperation.
I'll walk my own talk through that filter rather than through Google's slide order: model layer first, because it's the part I'd bet on regardless of what happens to any assistant brand; AppFunctions second, scar tissue on display and all, because I still think it's one of the more thoughtful things this platform has shipped; Halo and the openness claim last, as the thing to interrogate rather than the thing to lead with, but interrogate in good faith, the way you'd push back on a friend's plan because you want it to work. If your team is deciding what to prototype this quarter versus what to just watch, that ordering is the real answer: not "AI on Android," but which of three very different claims you're being asked to bet on.
Where do you land on Halo specifically: genuine platform neutrality, or a placeholder that only becomes real once the EU forces the issue? I'd genuinely love to hear it either way; this community has never been shy about that kind of debate, and that's one of my favorite things about it. Tell me in the comments; I'm still deciding how hard to push that claim on stage.