Android: Interoperabilidad Unificada

Android: Interoperabilidad Unificada

La Comisión Europea Impulsa un Futuro Más Abierto para los Asistentes en Android

Un avance significativo ha tenido lugar en el ecosistema de Android, con repercusiones directas para los usuarios de dispositivos inteligentes y desarrolladores. Como desarrollador Android para la Open Home Foundation y Home Assistant, fui invitado por la Comisión Europea (CE) a participar en consultas sobre la interoperabilidad de Android. Esta solicitud de retroalimentación formó parte del trabajo de la Comisión bajo la Ley de Mercados Digitales (DMA, por sus siglas en inglés). Para aquellos no familiarizados, la DMA es una legislación de la Unión Europea que define y regula las “plataformas guardianas” —aquellas que ofrecen servicios “centrales” como motores de búsqueda, tiendas de aplicaciones y plataformas de mensajería— con el objetivo de crear mercados digitales más justos y abiertos a la competencia.

Como era de esperar, tuve mucho que aportar sobre las restricciones que Google imponía en Android, especialmente la limitación de la detección de palabras clave de activación a su propio asistente Gemini. Esta preocupación ya la había compartido durante la fiesta de lanzamiento de Home Assistant 2026.3. En términos claros, Google no tenía justificación para restringir la interoperabilidad de Android, más allá de otorgarse a sí mismo una ventaja competitiva. Sabíamos que nuestra comunidad merecía algo mejor, y eso fue precisamente lo que comunicamos a la Comisión.

¿El resultado? La CE nos escuchó, junto con todas las demás organizaciones que contribuyeron. El 16 de julio de 2026, la Comisión Europea adoptó una decisión bajo la DMA que obliga a Alphabet (la empresa matriz de Google) a abrir once funciones de Android, incluida la detección de palabras clave de activación siempre activa, el acceso a sensores ambientales y la automatización de pantalla, a todos los asistentes en igualdad de condiciones.

Como ciudadano de la UE, me siento genuinamente complacido al ver este tipo de regulación sobre las grandes tecnológicas, que nivela el campo de juego en el mercado digital y representa un progreso real para los usuarios. Más allá de eso, es una victoria para la Open Home Foundation: nuestra misión es luchar por la privacidad, la elección y la sostenibilidad en los hogares inteligentes, y este resultado demuestra lo que es posible cuando defendemos a nuestra comunidad. Ya cubrimos brevemente esta noticia en nuestro boletín de julio, pero ahora quiero dedicar tiempo a desglosar cómo llegamos hasta aquí, qué implica esta decisión, por qué es importante para nuestra comunidad y qué podría desbloquear para Home Assistant y el resto de la industria.

Antecedentes: La Lucha por la Detección de Palabras Clave en Android

Durante tres años, nuestra comunidad intentó implementar una detección de palabras clave de activación siempre activa en la aplicación Companion de Home Assistant para Android. Nuestro objetivo era que los usuarios pudieran decir “Okay Nabu” y que su asistente de voz autoalojado, Assist, respondiera. Sin embargo, nuestros primeros intentos seguían fallando. Notablemente, después de cada reinicio, el micrófono del dispositivo dejaba de detectar la palabra clave. Así que investigamos el código fuente de Android y, para nuestra sorpresa, encontramos una solución: pero Google no nos permitía utilizarla.

Android cuenta con un mecanismo bien diseñado que permite a tu dispositivo escuchar “Hey Google” durante todo el día, sin agotar la batería. Su detección de palabras clave de activación funciona en dos etapas. Un modelo pequeño realiza la primera detección en un DSP (procesador de señal digital), que es un chip dedicado que procesa audio utilizando una fracción de la potencia que necesitaría el procesador principal (CPU) de tu dispositivo. Esta primera etapa se ejecuta en un proceso aislado, bloqueado de la red, y no puede extraer audio hasta que se detecta una posible palabra clave. Luego, la segunda etapa utiliza un modelo más robusto a través de la CPU para confirmar la detección.

La mayoría de los dispositivos contemporáneos disponen de DSPs. Sin embargo, los dispositivos basados en Android bloquean el acceso a estos chips a cualquier persona que no sea Google y el fabricante del dispositivo. Dado que el mecanismo de palabras clave de activación que utiliza el DSP simplemente no estaba disponible para aplicaciones de terceros, y la documentación para desarrolladores no existía públicamente, utilizamos lo que teníamos a mano para construir una solución alternativa.

De microWakeWord a Resultados Macro: El Desafío de la Detección con la CPU

Nuestra solución consistió en ejecutar un pequeño modelo microWakeWord en la CPU del dispositivo dentro de nuestra aplicación. Esto funcionó, pero conllevó algunas desventajas significativas:

