2. AAOS 系统架构全景:整体分层架构图

Android Automotive OS (AAOS) 基于 Android 开源项目 (AOSP) 构建,其系统架构延续了经典的四层分层设计。每一层都承担着明确的职责,并通过标准化的接口与相邻层通信。理解这一分层结构是掌握 AAOS 定制与开发的基础。

2.1 四层架构总览

AAOS 从底层到顶层依次为:Linux 内核层、硬件抽象层 (HAL)、应用框架层 (Framework) 和 应用层 (Apps)。其中,CarService 作为车辆专属的核心服务,位于应用框架层,是连接上层车载应用与底层车辆硬件的桥梁。

AAOS 四层分层架构全景图 AAOS 四层分层架构全景图 应用层 (Application Layer) OEM 定制应用 (Launcher, HVAC, 设置) | 第三方应用 (Spotify, Waze) | 系统 UI (SystemUI) 职责:提供用户交互界面,实现车辆功能控制与信息娱乐 应用框架层 (Application Framework) CarService | CarAppService | VehicleHalClient | PermissionController ActivityManager | WindowManager | PackageManager | 标准 Android 服务 职责:封装车辆功能 API,管理应用生命周期,提供权限与策略控制 核心:CarService 是车载功能的枢纽 硬件抽象层 (Hardware Abstraction Layer, HAL) Vehicle HAL (VHAL) | Audio HAL | Camera HAL | Sensors HAL 职责:定义标准接口,屏蔽硬件差异,实现与内核驱动通信 内核层 (Linux Kernel) CAN 总线驱动 | GPIO/I2C/SPI 驱动 | 电源管理 (Suspend/Resume) 职责:硬件驱动、进程管理、内存管理、网络协议栈 IPC 通信:Binder / HIDL / AIDL
架构要点:AAOS 与标准 Android 最大的区别在于 应用框架层 引入了 CarService 及其相关组件,以及 硬件抽象层 定义了 Vehicle HAL (VHAL) 标准接口。这两层共同构成了车载功能的专属通道。

2.2 各层职责深度解析

2.2.1 应用层 (Application Layer)

应用层是用户直接接触的界面层,包含系统应用和第三方应用。在 AAOS 中,应用层需要遵循车载特有的设计规范,如 驾驶安全约束 (Driver Distraction Guidelines, DDG)。

  • OEM 定制应用:车辆设置、空调控制 (HVAC)、车载 Launcher、仪表盘 (Instrument Cluster) 等。
  • 第三方应用:通过 CarAppService 与车辆交互,如导航、音乐、播客。
  • 系统 UI:状态栏、通知栏、音量控制等,需适配车载横屏与旋钮交互。

2.2.2 应用框架层 (Application Framework)

框架层是 AAOS 的核心,它既包含标准 Android 服务,也包含车载专属服务。这一层通过 Binder IPC 机制向上提供 API,向下调用 HAL 接口。

核心组件 职责说明 关键接口/类
CarService 车载功能中枢,管理车辆属性 (Vehicle Property) 的读写、订阅与通知 Car.java, CarPropertyManager
CarAppService 管理第三方车载应用的生命周期,确保应用在驾驶时符合安全策略 CarAppService.java
VehicleHalClient CarService 与 VHAL 之间的客户端代理,封装 AIDL 调用 IVehicle.aidl
PermissionController 管理车辆相关权限,如控制空调、读取车速等 CarPermissionManager
标准 Android 服务 ActivityManager、WindowManager、PackageManager 等,提供基础能力 标准 AOSP 接口
关键概念:CarService 内部维护了一个 Vehicle Property 注册表。所有车辆信号(如车速、车门状态、空调温度)都被抽象为 Property ID。应用通过 CarService 订阅特定 Property,当硬件状态变化时,VHAL 上报事件,CarService 再分发给订阅的应用。

2.2.3 硬件抽象层 (Hardware Abstraction Layer, HAL)

HAL 层是连接框架与内核的桥梁。AAOS 使用 AIDL HAL(Android 11 及之后)或 HIDL HAL(Android 10 及之前)来定义标准接口。其中 Vehicle HAL (VHAL) 是最关键的 HAL 模块。

  • Vehicle HAL (VHAL):定义车辆属性 (VehicleProperty) 的获取 (get)、设置 (set) 和订阅 (subscribe) 接口。OEM 必须实现此 HAL 以适配自家硬件。
  • Audio HAL:管理车载音频路由,支持多音区(驾驶席、乘客席)独立控制。
  • Camera HAL:支持环视摄像头、DMS 摄像头等车载视觉输入。
  • Sensors HAL:提供车速传感器、方向盘转角传感器等数据。

2.2.4 内核层 (Linux Kernel)

内核层是系统的基础,负责硬件驱动、进程调度、内存管理和电源管理。在 AAOS 中,内核层需要特别支持车载硬件接口。

  • CAN 总线驱动:用于与车辆 CAN 网络通信,读取/发送车身控制信号。
  • GPIO/I2C/SPI 驱动:用于控制车载外设,如氛围灯、物理按键。
  • 电源管理:支持汽车级的休眠/唤醒 (Suspend/Resume) 策略,如停车监控模式。
  • 安全启动 (Secure Boot):确保系统启动链的完整性,防止篡改。

2.3 层间通信机制

AAOS 各层之间通过明确的 IPC 机制进行通信,确保数据流和控制流的正确传递。

AAOS 层间通信与数据流图 AAOS 层间通信与数据流图 车载应用 (App) CarService Vehicle HAL (VHAL) Linux Kernel Driver 层间通信协议与数据流向 ① App → CarService: Binder IPC (AIDL 接口) 调用 Car.getProperty() / setProperty() ② CarService → VHAL: AIDL / HIDL IPC 调用 IVehicle::get() / set() / subscribe() ③ VHAL → Kernel Driver: ioctl() / sysfs / CAN 套接字 直接操作硬件寄存器或 CAN 报文
开发注意:在实现 VHAL 时,必须确保 线程安全。VHAL 的回调可能来自多个线程(如 CAN 接收线程、属性设置线程),CarService 期望 VHAL 在回调 onPropertyEvent() 时提供正确的序列化数据。建议使用 std::mutex 或 std::shared_mutex 保护共享状态。

2.4 架构设计原则与优势

AAOS 的四层架构设计遵循了以下原则,使其在车载场景中具备独特优势:

  • 解耦性:应用层不直接访问硬件,所有车辆功能通过 CarService 的 API 调用,降低了应用与硬件的耦合度。
  • 可移植性:OEM 只需实现 VHAL 和内核驱动,上层框架和应用无需修改即可在不同硬件平台上运行。
  • 安全性:通过权限控制器 (PermissionController) 和驾驶安全约束 (DDG),确保应用在驾驶过程中不会干扰驾驶员。
  • 扩展性:新增车辆功能时,只需在 VHAL 中注册新的 Property ID,并在 CarService 中定义对应的 API,无需改动整体架构。
架构总结:AAOS 的四层架构是 “标准 Android 能力 + 车载专属扩展” 的典范。内核与 HAL 层保证了硬件兼容性,框架层的 CarService 提供了统一的车辆抽象,应用层则实现了丰富的用户体验。掌握这一全景图,是后续深入分析 CarService 内部机制的前提。