3. Android Automotive 架构总览：系统架构分层与核心服务

好，我们直接进入正题。Android Automotive 的系统架构，说白了就是一套分层清晰的软件栈。你想想看，一辆车上有几十个 ECU（电子控制单元），每个都在跑不同的系统，而 Android Automotive 要做的，就是把这些乱七八糟的硬件统一管理起来，给上层应用提供一个稳定、安全的运行环境。

我个人习惯把整个架构想象成一个「千层蛋糕」。从最底层的硬件，到最顶层的应用，每一层各司其职，层与层之间通过定义好的接口通信。这样做的好处很明显——哪一层出了问题，就只修哪一层，不用把整个蛋糕掀了重做。

3.1 系统架构分层总览

我们先看一张整体架构图，把每一层的位置和关系搞清楚。

这张图你应该能看懂。从上到下分别是：应用层、框架层、HAL 层、内核层，最下面是硬件。每一层都通过标准接口与相邻层通信。嗯，这里要注意，Android Automotive 和普通 Android 最大的区别就在框架层和 HAL 层——多了专门为汽车设计的服务。

3.2 应用层：用户直接接触的部分

应用层就是用户能在车机上看到的那些 App。比如导航、音乐、电话、车辆设置、空调控制等等。这些应用运行在 Android 的 Activity 或 Service 中，通过 Framework 提供的 API 来访问车辆数据和控制车辆功能。

我在项目中遇到过一个问题：某款车型的空调控制 App 在切换温度时总是卡顿。后来发现是应用层频繁调用 VehicleService 的接口，而 VehicleService 底层处理不过来。解决方案是在应用层加了一个「防抖」机制——用户连续调节温度时，只发送最后一次的值。你看，有时候问题不在底层，而在上层怎么用。

3.3 框架层：系统的中枢神经

框架层是 Android Automotive 最核心的部分。它包含了 Android 原生的 Framework 服务（比如 ActivityManager、WindowManager、PackageManager），以及专门为汽车场景新增的服务。

这里我重点介绍几个核心服务：

服务名称	功能描述	我的备注
CarService	汽车服务的入口，管理所有车辆相关服务	相当于车载系统的「大管家」
VehicleService	与车辆硬件通信，获取/设置车辆属性	车速、车门、空调都通过它
CarPropertyService	管理车辆属性（Property）的读写	每个属性都有 ID 和类型
CarAudioService	管理车载音频路由和音量	导航、电话、媒体各走各的通道
CarInputService	处理方向盘按键、旋钮等输入	旋钮的「咔哒」手感也要模拟
CarProjectionService	支持手机投屏（Android Auto / CarPlay）	这个服务很复杂，涉及协议转换

为什么要有这么多服务？说白了，汽车不是手机。手机只需要处理触摸屏和传感器，汽车要处理 CAN 总线、LIN 总线、以太网、甚至 FlexRay。这些硬件的访问方式各不相同，框架层的作用就是把这些复杂性封装起来，给应用层提供统一的 API。

举个例子，应用层想知道当前车速，只需要调用 VehicleService.getProperty(VehicleProperty.PERF_VEHICLE_SPEED)。至于底层是通过 CAN 总线读取的，还是通过 OBD-II 读取的，应用层完全不用关心。这就是分层设计的好处。

3.4 HAL 层：连接软件与硬件的桥梁

HAL 层，全称 Hardware Abstraction Layer，硬件抽象层。它的作用是把硬件厂商的驱动代码和 Android Framework 隔离开来。

为什么需要这一层？我记得有一次，某家供应商提供的 CAN 驱动接口和我们预期的完全不一样。如果没有 HAL 层，我们就得修改 Framework 层的代码来适配这个驱动。但有了 HAL 层，我们只需要在 HAL 层写一个适配器，把供应商的接口转换成 Android 标准接口就行了。Framework 层完全不用动。

