Google utilizó una publicación de Android Developers del 24 de agosto de 2026 para explicar el modelo de seguridad de Android Automotive OS for Software-Defined Vehicles, o AAOS SDV. El proyecto amplía Android más allá del infoentretenimiento hacia dominios del vehículo que pueden compartir hardware de computación centralizado, por lo que el aislamiento y la comunicación autenticada pasan a ser decisiones esenciales de diseño.
Por qué la consolidación cambia el modelo de amenazas
Las arquitecturas modernas concentran cada vez más funciones que antes se ejecutaban en unidades de control separadas. Esto puede simplificar el hardware y el despliegue, pero también acerca servicios con perfiles de riesgo distintos. Google afirma que AAOS SDV afronta el problema mediante dominios lógicos aislados, incluidas máquinas virtuales separadas para funciones como el cuadro de instrumentos y el infoentretenimiento. La compartición debe ser explícita.
La plataforma evolucionó a partir de Microdroid, el entorno mínimo de Android para máquinas virtuales protegidas. Cada servicio dispone de su propio proceso e identificador de usuario, mientras las capacidades POSIX y las políticas SELinux limitan su alcance. El modelo de denegación por defecto hace que una regla ausente bloquee el acceso en lugar de conceder privilegios amplios.
Identidad vinculada al software en ejecución
La parte más distintiva es la comunicación entre dominios. AAOS SDV emplea identidad y atestación basadas en DICE junto con TLS para autenticar tanto al interlocutor como el estado de software representado por su cadena de arranque medido. Si cambian el firmware o la configuración, también cambia la identidad derivada.
Esto no hace que un vehículo sea inmune a ataques. Sí evita confiar en un servicio solo porque aparece en una dirección de red prevista. Google describe además dos capas de permisos: reglas por servicio y límites entre máquinas virtuales. Las señales sensibles pueden fijarse en políticas globales, mientras los servicios menos críticos conservan rutas de actualización más flexibles.
Seguridad de memoria y actualizaciones
Google dice que los nuevos componentes nativos usan Rust como lenguaje principal para reducir errores comunes de seguridad de memoria. La carga verificada, el análisis automatizado, las pruebas de penetración y el proceso de respuesta de Android añaden más capas. Son afirmaciones de arquitectura y proceso de Google, no una prueba independiente de la seguridad de un vehículo desplegado. El riesgo real dependerá también de la integración del fabricante, el hardware de confianza, la calidad de las políticas y la rapidez de las actualizaciones.
La presentación oficial de marzo describió AAOS SDV como una base modular para varios controladores. El nuevo texto explica cómo Google pretende conservar los límites sin renunciar a actualizaciones granulares. Para desarrolladores y fabricantes, la cuestión práctica será mantener esos valores seguros durante la integración.
Qué observar ahora
El diseño es concreto, pero las pruebas de despliegue serán más importantes. Habrá que seguir el código y la documentación públicos, las implementaciones de socios, los compromisos de actualización, las vulnerabilidades divulgadas y las evaluaciones independientes. Por ahora, Google ha descrito una defensa en profundidad seria; cada plataforma comercial deberá demostrar su eficacia.