• Consumo de Batería: El uso de la batería se disparaba de aproximadamente un 1% a un 15% con la detección de palabras clave activada, ya que la CPU es mucho menos eficiente para esta tarea.
• Indicador de Privacidad del Micrófono: El indicador de privacidad del micrófono (el punto verde) permanecía encendido permanentemente, ya que necesitábamos acceso completo al micrófono para realizar la detección nosotros mismos. Creemos que el indicador es el diseño correcto; el problema es que no teníamos forma de ofrecer la garantía más sólida que Google se otorga a sí misma: un proceso aislado que no puede enviar audio a ningún lugar. En su lugar, tenías que confiar en que nosotros manejábamos ese acceso de manera responsable. Y no porque una versión más segura no fuera técnicamente disponible, sino porque la ruta del DSP está arbitrariamente bloqueada por Google por razones anticompetitivas, forzando un enfoque menos seguro que introduce riesgos de privacidad para el usuario.
• Configuración del Asistente Predeterminado: Debías configurar Home Assistant como tu asistente predeterminado, ya que era la única forma en que Android mantendría nuestro servicio activo después de los reinicios. Esto te dejaría fuera de Gemini y de todo lo asociado a él (y no deberías tener que elegir).

Cuando fui invitado a compartir estas limitaciones (y otras) con la Comisión, no me guardé nada. Por eso nos emocionó descubrir una decisión impresionantemente precisa y técnicamente rigurosa de la UE: describe correctamente la arquitectura de detección de palabras clave en dos etapas, el DSP, el proceso aislado y el acoplamiento de roles. El informe llegaba a detalles que solo descubrimos al leer nosotros mismos el código fuente de Android. Lo que nos lleva a lo que dice realmente la sentencia…

Una Llamada de Atención para Google: El Impacto de la Decisión de la DMA

La decisión exige que Google proporcione a terceros una interoperabilidad “igual de eficaz” que la que recibe el propio asistente de Google en once funciones de Android, de forma gratuita. Específicamente para la detección de palabras clave de activación, Google debe proporcionar:

• La capacidad de crear un modelo de palabra clave de activación personalizado en Android, con la detección de primera etapa ejecutada por el DSP (cuando esté disponible) en lugar de la aplicación.
• La capacidad de ejecutar una validación de segunda etapa después de que el DSP haya identificado potencialmente la palabra clave en la detección de primera etapa.
• Herramientas de prueba y documentación completa, sin requerir un acuerdo comercial con Google.

Dos frases merecen una mención especial. Primera: Google “no someterá el acceso a las funciones a que la aplicación ostente un rol predeterminado, incluido el rol de asistente predeterminado”. Este es el desacoplamiento que discutimos con la Comisión. Segunda: la detección de palabras clave de activación “de múltiples servicios, incluidos los servicios que pertenecen a terceros y a Alphabet, podrán ejecutarse simultáneamente”. Esto permitiría decir “Okay Nabu” para controlar tu hogar sin cambiar ninguna configuración predeterminada ni tener que renunciar a usar Gemini para otros propósitos.

Más allá de las palabras clave de activación, la decisión abarca la invocación de asistentes desde el gesto de mantener presionado el botón de inicio, el acceso a datos ambientales como el micrófono y la cámara bajo las mismas condiciones que Google, la integración estructurada con aplicaciones (incluidos Gmail, Calendar y Maps), los controles a nivel de sistema, el acceso a modelos de IA en el dispositivo y reglas justas de ejecución en segundo plano. La apertura de estas funciones no ha estado exenta de oposición; Google mismo ha planteado preocupaciones de seguridad, que analizaremos a continuación. Pero, considerando todo, creemos que los beneficios para los usuarios y la industria superan con creces los riesgos.

El Tiempo Corre: Plazos y Desafíos para la Implementación

Google debe implementar estos cambios en Android 18 (la próxima gran versión), antes del 1 de agosto de 2027. La detección concurrente de palabras clave (permitiendo que múltiples servicios se activen por voz) debe estar implementada en Android 19, a más tardar el 1 de agosto de 2028.

Cabe señalar que la decisión aún depende de Google para diseñar e implementar los cambios, y con ello conlleva el riesgo de un cumplimiento malicioso: una solución técnicamente sólida pero impracticable en la realidad (no sería la primera vez que un guardián se libra de una regulación). Sin embargo, la letra pequeña da motivos para la esperanza: Google debe ofrecer soluciones “igual de eficaces” en cuanto a facilidad de uso, velocidad y consumo de energía, publicar documentación completa y herramientas de prueba, e informar mensualmente de los avances a la Comisión. Una victoria real para los desarrolladores, y una que hace que sea mucho más difícil salirse con la suya simplemente cumpliendo lo mínimo. Teniendo esto en cuenta, así es como podría verse para Home Assistant.

Ayúdanos a que Este Cambio Perdure: El Futuro de la Interoperabilidad en Android

Trabajamos constantemente para crear la mejor experiencia posible para nuestros usuarios de Home Assistant en Android, aunque somos un equipo pequeño, por lo que las contribuciones de la comunidad a la aplicación Android son de suma importancia. Si deseas colaborar (en línea con nuestra política de IA recientemente publicada), nos encantaría saber de ti. Si bien las ideas a continuación son solo eso y no forman parte de nuestra hoja de ruta, tu aportación podría ayudar a hacerlas realidad en el futuro:

Detección de Palabras Clave Eficiente en Batería

