TopsTip一辆新车里的电子控制单元（ECU）正在从“各自独立”走向“合并同类项”。过去仪表、信息娱乐和车身控制由不同芯片各管一摊，如今越来越多功能被集中到同一颗汽车 SoC 上。成本更低，但原本靠物理隔离形成的安全边界也随之消失。Google 给这个趋势提出的方案，是让 Android 学会在一台车里跑多个虚拟机。
2026 年 3 月，Google 宣布把 Android Automotive OS（AAOS）从信息娱乐扩展到车辆非安全关键部分的开放基础设施，并计划当年晚些时候开源；8 月 24 日，Android Auto 团队发布《AAOS SDV – Secure by Design》，专门补充面向软件定义汽车（SDV）的这套系统的安全设计。
这篇文章没有重复 3 月的功能列表，而是回答一个更具体的问题：当多个系统住进同一颗芯片时，如何让互不信任的“邻居”彼此隔离，并在出问题时退得回来。
隔离：默认不信任，共享必须显式
AAOS SDV 的起点是“域隔离”。仪表和信息娱乐对实时性、功能和安全等级的要求完全不同，Google 选择用虚拟机让多个实例并行运行，而不是让它们在同一个系统里互相“礼让”。共享是例外，隔离才是默认。这个思路也继承自更早的隐私虚拟机项目 Microdroid。
在系统内部，AAOS SDV 沿用 Android 一套成熟的边界机制：每个应用以独立 UID 放进沙箱；服务跑在独立进程，配合 POSIX capabilities 限制操作，再通过 SELinux 强制执行“默认拒绝”。也就是说，某项配置缺失时，访问被阻断，而不是网开一面。
AOSP 文档把 AAOS SDV 描述为轻量、无界面的 Android 系统，面向汽车 SoC 的多虚拟机环境，使用 VirtIO；同一套系统映像既能在云端或本地的 Cuttlefish 虚拟环境里跑，也能运行在兼容 VirtIO 的目标硬件管理程序上——这为开发者提供了相对统一的验证环境。
更新与证明：可回退比不可攻破更现实
安全不只取决于建了多少道墙，还取决于墙倒了之后系统能否恢复。AAOS SDV 的软件交付包括只读系统分区与 APEX。按官方说法，APEX 通过签名、Merkle Tree 和 dm-verity 按块验证完整性，并以只读方式挂载；更新采用 Active/Backup 设计，失败时回退到上一个可用版本。Google 还表示，新增组件会优先选用 Rust，配合持续自动扫描、年度深度渗透测试、架构审查和 Android 月度安全公告。
跨虚拟机访问则采用两层权限：服务级与 VM 级。非敏感服务可以通过较轻量的 APEX 更新获得更宽松的策略；而安全敏感信号的权限需要硬编码到各 VM 中——这意味着把敏感服务引入新 VM 时，可能要求整个 mesh 里的所有 VM 同步更新。安全边界越严格，后续扩展的协调成本就越高，这是设计里明确写着的取舍。
虚拟机之间还要先证明身份。AOSP 的 VM 身份与证明文档显示，VM 在加入 SDV Mesh 前需要验证同伴的完整性与真实性；DICE 证书链根植于 ECU 硬件级的 Unique Device Secret。换句话说，虚拟化隔离之外，还有一层硬件信任锚。
设计的边界
“Secure by Design”描述的是机制，而不是量产结果。Google 在 2026 年 3 月公告中已经把 AAOS SDV 的范围限定在车辆非安全关键部分；目前没有任何官方材料宣称 Android 接管制动、转向这类安全关键控制。虚拟化也没有消除所有信任问题——AOSP 的 pKVM 安全文档明确提示，主机可以影响 guest VM 的可用性，OEM 与 SoC 供应商依然是必须信任的一方。
所以更合适的判断是：AAOS SDV 提供的是一个可验证、可回退的框架，但每一辆量产车的安全水平，仍取决于 OEM 如何配置权限、如何做硬件集成、是否开展独立测试与认证。接下来的观察点不在架构图里，而在第一批量产车型上：Google 承诺的开源是否按期落地，车厂是否真的按这套默认隔离的原则部署，以及安全敏感权限的跨 VM 更新成本会不会拖慢功能迭代——这些才是软件定义汽车真正要交的答卷。
