2. AAOS 架构概览
Android Automotive OS（AAOS）并不是简单地把手机 Android 装进车机，而是在标准 Android 框架之上，增加了一整套面向车辆属性的服务层与硬件抽象层。理解 AAOS 的关键，是看清它的分层结构，以及 Car Service 与 Vehicle HAL（VHAL）之间“服务—抽象—硬件”的三角关系。本节从整体架构入手，逐层拆解，并梳理 VHAL 从 Android 9 到 Android 14 的版本差异。
一、AAOS 分层架构：从应用到车辆总线
AAOS 自上而下可分为五层，每一层都有明确的职责边界：
- 应用层（App Layer）：包括系统自带应用（如 Car Launcher、Settings、Media）和第三方应用。应用不直接访问车辆硬件，而是通过 Car API（如
CarPropertyManager）获取车辆属性。 - Car API 层：位于
android.car包中，是应用与 Car Service 之间的契约。它定义了属性 ID、权限、访问模式（读/写）和数据类型。 - Car Service 层：系统核心服务，运行在
system_server或独立进程中。它负责属性权限校验、订阅管理、区域映射、速率限制，并将请求转发给 VHAL。 - Vehicle HAL 层：即 VHAL，是 Car Service 与车辆硬件之间的抽象接口。它定义了属性 ID、属性配置、事件回调，并通过 Binder 与 Car Service 通信。
- 硬件与总线层：包括 MCU、CAN/LIN/FlexRay 总线、传感器和执行器。VHAL 的底层实现（Vendor HAL）负责将属性读写转换为具体的总线信号。
这五层之间是严格的单向依赖：上层依赖下层提供的接口，下层不感知上层业务逻辑。这种分层使得应用可以跨车型复用，而硬件差异被隔离在 VHAL 之下。
二、Car Service 与 VHAL 的关系
Car Service 与 VHAL 之间是“服务消费者”与“硬件抽象提供者”的关系，具体体现在三个层面：
- 接口契约：VHAL 通过
IVehicle.aidl暴露get()、set()、subscribe()等方法。Car Service 是这些接口的主要调用方，它把应用的属性请求翻译成 VHAL 调用。 - 属性配置：VHAL 在启动时通过
getAllPropConfigs()返回所有支持的属性配置，包括属性 ID、访问权限、数据类型、区域支持、变更模式等。Car Service 据此建立属性索引，并在应用请求时进行合法性校验。 - 事件回调：当车辆状态变化时，VHAL 通过
onPropertyEvent()主动上报。Car Service 接收后，再分发给已订阅的CarPropertyManager回调，形成“硬件 → VHAL → Car Service → 应用”的完整链路。
核心理解：Car Service 不直接读 CAN 信号，VHAL 也不处理业务权限。两者通过属性 ID 和 Binder 接口解耦，这是 AAOS 能够支持多车型、多供应商的关键设计。
三、VHAL 的演进与版本差异
VHAL 的接口形态和属性模型在 Android 9 到 Android 14 之间经历了多次重要变化。下表梳理了关键版本差异：
| Android 版本 | VHAL 接口形态 | 关键变化 | 对集成的影响 |
|---|---|---|---|
| Android 9 (P) | HIDL 1.0 | 属性模型初步建立，支持基础 get/set/subscribe | 供应商需实现 HIDL 接口，属性 ID 较少 |
| Android 10 (Q) | HIDL 2.0 | 引入属性配置、区域支持、连续属性 | 支持多区域属性，如分区空调 |
| Android 11 (R) | AIDL 过渡 | 开始从 HIDL 向 AIDL 迁移，引入 IVehicle.aidl |
供应商需同时维护 HIDL 与 AIDL 实现 |
| Android 12 (S) | AIDL 稳定 | AIDL 成为默认接口，属性 ID 大幅扩展 | 新项目建议直接使用 AIDL VHAL |
| Android 13 (T) | AIDL + 调试增强 | 支持 VHAL 调试工具、属性转储、更细粒度权限 | 便于排障，但权限配置更严格 |
| Android 14 (U) | AIDL 成熟 | 属性模型稳定，支持更多车辆域属性 | 推荐作为新车型的基线版本 |
从演进趋势看，VHAL 的接口从 HIDL 转向 AIDL，属性模型从“少量基础属性”扩展到“覆盖车身、动力、座舱、ADAS 的完整属性集”。对于集成工程师而言，选择 VHAL 版本时需重点确认：目标 Android 版本、供应商提供的 HAL 实现、以及属性 ID 是否与 Car API 对齐。
四、案例场景：读取车速属性的完整链路
以应用读取车速为例，完整链路如下：
// 1. 应用层：获取 CarPropertyManager
CarPropertyManager mgr = (CarPropertyManager) car.getCarManager(Car.PROPERTY_SERVICE);
// 2. 应用层：读取车速属性
CarPropertyValue<Float> value = mgr.getProperty(
VehiclePropertyIds.PERF_VEHICLE_SPEED,
VehicleAreaType.VEHICLE_AREA_TYPE_GLOBAL
);
// 3. Car Service：校验权限、查找属性配置、转发给 VHAL
// 4. VHAL：将属性 ID 转换为 CAN 信号，读取 MCU 数据
// 5. VHAL：返回 CarPropertyValue，Car Service 再返回给应用
这条链路中，任何一层出错都会导致读取失败。常见问题包括：属性 ID 未在 VHAL 中声明、权限未授予、区域类型不匹配、VHAL 实现未正确响应 get() 调用。
常见误区：很多初学者认为“应用可以直接调用 VHAL”。实际上，应用只能通过 Car API 访问 Car Service，再由 Car Service 调用 VHAL。绕过 Car Service 直接访问 VHAL 会导致权限校验缺失、订阅管理混乱，甚至引发系统稳定性问题。
五、复盘与要点总结
- AAOS 五层架构的核心是“分层解耦”：应用层、Car API、Car Service、VHAL、硬件层各司其职。
- Car Service 是属性访问的“守门人”，负责权限、订阅、区域和速率控制；VHAL 是硬件差异的“隔离层”。
- VHAL 从 HIDL 演进到 AIDL，属性模型不断扩展。集成时需确认版本、接口形态和属性 ID 对齐情况。
- 调试属性问题时，应沿着“应用 → Car API → Car Service → VHAL → 总线”的链路逐层排查，优先确认属性配置和权限。
掌握本节的分层关系和版本差异，是后续进行 VHAL 属性定义、Car Service 集成和车辆服务开发的基础。只有在架构层面建立清晰的认知，才能在具体集成工作中快速定位问题、做出正确的技术选型。