For about a week last winter, my phone could hear me. I’d enabled wake word detection in the Home Assistant Companion app, said “Okay Nabu” at my pocket, and watched my self-hosted Assist pipeline answer without a single packet leaving my network. It felt like the finish line of the whole local-voice project. Then I looked at my battery stats, saw the microphone indicator glowing like a tiny green accusation all day, and turned it off again.
I assumed the feature was just immature. It turns out the feature was sabotaged — not by the Home Assistant developers, but by the platform they were building on. On July 31, the Open Home Foundation published a post by Timothy Nibeaudeau, their Android developer, explaining exactly why third-party wake words on Android have always been terrible, and why that’s about to change. The European Commission, acting under the Digital Markets Act, adopted a decision on July 16 that forces Google to open eleven Android features — including always-on wake word detection — to all assistants, on equal terms, free of charge.
This is the most consequential smart-home news of the summer, and it didn’t come from a product launch. It came from a regulator.
Why “Okay Nabu” ate my battery and “Hey Google” didn’t
The technical background in the OHF post is worth reading in full, but here’s the short version. Android has an elegant two-stage system for wake word detection. The first stage runs on a DSP — a dedicated low-power audio chip that most modern phones already have — inside an isolated process that’s blocked from the network and can’t extract audio until a potential wake word is detected. Only then does the second stage wake the CPU to confirm. That’s why your phone can listen for “Hey Google” all day and barely sip power.
The catch: that DSP path was reserved for Google and device manufacturers. No public documentation, no third-party access. So the Home Assistant app had to run its microWakeWord model on the main CPU instead. The consequences were exactly what I experienced: battery drain jumping from roughly 1% to 15%, a permanently lit microphone indicator (because the app needed full mic access, with no way to offer the sandboxed, network-isolated guarantee Google gives itself), and the requirement to set Home Assistant as your default assistant — locking you out of Gemini entirely — just to keep the service alive across reboots.
I find the privacy point the most galling. The green dot made the honest, open-source implementation look creepier than Google’s own, when the reality was inverted: Google’s version runs in a locked room the OS provides, and everyone else was forced to stand in the hallway holding an open microphone. The insecure architecture wasn’t a technical necessity. It was a policy choice by the gatekeeper.
What the Commission actually ordered
The decision requires interoperability that is “equally effective” as what Google’s own assistant gets — explicitly covering ease of use, speed, and energy consumption, with complete documentation and testing tools, and no commercial agreement required. For wake words specifically: custom models with first-stage detection on the DSP, second-stage validation, and — this is the line that matters for daily life — the decision states that Google “shall not subject access to features to the app holding a default role, including the default assistant role.”
In other words: you keep Gemini as your default assistant for whatever you use it for, and your phone also listens for “Okay Nabu” to talk to your own house. No more either/or. Concurrent wake words from multiple services are mandated too, on a longer timeline.
Beyond voice, the eleven features include ambient sensor access, invoking assistants from the long-press gesture, structured integration with Gmail, Calendar and Maps, system-level controls, access to on-device AI models, and fair background execution rules. For a Home Assistant user, the sensor piece is quietly exciting: sound events like a smoke alarm or breaking glass as automation triggers, and controls like do-not-disturb that the companion app could act on rather than just observe.
The timelines are long, and that’s the honest part
Now the cold water. Google must ship these changes in Android 18, by August 1, 2027. Concurrent hotword detection — multiple assistants triggered by voice at once — gets until Android 19, no later than August 1, 2028. So nothing on my phone changes this year, and the “Hey Jarvis for the admin dashboard, Okay Nabu for the family” future the OHF sketches is realistically two-plus years out, and only on phones new enough to get those releases.
There’s also the malicious-compliance risk, which the OHF names openly: the decision relies on Google to design the implementation, and gatekeepers have a rich history of shipping technically-compliant solutions that are unusable in practice. The counterweights are the “equally effective” standard, mandatory documentation, and monthly progress reports to the Commission. I’d rate the odds of a genuinely good implementation as decent but not certain — Google is publicly unhappy about the ruling, framing it as a security risk, while simultaneously planning a developer verification program for 2027 that would centrally gate which apps can be installed at all. The fight over who controls your pocket computer is not over.
Why I care, sitting in Switzerland with a server in the closet
A fair objection: I’m not in the EU, and my voice pipeline already runs locally on the EliteDesk. Why does an EU competition ruling matter to my setup? Because platform changes like this don’t get built twice. When Google is forced to open the DSP path in Android 18, that API ships worldwide — the same way USB-C didn’t stay a European charging port. Switzerland gets the benefits of the DMA the same way it gets the benefits of GDPR-hardened privacy policies: as a spillover.
And the deeper reason: voice has been the weakest link in the local-first story. I can run Whisper and Piper on my own hardware, keep every automation offline, and still lose the last metre — the device in my pocket refuses to listen for my assistant without punishing me for it. This ruling fixes the last metre. Not with a workaround, not with a companion-app hack, but at the OS level, with the same sandboxed architecture Google always reserved for itself.
It also validates something I believe about this hobby: the Open Home Foundation consulting for the European Commission — and the final decision describing the two-stage DSP architecture with details the OHF only learned by reading Android source code — shows that the community around a self-hosted home server is now technically credible enough to shape platform regulation. That’s a long way from flashing ESP boards in a Discord thread.
My plan: nothing, for now. The wake word toggle in my companion app stays off, the wall-mounted Voice PE speakers keep doing the always-listening work at home, and I’ll revisit the phone in late 2027 when Android 18 betas show what Google’s compliance actually looks like. The OHF has promised to test the betas and report honestly. Based on their track record, I believe them — and I’ll be reading.
Primary sources: the Open Home Foundation’s write-up, the European Commission’s specification decision, and Google’s response.
Leave a Reply