A big win for Android interoperability – Open Home Foundation

A big win for Android interoperability

Google gatekept key Android features, and the European Commission asked what we thought about it. Now Alphabet must open 11 Android features to all.

Friday, July 31, 2026 · 9 minute read<br>Timothy Nibeaudeau

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...