Algo grande acabou de acontecer. Como desenvolvedor Android da Fundação Open Home, fui convidado pela Comissão Europeia (CE) para consultar sobre interoperabilidade do Android. O pedido por feedback faz parte do trabalho da Comissão sob a Lei de Mercados Digitais (DMA). Para quem não conhece, a DMA é uma lei da UE que define e regula “plataformas gatekeeper” – aquelas que oferecem serviços “críticos”, como motores de busca, lojas de aplicativos e plataformas de mensagens – para tornar os mercados digitais mais justos e abertos à concorrência. Como você pode imaginar, eu tinha muito a dizer sobre as restrições do Google no Android, especialmente quando o gigante da tecnologia limita a detecção de palavras-chave apenas ao seu próprio assistente Gemini, uma preocupação que levantamos em nosso evento de lançamento do Home Assistant 2026.3. Para ser honesto, o Google não tinha justificativa para limitar a interoperabilidade do Android além de dar vantagem à si mesmo. Sabíamos que nossa comunidade merecia mais e é isso que dissemos à Comissão.
O resultado? A CE ouviu nossas opiniões e as das outras organizações que contribuíram. Em 16 de julho de 2026, a Comissão Europeia adotou uma decisão sob a DMA que exige o Alphabet (a empresa-mãe do Google) abrir onze recursos do Android, incluindo a detecção de palavras-chave em tempo integral, acesso a sensores ambientais e automação da tela – para todos os assistentes, sob termos iguais.
Como cidadão europeu, estou genuinamente feliz em ver esse tipo de regulação da Big Tech nivelando o campo de jogo dos mercados digitais e representando um progresso real para os usuários. Além disso, é uma grande vitória para a Fundação Open Home: existimos para lutar por privacidade, escolha e sustentabilidade em casas inteligentes, e esse resultado mostra o que é possível quando defendemos nossa comunidade. Já mencionamos essa notícia brevemente em nosso boletim de julho, mas quero dedicar algum tempo agora para explicar como chegamos a esse ponto, o que essa decisão significa, por que é importante para nossa comunidade e o que pode desbloquear para o Home Assistant e o resto da indústria.
Um pouco de contexto
Por três anos, nossa comunidade tentou lançar uma detecção de palavras-chave em tempo integral no aplicativo Android Home Assistant Companion. Queríamos que os usuários pudessem dizer “Okay Nabu” e tivessem seu assistente de voz auto-hospedado Assist responder. No entanto, nossos primeiros esforços continuavam quebrando. Notavelmente, após cada reinicialização do dispositivo, o microfone não mais captava a palavra-chave. Então, mergulhamos no código-fonte do Android e, para nossa surpresa, havia uma solução: mas o Google não nos deixou usá-la.
O Android tem um mecanismo bem projetado que permite ao seu dispositivo ouvir “Hey Google” durante todo o dia sem esgotar a bateria. Sua detecção de palavras-chave funciona em duas etapas. Um modelo pequeno faz a primeira detecção em um DSP (processador de sinal digital), que é uma placa dedicada que processa áudio usando uma fração da energia necessária para o processador principal do dispositivo (CPU). Essa primeira etapa roda em um processo isolado bloqueado da rede e não pode extrair áudio até detectar uma palavra-chave potencial. Então a segunda etapa usa um modelo mais forte via CPU para confirmar a detecção.
A maioria dos dispositivos atuais possui DSPs. No entanto, os dispositivos baseados no Android bloqueiam o acesso a eles para qualquer pessoa além da Google e do fabricante do dispositivo. Como o mecanismo de palavra-chave de despertar usando o DSP simplesmente não estava disponível para aplicativos de terceiros e a documentação do desenvolvedor não existia publicamente, usamos o que tínhamos para criar uma solução alternativa.
Do microWakeWord aos resultados macro
Nossa solução consistiu em executar um pequeno modelo microWakeWord no CPU do dispositivo dentro de nosso aplicativo. Isso funcionou, mas veio com algumas desvantagens significativas:
- O uso da bateria aumentaria de cerca de 1% para 15% com a detecção da palavra-chave ativada, já que o CPU é muito menos eficiente para essa tarefa.
- O indicador de privacidade do microfone (o ponto verde) ficaria ligado permanentemente, pois precisávamos de acesso completo ao microfone para executar a detecção. Na verdade, achamos que o indicador é o design correto – o problema é que não tínhamos nenhuma maneira de oferecer a garantia mais forte que a Google dá a si mesma: um processo isolado que não pode enviar áudio para lugar algum. Em vez disso, você teria que confiar que estávamos lidando com esse acesso de forma responsável. E não porque uma versão mais segura não é tecnicamente disponível. Mas porque o caminho do DSP é arbitrariamente bloqueado pela Google por razões anticompetitivas, forçando uma abordagem menos segura que introduz riscos à privacidade do usuário.
- Você teria que definir o Home Assistant como seu assistente padrão, pois era a única maneira de o Android manter nosso serviço ativo após reinicializações. Isso bloquearia você da Gemini e de tudo relacionado (e você não deveria precisar escolher).
Quando fui convidado para compartilhar essas limitações (e outras) com a Comissão, eu não hesitei em ser transparente. É por isso que ficamos extremamente animados ao descobrir uma decisão da UE impressionantemente precisa e tecnicamente precisa: ela descreve corretamente a arquitetura de duas etapas para a palavra-chave de despertar, o DSP, o processo isolado e o papel de acoplamento. O relatório chegou aos detalhes que só descobrimos lendo o código-fonte do Android nós mesmos. Isso nos leva ao que a decisão realmente diz...
Um alerta para a Google
A decisão exige que a Google forneça interoperabilidade “igualmente eficaz” para terceiros em onze recursos do Android, sem custo algum. Para a detecção de palavra-chave específica, a Google deve fornecer:
- A capacidade de criar um modelo personalizado de palavra-chave no Android, com a primeira etapa da detecção executada pelo DSP (quando disponível) em vez do aplicativo
- A capacidade de executar uma segunda validação após o DSP potencialmente identificar a palavra-chave na primeira etapa de detecção
- Ferramentas de teste e documentação completa, sem exigir um acordo comercial com a Google
Duas linhas merecem uma menção especial. Primeiro: a Google “não deve submeter o acesso aos recursos ao aplicativo mantendo um papel padrão, incluindo o papel de assistente padrão.” Isso é o desacoplamento que discutimos com a Comissão. Segundo: a detecção da palavra-chave “de múltiplos serviços, incluindo serviços pertencentes a terceiros e ao Alphabet, podem ser executados simultaneamente.” Isso permitiria que você dissesse “Okay Nabu” para controlar sua casa sem precisar alterar quaisquer padrões ou ter que abrir mão do uso da Gemini para outros propósitos.
Além das palavras-chave, a decisão abrange o acionamento de assistentes por meio do gesto long-press na tela inicial, acesso aos dados ambientais como microfone e câmera sob as mesmas condições que a Google, integração estruturada com aplicativos (incluindo Gmail, Calendário e Maps), controles no nível do sistema, acesso a modelos de IA no dispositivo e regras justas para execução em segundo plano. Abrir esses recursos não foi sem resistência – mesmo a própria Google levantou preocupações de segurança, sobre as quais falaremos abaixo. Mas considerando tudo, acreditamos que os benefícios aos usuários e à indústria superam os riscos.
O tempo está correndo
A Google deve enviar essas alterações no Android 18 (a próxima versão principal), até 1º de agosto de 2027. A detecção simultânea de palavras-chave – permitindo que múltiplos serviços sejam acionados por voz – deve estar em vigor no Android 19, não mais tarde do que 1º de agosto de 2028.
É importante observar que a decisão ainda depende de Google para projetar e implementar as mudanças, o que traz um risco de conformidade maliciosa: uma solução técnicamente sólida que é inutilizável na prática (não seria a primeira vez que um guardião encontrou uma forma de escapar de uma regulamentação). Mas os detalhes da decisão oferecem esperança: Google deve entregar soluções que sejam “equivalentemente eficazes” em termos de facilidade de uso, velocidade e consumo de energia, publicar documentação completa e ferramentas de teste, e relatar o progresso à Comissão mensalmente. Uma vitória real para os desenvolvedores, e uma que torna a implementação do mínimo necessário muito mais difícil.
Ajude-nos a fazer essa mudança permanecer
Estamos sempre trabalhando arduamente para criar a melhor experiência possível para nossos usuários de Home Assistant no Android, embora sejamos uma equipe pequena – é por isso que as contribuições da comunidade para o app Android são tão importantes. Se você gostaria de ajudar (de acordo com nossa política de IA recentemente lançadaAI policy), ficaremos felizes em ouvir suas ideias. Embora as ideias abaixo sejam apenas isso, e não façam parte de nossa rota de desenvolvimento, seu feedback pode ajudar a liberá-las no futuro:
Detectação eficiente de palavra-chave para economia de bateria
Como mencionamos anteriormente, mover a detecção inicial do CPU para o DSP deve aumentar significativamente a eficiência da bateria. Nosso plano é suportar dois métodos: em telefones mais novos com Android 18, usaremos o chip de baixo consumo de energia do telefone para escutar pela palavra-chave. Em telefones mais antigos ou sem esse chip, a detecção continuará como hoje. De qualquer forma, mostraremos qual método seu telefone está usando dentro do aplicativo Companion.
Um telefone, dois assistentes
Agora, escolher uma palavra-chave de terceiros significa abandonar o Gemini, junto com chamadas e mensagens através do seu assistente padrão. A desconexão da função padrão e a detecção simultânea de palavras-chave acabariam com isso: Você pode falar com o Gemini como sempre, mas também dizer “Okay Nabu” quando quiser interagir com sua casa via Home Assistant.
Imagine se você pudesse definir diferentes palavras-chave para diferentes assistentes dentro do próprio aplicativo, como “Hey Jarvis” para seu painel administrativo e “Okay Nabu” para a família. Isso não será tecnicamente possível até 2028 quando o Android 19 for lançado (e levará muito trabalho), mas é um objetivo legal de se ter à frente.
Melhor privacidade embutida
Esta é a parte que eu acho mais emocionante. A decisão exige que a confirmação da palavra-chave seja executada em um processo seguro e isolado (conhecido como sandboxing) via DSP. Isso significa que a parte do sistema que controla essa função está separada, sem nenhuma maneira de enviar áudio para qualquer lugar até que a palavra-chave seja confirmada. Não quero confiar na confiança quando se trata de algo tão sensível quanto interações com meu assistente de voz. Quero estar no controle, com uma explicação clara do que as coisas que eu ativo realmente implicam. O sandboxing nos dá isso por design: privacidade impulsionada pelo próprio sistema operacional, a mesma proteção padrão segura que o Google sempre teve, agora finalmente disponível para todos.
Um assistente mais capaz, para todos
O acesso aos sensores não é o único lugar onde essa tratamento igual se aplica. A decisão também exige que o Google abra integrações estruturadas com seus próprios aplicativos – Gmail, Calendário, Maps, etc – a assistentes qualificados, e não apenas ao Gemini. Teoricamente, isso significa que seu assistente poderia redigir um email, gerenciar um evento no calendário ou enviar uma mensagem de texto e iniciar uma chamada em seu nome: exatamente as capacidades que nossos usuários nos dizem que eles sentem falta quando deixam o Gemini, e algumas que realmente poderiam aumentar a usabilidade, especialmente para usuários com necessidades de acessibilidade.
A mesma acesso também pode expandir o alcance dos sensores e controles que o aplicativo já relata ao Home Assistant: detecção de som (alarme de incêndio, vidro quebrado, campainha) como gatilhos de automação, e controles como não perturbe ou Bluetooth que seu assistente pode realmente agir em vez de observar.
Sobre o argumento de segurança
A Google se opôs à decisão, citando riscos de segurança. Alega que a decisão concede a terceiros ‘permissões sensíveis e poderosas do dispositivo’, expor dados dos usuários ‘sem conhecimento ou consentimento’. Esta abordagem exagera os riscos em uma tática familiar: alertar sobre preocupações de segurança para limitar tentativas de interoperabilidade. Como um desses terceiros, apontamos que a decisão já incorpora as salvaguardas que essas preocupações exigem: a Google ainda pode exigir o consentimento do usuário, mostrar indicadores de privacidade e permitir que os usuários revoguem o acesso por serviço. Para recursos mais sensíveis, como acesso aos dados de saúde, também há uma política em vigor via loja Play para verificar segurança, privacidade e minimização de dados antes que qualquer aplicativo tenha acesso.
E é claro, essas capacidades já existem no seu telefone e os próprios serviços da Google as usam sem pedir sua aprovação. O risco não surgiu quando a UE solicitou que esse acesso fosse compartilhado mais amplamente – o que mudou foi quem decide quem tem acesso. Qualquer risco restante, como aqueles introduzidos pelo uso de qualquer dispositivo inteligente, deve ser levado a sério – apenas não como um véu para os jogos duplos da Google.
Nossa visão é que confiança sem verificação não é um modelo de segurança e limitar essas salvaguardas à Google sozinha não é proteção. Mesmo grandes fornecedores de IA já tiveram incidentes de segurança, como Hugging Face/OpenAI. O que oferece proteção é dar aos usuários escolha e transparência sobre os processos de segurança, junto com uma arquitetura técnica segura: sandboxing, isolamento, permissões revogáveis – aplicadas igualmente, o que esta decisão exige.
É importante observar onde a Google vai em seguida: a partir de 2027, seu programa de verificação para desenvolvedores exigirá que todos os desenvolvedores do Android sejam verificados centralmente antes que seus aplicativos possam ser instalados – um movimento contestado pela campanha Keep Android Open e algo sobre o qual também somos céticos. É uma lembrança de que essa luta não acabou, nem nosso trabalho.
Acompanhando em cada passo
A Google deve apresentar seus planos de implementação à Comissão dentro de dois meses e os termos do programa de elegibilidade devem ser submetidos a consulta pública até fevereiro de 2027. Estaremos lá para tudo: testando as versões beta, relatando se a implementação vive à altura da promessa e mantendo você informado. Enquanto isso, continuaremos fazendo tudo o que pudermos para defender tecnologia doméstica inteligente que é privada, local e controlada por você, nas suas próprias condições.