Como mencionamos anteriormente, trasladar la detección de primera etapa de la CPU al DSP debería aumentar significativamente la eficiencia de la batería. Nuestro plan es admitir dos métodos: en teléfonos más nuevos con Android 18, utilizaremos el chip de bajo consumo del teléfono para escuchar la palabra clave. En teléfonos más antiguos, o aquellos sin ese chip, la detección seguirá funcionando como lo hace hoy. En cualquier caso, te mostraremos qué método está utilizando tu teléfono dentro de la aplicación Companion.

Un Teléfono, Dos Asistentes: Rompiendo las Cadenas del Asistente Predeterminado

Hoy en día, elegir una palabra clave de terceros significa renunciar a Gemini, junto con llamadas y mensajes a través de tu asistente predeterminado. El desacoplamiento del rol predeterminado y el acceso concurrente a las palabras clave de activación pondrían fin a eso: puedes hablar con Gemini como siempre, pero también decir “Okay Nabu” cuando quieras interactuar con tu hogar a través de Home Assistant.

Imagina poder configurar palabras clave de activación diferentes para distintos asistentes dentro de la propia aplicación, como “Hey Jarvis” para tu panel de administración y “Okay Nabu” para la familia. Esto no será técnicamente posible hasta 2028, cuando se lance Android 19 (y requerirá mucho trabajo), pero es un objetivo atractivo para el futuro.

Mejor Privacidad Integrada: Sandboxing por Diseño

Esta es la parte que me parece más emocionante. La sentencia exige que la confirmación de la palabra clave se ejecute en un proceso seguro y aislado (conocido como sandboxing) a través del DSP. Esto significa que la parte del sistema que controla esta función está aislada, sin forma de enviar audio a ningún sitio hasta que se confirme la palabra clave. No quiero depender de la confianza cuando se trata de algo tan sensible como las interacciones con mi asistente de voz. Quiero tener el control, con una explicación clara de lo que implican las cosas que habilito. El sandboxing nos proporciona eso por diseño: privacidad impuesta por el propio sistema operativo, la misma protección segura por defecto que Google siempre ha tenido, ahora finalmente disponible para todos.

Un Asistente Más Capaz, para Todos: Integración y Control Ampliados

El acceso a los sensores no es el único ámbito donde se aplica este trato igualitario. La decisión también exige que Google abra integraciones estructuradas con sus propias aplicaciones —Gmail, Calendar, Maps, etc.— a asistentes cualificados, no solo a Gemini. En teoría, eso significa que tu asistente podría redactar un correo electrónico, gestionar un evento del calendario o enviar un mensaje de texto e iniciar una llamada en tu nombre: exactamente las capacidades que nuestros usuarios nos dicen que extrañan cuando abandonan Gemini, y que podrían aumentar genuinamente la usabilidad, especialmente para usuarios con necesidades de accesibilidad.

Ese mismo acceso podría ampliar el rango de sensores y controles que la aplicación ya reporta a Home Assistant: detección de sonido (alarma de humo, rotura de cristales, timbre) como disparadores de automatización, y controles como “no molestar” o Bluetooth sobre los que tu asistente puede actuar, no solo observar.

El Argumento de la Seguridad: Desmontando las Preocupaciones de Google

Google ha respondido a la decisión citando riesgos de seguridad. Advierte que la decisión otorga a terceros “permisos sensibles y potentes del dispositivo”, exponiendo datos de usuario “sin el conocimiento o consentimiento del usuario”. Este planteamiento exagera los riesgos con una táctica familiar: hacer sonar la alarma sobre preocupaciones de seguridad para limitar los intentos de interoperabilidad. Señalaríamos, como uno de esos terceros, que la decisión ya incorpora las salvaguardias que la preocupación exige: Google aún puede requerir el consentimiento del usuario, mostrar indicadores de privacidad y permitir a los usuarios revocar el acceso por servicio. Para las funciones más sensibles, como el acceso a datos de salud, también cuenta con una política a través de Play Store para verificar la seguridad, la privacidad y la minimización de datos antes de que cualquier aplicación obtenga acceso.

Y para que quede claro, estas capacidades ya existen en tu teléfono, y los propios servicios de Google ya las utilizan, sin pedir nunca tu aprobación. El riesgo no apareció cuando la UE pidió que ese acceso se compartiera más ampliamente; lo que cambió es quién decide quién lo tiene. Cualquier riesgo restante, como los introducidos al usar cualquier dispositivo inteligente, debe tomarse en serio, pero no como un velo para el doble juego de Google.

Nuestra opinión es que la confianza sin verificación no es un modelo de seguridad, y limitar estas salvaguardias solo a Google no es protección. Incluso los principales proveedores de IA han tenido incidentes de seguridad, como Hugging Face/OpenAI. Lo que sí ofrece protección es dar a los usuarios elección y transparencia en los procesos de seguridad, junto con una arquitectura técnica segura: sandboxing, aislamiento, permisos revocables, aplicados por igual, que es lo que esta decisión requiere.

Vale la pena estar atento a los próximos pasos de Google: a partir de 2027, su verificación de desarrolladores…