3. AAOS 架构总览
Android Automotive OS（AAOS）并不是把手机 Android 简单搬进车机，而是在标准 Android 框架之上叠加了一整套面向车辆的分层体系。理解 AAOS 的关键，是把它看成一条从“硬件信号”到“应用界面”的纵向链路：底层是车辆总线与 ECU，中间是 Vehicle HAL 与 CarService，上层是 Car API 与应用框架，最终由 SystemUI、Launcher 和第三方应用呈现给用户。本节围绕系统分区、CarService、Vehicle HAL、Car API、应用框架与启动流程六个对象，建立一张可落地的架构地图。
一、系统分区：AAOS 的静态骨架
AAOS 的镜像布局决定了“哪些代码属于平台、哪些属于供应商、哪些可以独立升级”。量产项目中最常打交道的分区如下：
| 分区 | 典型内容 | 量产关注点 |
|---|---|---|
| system | AOSP 框架、CarService、Car API、系统应用 | 只读，随 OTA 整体升级 |
| vendor | Vehicle HAL 实现、HIDL/AIDL 服务、MCU 通信库 | 与硬件强绑定，由 Tier1 维护 |
| product | OEM 定制应用、主题、配置 | 可独立于 system 更新 |
| odm | ODM 驱动、传感器适配 | 与 vendor 协同验证 |
| data / metadata | 用户数据、加密元数据 | 恢复出厂与加密策略 |
分区边界一旦确定，接口就必须稳定。CarService 与 Vehicle HAL 之间的 AIDL 接口、Car API 与 CarService 之间的 Binder 接口，都是跨分区协作的“合同”。量产中常见的返工，往往不是功能写错，而是分区归属和接口版本没有提前冻结。
二、CarService：车辆能力的调度中枢
CarService 是 AAOS 的核心系统服务，运行在 system_server 之外的独立进程中，通常以 car_service 身份存在。它向下通过 Vehicle HAL 订阅车辆属性，向上通过 Binder 向应用暴露 Car API。可以把它理解为“车辆领域的 ActivityManager + SensorService”。
- 属性管理：维护 VehicleProperty 的订阅、读写与权限校验，例如车速、挡位、空调温度。
- 场景与电源：处理驾驶状态、用户切换、电源策略，决定哪些应用可见、哪些功能禁用。
- 服务编排：CarPropertyService、CarPowerManagementService、CarUxRestrictionsManagerService 等子服务协同工作。
- 权限与安全：对车辆信号访问做分级授权，避免普通应用直接触碰关键控制量。
三、Vehicle HAL 与 Car API：一上一下的两层接口
Vehicle HAL 是 AAOS 与车辆硬件之间的抽象层。它把 CAN、LIN、以太网或私有总线上的信号，统一映射为 VehicleProperty。供应商在 vendor 分区实现该 HAL，向上提供 AIDL 接口，向下对接 MCU 或网关。
// 典型属性访问路径（示意）
应用 → CarPropertyManager.getProperty(Car.PROPERTY_SPEED)
→ Binder → CarPropertyService
→ VehicleHal.getProperty()
→ Vendor Vehicle HAL
→ CAN / MCU → 车辆总线Car API 则是面向应用的 Java/Kotlin 接口集合，位于 android.car 包。它把 CarService 的能力封装成 CarPropertyManager、CarUxRestrictionsManager、CarPowerManager 等管理器。应用不直接接触 HAL，而是通过 Car API 获得经过权限校验和场景过滤后的数据。
四、应用框架与启动流程
AAOS 的应用框架在标准 Android 之上增加了 Car 相关约束：驾驶状态会限制 UI 复杂度，用户切换会重建任务栈，电源状态会影响应用生命周期。启动流程可以概括为“内核 → init → zygote → system_server → CarService → 应用”。
- 内核与 init 拉起 vendor 服务，Vehicle HAL 进程就绪。
- zygote 启动，system_server 初始化标准系统服务。
- CarService 作为独立进程启动，连接 Vehicle HAL 并完成属性订阅。
- CarService 向 system_server 注册，Car API 对应用可用。
- SystemUI、Launcher 与 Car 应用按用户和驾驶状态启动。
下面这张图把六个对象放在同一条纵向链路上，便于建立整体位置感：
五、案例与排障复盘
某量产项目出现“空调温度显示不刷新”的问题。按链路逐层排查：应用侧 CarPropertyManager 订阅正常；CarService 日志显示属性订阅成功但无新值；Vehicle HAL 侧发现供应商把温度属性注册到了错误的 zone，导致 CarService 过滤后丢弃。最终修改 vendor 侧属性注册表并重新验证。这个案例说明：AAOS 排障要沿“应用 → Car API → CarService → Vehicle HAL → 总线”逐段确认，而不是只在应用层加日志。