Android Automotive 中最重要的 HAL 是 Vehicle HAL。它定义了车辆属性的标准接口：

// Vehicle HAL 的核心接口（简化版）
struct VehicleHal {
    // 获取车辆属性
    StatusCode get(VehiclePropValue* out_value);
    
    // 设置车辆属性
    StatusCode set(const VehiclePropValue& value);
    
    // 订阅属性变化
    StatusCode subscribe(int32_t prop_id, float sample_rate);
    
    // 取消订阅
    StatusCode unsubscribe(int32_t prop_id);
};

你看，接口很简单，就四个函数：get、set、subscribe、unsubscribe。但背后要做的事情可不少。比如 set 一个空调温度，HAL 层需要把温度值转换成 CAN 报文，发送到空调控制器，还要等待控制器确认。这个过程可能涉及多个 CAN 帧的收发，还有超时重试机制。

除了 Vehicle HAL，还有 Audio HAL、Camera HAL、Sensors HAL 等。这些 HAL 和普通 Android 的 HAL 基本一致，但有一些车载特有的扩展。比如 Audio HAL 需要支持「音频焦点管理」——导航播报时，音乐音量要自动降低。

3.5 内核层：系统的基石

内核层就是 Linux Kernel，加上车载设备驱动。Android Automotive 使用的是标准的 Linux 内核，但增加了一些车载场景需要的驱动和特性。

内核层主要负责：

• 进程管理：调度 CPU 资源，确保关键服务优先运行
• 内存管理：分配和回收内存，防止内存泄漏导致系统崩溃
• 设备驱动：CAN 控制器驱动、GPIO 驱动、I2C/SPI 驱动等
• 电源管理：管理车载系统的休眠和唤醒
• 安全机制：SELinux、权限控制、加密存储

这里我要特别提一下「电源管理」。汽车和手机不一样，手机可以关机，汽车不能。汽车熄火后，系统要进入「深度休眠」状态，但还要能响应「开门」、「按启动键」等事件。这需要内核层的电源管理驱动和硬件紧密配合。

我曾经踩过一个坑：某款车型在熄火后，系统无法正常唤醒。排查了三天，最后发现是内核的 GPIO 中断配置有问题——唤醒引脚的中断触发方式设置成了「上升沿触发」，但硬件实际产生的是「下降沿」。改了一行代码就解决了。你看，有时候问题就出在最底层。

3.6 各层之间的通信机制

层与层之间怎么通信？我简单总结一下：

• 应用层 ↔ 框架层：通过 Binder 机制。应用通过 AIDL 接口调用 Framework 服务。
• 框架层 ↔ HAL 层：通过 HIDL（Android 8~10）或 AIDL（Android 11+）。HAL 服务运行在独立进程中，Framework 通过 Binder 或直连方式调用。
• HAL 层 ↔ 内核层：通过系统调用（open/read/write/ioctl）。HAL 层打开设备节点，直接操作硬件。
• 内核层 ↔ 硬件：通过中断、DMA、寄存器读写等方式。

你想想看，一个简单的「按方向盘上的音量+键」操作，要经过多少层？按键产生中断 → 内核驱动读取 GPIO 状态 → 上报输入事件 → InputReader 处理 → 发送到当前焦点应用 → 应用调用 AudioManager → AudioService 调整音量 → 通过 Audio HAL 设置硬件音量。每一步都不能出错。

3.7 小结

Android Automotive 的架构设计，说白了就是「分而治之」。每一层只做自己的事，通过标准接口与上下层协作。这种设计让系统更稳定、更易维护、也更灵活。

我个人觉得，理解架构分层是入门车载系统开发的第一步。你不需要记住每一层的所有细节，但要知道每一层是干什么的，出了问题该去哪一层找原因。后面我们会深入每一层，讲具体的实现和优化技巧。

嗯，今天就先到这里。记住这张架构图，后面所有的内容都会围绕它展开。

---