EU Forces Google to Open 11 Android Features to Third-Party AI Assistants

On July 16, 2026, the European Commission adopted a final decision under Article 6(7) of the Digital Markets Act that requires Alphabet to open eleven Google Android features to third-party AI assistants and AI-powered services, free of charge, on terms "equally effective" to what Google's own services get. The decision caps a specification proceeding that opened on January 27, 2026, and it was informed in part by the Open Home Foundation, whose Android developer for Home Assistant was invited to consult with the Commission after years of fighting Google's restrictions.

This is one of the most concrete platform-interoperability rulings yet, because it names the exact features, the exact deadlines, and the exact conditions. If you build a voice assistant, an agentic app, or anything that wants to act on a user's behalf inside Android, the surface you can reach is about to get much larger.

What the Decision Requires#

The ruling covers eleven Android features grouped into four capabilities that AI services rely on:

• Invocation: long-press access to the home button and navigation handle (no longer reserved for Circle to Search and Google's own surfaces), plus always-on hotword detection with support for concurrent wake words, so multiple assistants can listen at once.
• Context: centralized access to on-device app data (the AppSearch path Google uses), context-aware intelligence with proactive suggestions, and ambient data, meaning real-time access to microphone, camera, screen, and speakers under the same consent and awareness conditions that apply to Google.
• Actions on apps and the OS: structured on-device integration (the App Functions mechanism, including access to Gmail, Calendar, Drive, Docs, Maps, YouTube, Messages, and Phone), screen automation (the Computer Control path, currently reserved for Gemini), and system integration for settings like brightness, media, Do Not Disturb, and Bluetooth.
• Access to resources: the ability to call Android's system-level on-device models, including the Gemini Nano ODMs already preinstalled on devices, equal access for third-party on-device model implementations, and transparent, non-discriminatory background execution rules for AI apps.

The general conditions matter as much as the feature list. Interoperability must be free, equally effective in ease of use, speed, and energy consumption, and must not be conditioned on holding a default role. Google must publish complete documentation, provide testing tools and technical assistance, and report regularly to the Commission on implementation progress over the next two years.

The timeline: all features must ship in Android 18, no later than August 1, 2027. Concurrent hotword detection, where multiple services can be voice-triggered at the same time, is due in Android 19, no later than August 1, 2028.

Five of the eleven features - screen automation, structured on-device integration, system integration, centralized on-device data access, and context-aware intelligence - are subject to objective, non-discriminatory eligibility conditions that Google may set for privacy, security, and integrity reasons, with independent third-party certification. Google must publish draft terms by February 1, 2027, final terms by May 1, 2027, and accept applications from that date, with assessments completed within four weeks.

The Home Assistant Story Behind the Ruling#

The Open Home Foundation's post explains why this is a genuinely technical win rather than a symbolic one. The Home Assistant community spent three years trying to ship an always-on wake word in the Android Companion app, and every attempt hit the same wall: Android blocks third-party apps from the DSP-based wake word pipeline that Google reserves for itself.

Android's wake word detection runs in two stages. A small model listens on the DSP, a dedicated low-power chip that uses a fraction of the CPU's energy, running in an isolated process that cannot send audio anywhere until the wake word is confirmed. A second, stronger model then confirms the detection on the CPU. Home Assistant was forced to run its own microWakeWord model on the CPU instead. The costs were concrete: battery drain jumped from roughly 1 percent to 15 percent, the microphone privacy indicator stayed lit permanently, and users could not have both Home Assistant and Gemini active, because Android only kept a non-default assistant's service alive if it was set as the default assistant.

The decision addresses each of those specific failures: third parties get DSP first-stage detection when hardware supports it, sandboxed confirmation, complete documentation without a commercial agreement, decoupling from the default assistant role, and concurrent wake words so "Okay Nabu" and "Hey Google" can both work on one device.

What Developers Are Saying#

The reaction splits between people who have been fighting these platform walls and people who have watched regulators try before.

The strongest enthusiasm comes from the open-source and self-hosted camp, and the Home Assistant story is doing heavy lifting. The concrete technical details in the decision - the two-stage wake word architecture, the DSP, the isolated process, the role coupling - are being read as evidence that the Commission understood the actual engineering rather than rubber-stamping a complaint.

The skeptical camp is focused on the calendar. Android 18 arrives next year and concurrent hotwords arrive in 2028, which means the most interesting capability is two major releases away. The same readers note that the certification process for the five sensitive features gives Google a legitimate-looking funnel to slow access, and that Google designs the implementation, so the risk of technically compliant but practically unusable solutions is real. Past experience with gatekeeper rulings is not obviously on the side of speed.

A third theme is scope: why eleven features and not the rest of the walled garden? Attestation, app installation, and payment access all remain Google-controlled, and several commenters argue the deeper problem is that independent vendors still cannot ship a patched, open Android phone to users in any volume, which no interoperability order directly fixes. There are also open questions about whether the same obligations will land on iOS's side, and whether AOSP builds outside the Google ecosystem inherit any of it.

Why This Matters for Developers#

This is the first major DMA interoperability decision written around the agentic use case, and it names the exact primitives an AI assistant needs on a phone: a voice in, context to read, actions to take, and resources to run on. For developers, that means three concrete things.

First, the platform APIs become reachable. App Functions, screen automation, ambient data, and on-device models stop being Gemini-only surfaces and become addressable by any assistant app that goes through certification. The "send a message", "create a note", and "schedule a meeting" actions the decision lists are exactly the primitives agentic apps have been building around on desktop, now available on Android with user consent.

Second, on-device AI gets real choice. The ruling covers access to Google's own preinstalled models, including Gemini Nano, and the right to run third-party on-device models under the same hardware and background conditions. That is meaningful for privacy-sensitive features like live translation and speech recognition that have to run locally.

Third, the economics of voice assistants change. DSP-based hotword detection means always-listening no longer costs 15 percent battery and a permanent mic indicator, which removes the practical barrier that kept third-party wake words off modern Android. If you have been waiting to ship an assistant experience because the platform made it impossible, the timeline to build for is Android 18, with concurrent hotwords to follow in Android 19.

Continue Reading#

• Android May Soon Restrict On-Device ADB - What Developers Need to Know - the other side of the platform-access coin: Google restricting developer access on Android.
• A GrapheneOS Phone Wiped Itself at the US Border - What Developers Should Know - what device control means when your phone is the thing holding your data.
• Kokoro: A Local TTS Model That Runs Entirely on CPU - the on-device voice stack third-party assistants can build on.
• Apple's LanguageModel Protocol: OS-Level Model Abstraction on iPhone and Mac - how the other major mobile platform is opening model access to developers.

Sources#

• Alphabet specification proceedings - Interoperability for AI services (European Commission DMA Developer Portal) - the final decision (DMA.100220, adopted 2026-07-16), the 11 features, timeline, and eligibility conditions.
• DMA.100220 measures (European Commission) - the measures Google must implement, PDF.
• A big win for Android interoperability (Open Home Foundation) - the Home Assistant developer's account of the wake word fight and what the ruling requires, published 2026-07-31.