Something big just happened. As the Open Home Foundation’s Android developer for Home Assistant, I was invited by the European Commission (EC) to consult on Android interoperability. The call for feedback was part of the Commission’s work under the Digital Markets Act (DMA). For anyone unfamiliar, the DMA is an EU law that defines and regulates “gatekeeper platforms” – those that offer “core” services like search engines, app stores, and messaging platforms – to make digital markets fairer and more open to competition. As you might imagine, I had plenty to say about Google’s restrictions on Android, especially the tech giant limiting wake word detection to its own Gemini assistant, a concern I surfaced in our Home Assistant 2026.3 Release Party. To put it plainly, Google had no grounds for limiting Android interoperability in the first place, other than to give itself the upper hand. We knew our community deserved better, and that’s what we told the Commission.
The result? The EC listened to us and all the other organizations that contributed. On July 16, 2026, the European Commission adopted a decision under the DMA that requires Alphabet (Google’s parent company) to open up eleven Android features, including always-on wake word detection, ambient sensor access, and screen automation – to all assistants, on equal terms.
As an EU citizen, I’m genuinely pleased to see this kind of regulation of Big Tech leveling the digital market playing field and representing real progress for users. Not only that, but it’s a real win for the Open Home Foundation: we exist to fight for privacy, choice, and sustainability in smart homes, and this outcome shows what’s possible when we advocate for our community. We already briefly covered this news in our July newsletter, but I want to take some time now to break down how we got here, what this decision says, why it matters for our community, and what it could unlock for Home Assistant and the rest of the industry.
A bit of background
For three years, our community had tried to ship an always-on wake word detection in the Android Home Assistant Companion app. We wanted users to be able to say “Okay Nabu,” and have their self-hosted Assist voice assistant answer. Yet our early attempts kept breaking. Most notably, after each reboot the device's microphone no longer picked up the wake word. So we dug into the Android source code, and lo and behold, there was a solution: but Google wasn’t letting us use it.
Android has a well-designed mechanism that lets your device listen for “Hey Google” all day, without draining your battery. Their wake word detection runs in two stages. A small model does the first detection on a DSP (digital signal processor), which is a dedicated chip that processes audio using a fraction of the power your device’s main processor (CPU) would need. This first stage runs in an isolated process blocked from the network, and can’t extract audio until a potential wake word is detected. Then the second stage uses a stronger model via the CPU to confirm the detection.
Most contemporary devices have DSPs. But Android-based devices block access to it for anyone other than Google and the manufacturer of the device. Since the wake word mechanism using the DSP simply wasn’t available to third-party apps, and developer documentation didn’t exist publicly, we used what we could to build a workaround.
From microWakeWord to macro results
Our solution was running a small microWakeWord model on the device’s CPU inside our app. This worked, but came with some big downsides:
- Battery usage would jump from roughly 1% to 15% with wake word detection enabled, since the CPU is far less efficient for this task.
- The microphone privacy indicator (the green dot) would stay on permanently, because we needed full microphone access to run detection ourselves. We actually think the indicator is the right design – the problem is that we had no way to offer the stronger guarantee Google gives itself: an isolated process that can’t send audio anywhere. Instead, you had to trust that we were handling that access responsibly. And not because a safer version isn’t technically available. But because the DSP path is arbitrarily blocked by Google for anticompetitive reasons, forcing a less secure approach that introduces privacy risks for the user.
- You would have to set Home Assistant as your default assistant, because that was the only way Android would keep our service alive across reboots. That would lock you out of Gemini and everything tied to it (and you shouldn’t have to choose).
When I was invited to share these limitations (and others) with the Commission, I didn’t hold back. Which is why we were thrilled to discover an impressively precise and technically accurate decision from the EU: it correctly describes the two-stage wake word architecture, the DSP, the isolated process, and the role coupling. The report went down to details we only figured out by reading Android's source code ourselves. Which brings us to what the ruling actually says…
A wake-up call for Google
The decision requires Google to give third parties interoperability that’s “equally effective” as what Google’s own assistant gets across eleven Android features, free of charge. For wake word detection specifically, Google must provide:
- The ability to create a custom wake word model in Android, with first-stage detection run by the DSP (when available) instead of the app
- The ability to run a second-stage validation after the DSP has potentially identified the wake word in first-stage detection
- Testing tools and complete documentation, without requiring a commercial agreement with Google
Two lines deserve a special mention. First: Google “shall not subject access to features to the app holding a default role, including the default assistant role.” That is the decoupling we discussed with the Commission. Second: wake word detection “from multiple services, including services belonging to third parties and Alphabet, are able to run concurrently.” This would let you say “Okay Nabu” to control your home without changing any defaults or having to give up using Gemini for other purposes.
Beyond wake words, the decision covers invoking assistants from the long-press home gesture, access to ambient data like the microphone and camera under the same conditions as Google, structured integration with apps (including Gmail, Calendar, and Maps), system-level controls, access to on-device AI models, and fair background execution rules. Opening up these features hasn’t been without pushback – Google itself has raised security concerns, which we’ll get into below. But with all things considered, we believe the benefits to users and the industry far outweigh the risks.
Time’s ticking
Google must ship these changes in Android 18 (the next major release), by August 1, 2027. Concurrent hotword detection – letting multiple services be triggered by voice – must be in place by Android 19, no later than August 1, 2028.
It’s worth noting the decision still relies on Google to design and implement the changes, and with that comes a risk of malicious compliance: a technically sound solution that is unusable in reality (it wouldn’t be the first time a gatekeeper wrangled its way out of a regulation). But the fine print gives grounds for hope: Google must deliver solutions that are “equally effective” on ease of use, speed, and energy consumption, publish complete documentation and testing tools, and report progress to the Commission monthly. A real win for developers, and one that makes shipping the bare minimum much harder to get away with. With that in mind, here’s what it could look like for Home Assistant.
Help us make this change stick
We’re always working hard to create the best possible experience for our Android Home Assistant users, though we’re a small team – which is why community contributions to the Android app matter so much. If you’d like to help (in line with our recently released AI policy), we’d love to hear from you. While the ideas below are just that, and don’t form part of our roadmap, your input could help unlock them in the future:
Battery-efficient wake word detection
Like we mentioned earlier, moving first-stage detection from the CPU to the DSP should increase battery efficiency significantly. Our plan is to support two methods: on newer phones with Android 18, we’ll use the phone’s low-power chip to listen for the wake word. On older phones, or those without that chip, detection will keep running as it does today. Either way, we’ll show you which method your phone is using from within the Companion app.
One phone, two assistants
Today, choosing a third-party wake word means giving up Gemini, along with calls and messages through your default assistant. Default-role decoupling and concurrent wake word access would end that: You can talk to Gemini like aways, but also say “Okay Nabu” when you want to interact with your home via Home Assistant.
Imagine if you could set different wake words for different assistants inside the app itself, like “Hey Jarvis” for your admin dashboard and “Okay Nabu” for the family. This won’t even be technically possible until 2028 when Android 19 is released (and it will take a lot of work), but it’s a nice goal to have looking ahead.
Better built-in privacy
This is the part I find most exciting. The ruling requires wake word confirmation to run in a secure, isolated process (known as sandboxing) via the DSP. This means the part of the system that controls this feature is walled off, with no way to send audio anywhere until the wake word is confirmed. I don’t want to rely on trust when it comes to something as sensitive as interactions with my voice assistant. I want to be in control, with a clear explanation of what the things I enable actually imply. Sandboxing gives us that by design: privacy enforced by the OS itself, the same secure-by-default protection Google has always had, now finally available to all.
A more capable assistant, for everyone
Sensor access isn’t the only place this equal treatment applies. The decision also requires Google to open structured integrations with its own apps – Gmail, Calendar, Maps, etc – to qualified assistants, not just Gemini. In theory, that means your assistant could draft an email, manage a calendar event, or send a text and start a call on your behalf: exactly the capabilities our users tell us they miss when they leave Gemini, and ones that could genuinely boost usability, especially for users with accessibility needs.
That same access could expand the range of sensors and controls the app already reports to Home Assistant: sound detection (smoke alarm, breaking glass, doorbell) as automation triggers, and controls like do-not-disturb or Bluetooth your assistant can actually act on, not just observe.
On the security argument
Google has pushed back on the ruling, citing security risks. It warns the decision grants third parties “sensitive and powerful device permissions,” exposing user data “without user knowledge or consent.” This framing overstates the risks in a familiar tactic: sounding the alarm on security concerns to curtail attempts for interoperability. We’d point out, as one of those third parties, that the decision already builds in the safeguards that concern calls for: Google can still require user consent, show privacy indicators, and let users revoke access per service. For the most sensitive features like health data access, it also has a policy in place via the Play Store to check security, privacy, and data minimization before any app gets access.
And to be clear, these capabilities already exist on your phone, and Google’s own services already use them, without ever asking your approval. The risk didn’t appear when the EU asked for that access to be shared more broadly – what changed is who gets to decide who has it. Whatever risks remain, like those introduced by using any smart device, should be taken seriously – just not as a veil for Google’s double-dealing.
Our view is that trust without verification isn’t a security model, and limiting these safeguards to Google alone isn’t protection. Even major AI vendors have had security incidents, Hugging Face/OpenAI among them. What does offer protection is giving users choice and transparency into security processes, along with a secure technical architecture: sandboxing, isolation, revocable permissions – enforced equally, which is what this decision requires.
It’s worth watching where Google goes next: from 2027, its developer verification program will require every Android developer to be centrally verified before their apps can even be installed – a move contested by the Keep Android Open campaign, and one we’re also skeptical about. It’s a reminder that this fight isn’t over, and neither is our work.
There every step of the way
Google must report its implementation plans to the Commission within two months, and eligibility program terms are due for public consultation by February 2027. We’ll be there for it all: to test the betas, report on whether implementation lives up to the promise, and keep you informed. In the meantime, we’ll continue doing all we can to champion smart home tech that’s private, local, and controlled by you, on your terms.