解读

面试官问“架构差异”，并不是让你把 AOSP 代码目录背一遍，而是想看三件事：

1. 你是否知道车载场景对可靠性、实时性、安全合规的硬性要求；
2. 你是否能把手机系统里“能省就省”的模块，对应到车载里“必须留、必须改、必须加”的模块；
3. 你是否能把差异落到具体技术决策：进程模型、SELinux 策略、HAL 接口、系统服务、应用框架、升级机制、权限模型、测试流程。

一句话：手机是“消费级”，车载是“车规级”，架构差异就是“怎么把消费级改写成车规级”。

知识点

1. 车规级硬件抽象层（Vehicle HAL）

   • 定义在 /hardware/interfaces/automotive/vehicle/2.0 及以上版本
   • 用 HIDL/AIDL 描述车身信号：车速、档位、空调、车门、燃油、EV 电池
   • 手机侧无此 HAL，车载必须实现且通过 CTS-on-Truck/VTS 认证

2. 系统服务差异

   • CarService 作为系统级服务常驻 system_server 进程，内部再拆： – CarPowerService：管理点火、熄火、休眠、唤醒序列（与 kernel 的 suspend-to-RAM 对齐） – CarPropertyService：把 Vehicle HAL 属性映射成 Android 属性，供上层调用 – CarAudioService：多音区、优先级抢占、紧急提示音（eCall）路由 – CarPackageManagerService：车机专用权限，禁止第三方 APK 在行驶中启动视频类 Activity
   • 手机侧只有 ActivityManager、AudioService、PowerManager，无 CarService

3. 多用户与多屏模型

   • 车载采用“系统用户（System User）+ 前台乘客用户（Foreground User）+ 后台临时用户（Rear Seat User）”模型，支持 Driver-Only 模式与 Multi-Display 安全隔离
   • 手机侧多用户仅用于工作资料或儿童空间，不会同时激活两块屏幕

4. SELinux 与安全合规

   • 车载在 system/sepolicy 里新增 automotive/domain.te、car_service.te，对 Vehicle HAL、CarService、VMCU 访问线程做 MLS/MLS-CAP 限制
   • 国内过《汽车整车信息安全技术要求》（GB/T 40861）与《汽车软件升级通用技术要求》（GB/T 40857），SELinux 必须 enforcing 且通过渗透测试

5. 升级与回滚

   • 车载必须使用 A/B 无缝系统分区 + 虚拟 AB 压缩快照，保证 30 分钟内完成全量 OTA，升级失败可回滚到上一次“可行驶”版本
   • 手机侧允许用户跳过版本，车载侧由车厂 TSP 平台强制推送，且需先经过仿真台架、封闭道路、公开道路三级测试

6. 应用框架限制

   • 禁止直接使用 android.permission.CAMERA、RECORD_AUDIO，需通过 CarUxRestrictionsManager 检查行驶状态
   • 禁止后台启动 Activity，必须使用 SystemUI 提供的 CarNotificationListener
   • 国内厂商（华为鸿蒙车机、百度 CarLife+、阿里斑马）在 AOSP 之上再封装一套 China Automotive SDK，与 Google GAS（Google Automotive Services）不兼容，面试时需说明“国内无 GMS，用高德地图、酷我音乐替代”

7. 性能与实时性

   • 车载对冷启动要求 <2.5 s 显示 Launcher，Android 10 之后引入 Bootloader 提前渲染 splash 的 Early-Surface 机制
   • 音频通路延迟 <50 ms，使用 ALSA tinycompress + FastMixer 线程优先级 SCHED_FIFO:98
   • 手机侧无此硬实时指标

8. 测试认证

   • 必须通过 CTS、GAS-Vehicle-ATS、VTS、STS、BTS、Perf-RT 六套测试，国内还要过中汽研 CATARC 信息安全与 OTA 备案
   • 手机侧只需 CTS/GTS/STS

答案

Android Automotive OS 在保持 AOSP 内核、Binder IPC、SELinux 沙箱等大框架不变的前提下，围绕“车规级可靠性、车规级安全、车规级实时”做了四方面重构：

1. 新增 Vehicle HAL 与 CarService 把车身信号抽象成 HIDL/AIDL 接口，由 CarPowerService、CarAudioService、CarPropertyService 等系统级服务统一管理，手机系统无此层。

2. 多用户+多屏安全隔离 采用 System User + Foreground User 模型，支持仪表盘、中控、副驾、后排四块屏幕独立 DisplayId，通过 CarUxRestrictions 禁止行驶中视频，手机系统无多屏安全策略。

3. 升级与回滚车规化 强制 A/B 无缝分区 + 虚拟 AB 压缩，升级失败必须回滚到“可行驶”版本，OTA 流程由车厂 TSP 管控；手机系统允许用户跳过版本。

4. 权限、SELinux、性能指标收紧 新增 automotive sepolicy 域，Vehicle HAL 线程优先级 SCHED_FIFO，冷启动 <2.5 s，音频延迟 <50 ms；手机侧无此类硬实时要求。

因此，Android Automotive OS 并不是简单地把手机系统“搬上车”，而是通过“加 HAL、加服务、加策略、加认证”把消费级架构改造成车规级架构。

拓展思考

1. 如果车厂要求“熄火后 10 分钟内可远程开空调，但 MCU 需休眠省电”，你怎么设计 CarPowerService 的 WakeLock 与 SuspendBlocker 策略？
2. 国内项目无 GMS，如何把高德地图 SDK 封装成 Automotive 的 MapService，使其既能被 SystemUI 调用，又能通过 CarProperty 把导航状态写到 Vehicle HAL 的 NAV_ACTIVE 属性？
3. 当仪表和中控共用一颗 SoC、跑两套 Android 实例（安全岛+娱乐岛）时，Hypervisor 方案（QNX+Android、KVM、Xen）在 Binder IPC 和 GPU 共享上分别有哪些坑？