Google 在 2026 年 8 月 24 日发布的 Android Developers 文章中，介绍了 Android Automotive OS for Software-Defined Vehicles（AAOS SDV）背后的安全模型。该项目让 Android 从信息娱乐系统扩展到可能共享集中式计算硬件的多个车载域，因此隔离和经过身份验证的通信成为核心设计问题。
集中化为何改变威胁模型
现代汽车架构正把过去运行在独立电子控制单元上的功能集中到同一计算平台。这可以简化硬件和软件部署，但也会让风险等级不同的服务彼此更接近。Google 表示，AAOS SDV 支持相互隔离的逻辑域，例如让仪表盘和信息娱乐系统运行在不同虚拟机中；共享必须显式配置。
该平台源自 Microdroid，也就是 Android 面向受保护虚拟机的精简环境。每个服务都有独立进程和用户标识，POSIX capabilities 与 SELinux 策略用于限制访问范围。默认拒绝意味着缺失权限配置时应阻止访问，而不是意外授予宽泛权限。
与运行软件状态绑定的身份
Google 方案中较有特色的部分是车载域之间的通信。AAOS SDV 将基于 DICE 的身份和证明机制与 TLS 结合，使组件不仅能验证对端身份，也能验证对端测量启动链所代表的软件状态。固件或配置发生变化时，派生身份也会改变。
这并不意味着汽车不会遭到入侵，但它可以避免仅凭预期网络地址就信任某项服务。Google 还描述了两层权限：服务级规则控制具体资源，虚拟机级规则控制跨域边界。安全敏感信号可固化到系统级策略中，而风险较低的服务仍可采用更灵活的更新方式。
内存安全与更新取舍
Google 称，新原生组件主要使用 Rust，以减少常见内存安全缺陷。验证加载、自动扫描、渗透测试和 Android 漏洞响应流程提供额外防线。不过，这些是 Google 对架构与流程的说明，并不是量产车辆安全性的独立证明。实际风险还取决于车企集成、硬件信任根、策略质量以及更新速度。
Google 今年 3 月发布的官方架构概览把 AAOS SDV 定位为面向多个车载控制器的模块化平台。此次安全文章进一步说明了如何在支持细粒度更新的同时维护边界。对开发者和车企而言，关键是集成过程中能否保留这些安全默认值。
接下来值得关注什么
该设计具有明确技术细节，但实际部署证据更重要。后续应关注公开代码与文档、合作伙伴实现、更新承诺、漏洞披露以及对量产系统的独立评估。现阶段较稳妥的结论是：Google 描述了一个严肃的纵深防御模型，而每个落地平台仍需证明其效果。