Android's AI Era: Hype vs. Architecture

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. Three Claims Wearing One Name 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. Layer Three First, Because It's the Weakest: Who Gets to Be the Agent 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. Layer Two: AppFunctions Is Real, and Still Finding Its Shape 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. Layer One: The Part That Will Outlive Both Buzzwords 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