{"schema_version":"1.0","service":"Publicasta","type":"article","id":246,"slug":"android_local_voice_home_assistant_interoperability_2026_08_03","title":"An old Android phone could become a better Home Assistant voice panel — but not yet","excerpt":"Europe’s Android interoperability decision could fix a real smart-home nuisance: local wake words on phones without killing battery or replacing the default assistant.","language":"en","default_language":"en","canonical_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03?lang=en","image":{"url":"https://publicasta.com/storage/projects/14/pages/246/2026/08/9953cd1f-ec67-4108-bb8b-20f97d46b917.webp","alt":"Old Android phone used as a local smart-home voice panel"},"publisher":{"id":14,"slug":"smart_home","name":"Smarter Home","url":"https://publicasta.com/smart_home"},"author":{"name":"Anton R"},"published_at":"2026-08-03T10:15:45+00:00","updated_at":"2026-08-03T10:15:45+00:00","content_markdown":"An old Android phone on the kitchen counter should be an obvious smart-home device. It has microphones, Wi-Fi, a screen, a battery, speakers and enough compute to show a dashboard. In a Home Assistant home, the dream is simple: say “Okay Nabu”, turn on the hallway lights locally, ask for the garage door state, or run a bedtime routine without routing every command through a cloud speaker.\n\n ![Old Android phone used as a local smart-home voice panel](https://publicasta.com/storage/projects/14/pages/246/2026/08/9953cd1f-ec67-4108-bb8b-20f97d46b917.webp)\n\n Today that idea is still awkward. It is possible to experiment with Assist on Android, and Home Assistant has made impressive progress with local voice. But the always-listening, low-battery, family-friendly version is blocked by a platform detail most household users never think about: the efficient wake-word path on an Android phone is not just an app feature. It sits behind privileged operating-system access.\n\n That is why the July 31 post from the Open Home Foundation matters for smart-home users. The Foundation says the European Commission’s July 16 Digital Markets Act decision requires Alphabet to open eleven Android capabilities to third-party AI assistants on equal terms, including always-on wake-word detection, ambient sensor access and screen automation. The official European Commission specification page confirms the final decision, the eleven-feature framework, Android 18 implementation by 1 August 2027, and concurrent hotword detection in Android 19 by 1 August 2028.\n\n This is not a “go install this today” story. It is a roadmap story. If Google implements the measures in a usable way, an Android phone or wall tablet could become a much better local voice satellite for Home Assistant. If it implements them narrowly, the smart-home benefit may remain theoretical. Either way, the decision explains why a problem that looks like a missing Home Assistant setting was actually an Android interoperability problem.\n\n ## The ordinary household problem\n\n Voice control is not the fanciest part of a smart home. It is often the part that makes the system usable for everyone else.\n\n A dashboard is fine for the person who built the system. Guests, children, older relatives and carers usually need something simpler. “Turn on the kitchen lights”, “open the blinds halfway”, “start the fan for twenty minutes”, “is the back door locked?” and “good night” are natural household commands. Voice also helps when hands are full, when a phone is not nearby, or when accessibility matters more than novelty.\n\n Cloud assistants solved the convenience part first. A Nest speaker or Alexa device is easy to place in a room. The trade-off is that the microphone, speech processing, assistant account and platform rules belong to a company whose priorities are not the same as a local smart-home owner’s priorities.\n\n Home Assistant Assist tries to move that center of gravity back home. It can run local speech-to-text and text-to-speech pipelines, expose entities intentionally, and trigger automations without making the cloud the default control plane. But a local assistant still needs a way to hear its wake word in the room.\n\n That is where old Android devices look tempting. Many homes have retired phones or tablets in drawers. They already have microphones and screens. They are cheaper than buying one dedicated satellite per room. They can sit on a wall as a dashboard and, in theory, listen for a local wake word.\n\n In practice, the device can do the job only if Android lets the right app use the right low-power microphone path.\n\n ## Why wake words need special hardware\n\n A wake word is not just ordinary speech recognition. A device that listens for “Hey Google”, “Alexa” or “Okay Nabu” must listen continuously while consuming very little power and waking the main processor only when there is a plausible match.\n\n Modern phones often solve this with a two-stage design. A low-power digital signal processor, or DSP, performs first-stage detection. It watches for a small model or acoustic pattern while the main CPU remains asleep or lightly used. If the DSP thinks it heard the wake phrase, a stronger second-stage model on the CPU validates the event before the assistant starts listening to the full command.\n\n That split matters for battery. It also matters for heat, privacy indicators and background service reliability. If an app cannot use the DSP path, the workaround is to keep more of the phone awake and keep using the microphone in a way Android treats like an ordinary foreground recording service.\n\n The Open Home Foundation says Home Assistant’s Android team spent three years trying to ship always-on wake-word detection in the Companion app. The workaround used microWakeWord on the CPU. OHF says it worked, but badly enough to be unsuitable as the everyday answer: battery usage could jump from roughly 1% to 15% in their example, the Android green microphone indicator stayed visible, and Home Assistant had to become the default assistant so Android would keep the service alive across reboots.\n\n Those are not small annoyances in a household. A wall tablet that drains faster, shows a permanent mic indicator and forces users to replace Gemini or Google Assistant as the default phone assistant is not a clean local-voice product. It is a hack that proves demand.\n\n ## What the EU decision says\n\n The Commission’s official Android interoperability page says the decision was adopted on 16 July 2026 under Article 6(7) of the Digital Markets Act. It covers eleven Android features relevant for AI services and groups them around invocation, context, actions on apps and the operating system, and access to hardware and software resources.\n\n For smart-home users, the wake-word part is the headline. The Commission says alternative AI services should be able to be invoked by hotword, including when the display is off, the device is in standby, battery saving mode is active, or the user is doing something else. It also says hotwords can no longer be reserved for Google services such as Google Assistant or Gemini, and that concurrent access should allow users to use different AI services for different tasks.\n\n The same official page gives the timeline. Google must implement the measures in Android 18 by 1 August 2027 at the latest. Concurrent hotword detection, where multiple services can be triggered by voice invocation, must be implemented in Android 19 by 1 August 2028 at the latest.\n\n The page also says interoperability must be equally effective to what Google has for its own services, must not add unnecessary friction, and must not be conditioned on the AI provider holding a default role. That last point is critical for the home. A user should not have to choose between “my phone assistant” and “my house assistant”.\n\n Beyond hotwords, the same framework includes context access, structured on-device integration, app actions, screen automation, system integration, on-device models and resource access. Some of those features are less directly about lights and blinds, but they point to the same future: assistants that can act on the device and in apps with user consent instead of being artificially limited to whatever private APIs the platform owner gives itself.\n\n ## Google’s objection is not imaginary\n\n Google’s July 16 response argues that the DMA decisions risk undercutting privacy and security for Europeans by granting external apps sensitive and powerful device permissions without adequate safeguards.\n\n That concern deserves a fair reading. Always-on microphone paths, ambient sensors, app context, screen automation and system integration are not harmless toys. A malicious or sloppy app with deep device access can expose private conversations, infer routines, misuse accessibility-like automation, exfiltrate data, manipulate apps or confuse users about which assistant is listening.\n\n Smart-home people should not dismiss that as pure corporate self-interest. A home automation system often knows when people are home, which doors are open, when children sleep, how heating is configured, and which cameras or locks exist. If voice assistants get deeper OS hooks, permission design, logging, local processing boundaries, revocation and user education must be serious.\n\n The counterargument from Open Home Foundation is also practical. Blocking third-party assistants from the efficient path does not eliminate risk; it can force worse workarounds. A CPU-based microphone service that drains battery and leaves a permanent mic indicator is not automatically more private. Requiring Home Assistant to become the default assistant just to survive reboot is not a privacy win if the household then loses the assistant choice it wanted.\n\n The better answer is not “give every app everything.” It is equal, documented, permissioned access with clear consent, hardware-backed limits, testing tools, review mechanisms and the ability to revoke access. The Commission’s page says user consent and privacy/security law still apply, and that Google may use strictly necessary and proportionate safeguards. The details will decide whether this becomes useful or messy.\n\n ## Why this is a smart-home story, not just a regulatory story\n\n The smartest home is often the one that stays boring. Lights turn on. Heating runs. A door sensor tells the truth. A button still works when the internet is down. Voice control should fit that pattern.\n\n If the microphone lives in a cloud speaker, local automation is never fully local. The wake word, account routing and assistant availability depend on outside services. If the only good microphone path on an Android phone belongs to Google’s assistant, a self-hosted smart home is still borrowing a gatekeeper’s front door.\n\n Opening the wake-word path could make old phones and tablets useful in a new way. A retired phone in the utility room could answer local commands without a cloud wake word. A kitchen wall tablet could remain a dashboard and also serve as a voice satellite. A guest room could have a cheap device that controls only exposed entities. An accessibility setup could rely on a local phrase without requiring the user to learn a dashboard.\n\n This matters especially for apartments and ordinary houses. Not everyone wants to install ceiling microphones or build ESP32 satellites for every room. Many people want one practical device in the kitchen and one by the bed. Android hardware is already there.\n\n But the decision does not magically make every old phone perfect. DSP support depends on hardware and OEM implementation. Android version updates vary wildly. EU interoperability obligations do not automatically mean every device worldwide will expose the same features at the same time. A phone with a dead battery, weak microphone, aggressive vendor battery management or no Android 18 update will not become a great voice satellite because a regulation exists.\n\n ## What you can do today\n\n If you are building a Home Assistant home in 2026, do not buy Android tablets solely because of this future wake-word path. Treat Android DSP access as a feature to watch, not a buying requirement.\n\n Use push-to-talk Assist where it makes sense. A dashboard button, a lock-screen shortcut or a physical control can be more reliable than an always-on experiment. For family members who dislike dashboards, put the most important scenes on visible buttons or NFC tags.\n\n Consider dedicated local voice satellites if voice is important now. Home Assistant’s voice documentation points users toward ESPHome-based satellites, ESP32-S3 devices, the Home Assistant Voice Preview Edition, Atom Echo-style projects and other local pipelines. These devices are not as polished as mass-market cloud speakers, but they can be designed around local wake words instead of fighting Android’s phone-assistant model.\n\n Use old Android phones and tablets as dashboards first. They can show room controls, camera snapshots, energy views, music controls or simple scenes. If you experiment with wake-word detection, expect trade-offs: battery, charging, screen sleep, microphone indicators, reboot behavior, background restrictions and household acceptance.\n\n Keep critical routines available without voice. A local assistant is useful, but the front door, night lighting, heating safety and emergency routines should not depend on a microphone hearing correctly. Physical switches, schedules and automations are still the backbone.\n\n Be conservative with permissions. A device used as a voice panel should not also hold unnecessary personal accounts, work email, banking apps or long-lived tokens. If you repurpose an old phone, factory reset it, use a limited account, lock down notifications and avoid turning the wall tablet into a credential museum.\n\n ## What to watch in 2027 and 2028\n\n The first thing to watch is Android 18. The Commission says the measures must be in the next major Android release and by 1 August 2027. For Home Assistant users, the question is not just whether an API exists. It is whether the Companion app can use it without becoming the default assistant, whether documentation and testing tools are usable, whether OEMs expose the DSP path consistently, and whether battery behavior is close to what Google’s own assistant gets.\n\n The second milestone is Android 19 and concurrent hotword detection by 1 August 2028. This is the part that makes the “one phone, two assistants” idea realistic. A household may want Gemini for general phone tasks and Home Assistant Assist for the house. If only one assistant can listen, the user still has to choose a winner. If multiple wake words can coexist with clear UI and permissions, the phone becomes more like a shared control surface.\n\n The third issue is geography. The decision is European. Google may implement globally because maintaining separate systems is costly or because the architecture becomes part of Android. Or it may limit availability where the law requires it. Readers outside the EU should not assume the feature will arrive on their device at the same time.\n\n The fourth issue is trust. A local voice assistant is more private only if it actually stays local for the wake word, command processing and automation path you care about. “Works with Home Assistant” is not the same as “no cloud ever.” Check the pipeline: wake-word detection, speech-to-text, intent processing, text-to-speech, fallback LLMs and remote access.\n\n ## A practical checklist before turning a phone into a voice satellite\n\n Ask whether the device will receive Android 18 or 19. If not, it may remain a dashboard-only device.\n\n Check whether the microphone is good in the room where it will sit. Kitchens and bathrooms are noisy. A bad location creates more false negatives than any software setting can fix.\n\n Decide what entities the assistant can control. Expose lights, climate and safe scenes first. Be careful with locks, alarms, garage doors and security modes.\n\n Give household members a visible privacy rule. People should know what phrase wakes the assistant, whether audio stays local, what the microphone indicator means, and how to disable it.\n\n Make charging boring. A wall panel that slowly drains or overheats will be removed. Use safe chargers and avoid swollen old batteries.\n\n Keep a non-voice fallback in every important room. A smart home that requires speaking to it is not accessible to everyone all the time.\n\n Review logs and permissions periodically. Local automation does not mean “install and forget.”\n\n ## The bottom line\n\n The EU Android interoperability decision could make a normal Android device far more useful in a local smart home. The key phrase is “could.” The valuable part is not regulation for its own sake; it is the possibility that Home Assistant Assist can use the same kind of low-power wake-word path that Google’s own assistant enjoys, without forcing users to give up their default phone assistant.\n\n For now, the practical advice is simple. Build today’s smart home around reliable local controls, dashboards, dedicated satellites and fallback switches. Do not buy hardware for a feature that depends on Android 18, Android 19, OEM support and Google’s implementation quality. But do watch this closely. If the implementation is real, the old Android phone in the drawer may finally become what smart-home users always wanted it to be: a private, low-power, local voice panel for the house.","available_translations":[{"language":"ar","title":"هاتف Android قديم كلوحة صوتية لـ Home Assistant: واعد، لكن ليس الآن","html_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03?lang=ar","markdown_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.md?lang=ar","json_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/smart_home/articles/android_local_voice_home_assistant_interoperability_2026_08_03?lang=ar"},{"language":"de","title":"Altes Android als Home-Assistant-Sprachpanel: vielversprechend, aber noch nicht jetzt","html_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03?lang=de","markdown_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.md?lang=de","json_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/smart_home/articles/android_local_voice_home_assistant_interoperability_2026_08_03?lang=de"},{"language":"en","title":"An old Android phone could become a better Home Assistant voice panel — but not yet","html_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03?lang=en","markdown_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.md?lang=en","json_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/smart_home/articles/android_local_voice_home_assistant_interoperability_2026_08_03?lang=en"},{"language":"es","title":"Un viejo Android como panel de voz para Home Assistant: prometedor, pero no todavía","html_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03?lang=es","markdown_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.md?lang=es","json_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/smart_home/articles/android_local_voice_home_assistant_interoperability_2026_08_03?lang=es"},{"language":"fr","title":"Un vieux Android comme panneau vocal Home Assistant: prometteur, mais pas encore","html_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03?lang=fr","markdown_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.md?lang=fr","json_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/smart_home/articles/android_local_voice_home_assistant_interoperability_2026_08_03?lang=fr"},{"language":"pl","title":"Stary Android jako panel głosowy Home Assistant: obiecujące, ale jeszcze nie teraz","html_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03?lang=pl","markdown_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.md?lang=pl","json_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/smart_home/articles/android_local_voice_home_assistant_interoperability_2026_08_03?lang=pl"},{"language":"ru","title":"Старый Android‑телефон как голосовая панель Home Assistant: почему ещё рано","html_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03?lang=ru","markdown_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.md?lang=ru","json_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/smart_home/articles/android_local_voice_home_assistant_interoperability_2026_08_03?lang=ru"},{"language":"zh","title":"旧 Android 手机做 Home Assistant 语音面板：有希望，但还不是现在","html_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03?lang=zh","markdown_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.md?lang=zh","json_url":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/smart_home/articles/android_local_voice_home_assistant_interoperability_2026_08_03?lang=zh"}],"_links":{"self":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.json?lang=en","api":"https://publicasta.com/api/public/v1/channels/smart_home/articles/android_local_voice_home_assistant_interoperability_2026_08_03?lang=en","html":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03?lang=en","canonical":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03?lang=en","markdown":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.md?lang=en","json":"https://publicasta.com/smart_home/android_local_voice_home_assistant_interoperability_2026_08_03.json?lang=en","channel":"https://publicasta.com/api/public/v1/channels/smart_home","channel_articles":"https://publicasta.com/api/public/v1/channels/smart_home/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}