7、Android Automotive系统架构：从底层到应用的全景解读
各位同学，今天我们来聊聊Android Automotive的系统架构。说实话，这个题目看起来很大，但别担心，我会用我这些年做嵌入式系统移植的经验，帮你把这块硬骨头啃下来。
Android Automotive，说白了就是Google为汽车量身定制的Android系统。它跟手机上的Android同源，但多了很多车规级的东西。我刚开始接触这个项目时，第一反应是：这不就是个改版的Android吗？后来踩了不少坑才明白——汽车场景下的系统架构，远比手机复杂得多。
7.1 Android系统层次结构
先看整体架构。Android Automotive的层次结构，从上到下分为五层：
- 应用层（Application Layer）：包括车载信息娱乐应用、仪表盘应用、第三方应用等
- 应用框架层（Application Framework）：提供Activity Manager、Window Manager、Package Manager等核心服务
- 系统运行库层（Libraries & Android Runtime）：包含C/C++原生库、ART虚拟机
- 硬件抽象层（HAL）：这是连接Android框架和底层硬件的关键桥梁
- Linux内核层（Linux Kernel）：包含设备驱动、电源管理、内存管理等
嗯，这里要注意一点：Automotive版本在应用框架层多了几个汽车专属的服务，比如CarService、Vehicle HAL等。我刚开始移植时，就是忽略了这些差异，导致系统启动后很多功能跑不起来。
核心观点：Android Automotive不是简单的"Android + 汽车皮肤"，而是从架构层面就为汽车场景做了深度定制。
7.2 HAL层设计思想
HAL层，全称Hardware Abstraction Layer。我个人觉得，这是整个系统移植中最关键、也最容易出问题的一层。
为什么要有HAL？说白了，就是为了让Android框架不直接跟硬件打交道。你想想看，不同厂商的硬件千差万别，如果框架直接调用驱动接口，那Google得维护多少种驱动协议？
HAL的设计思想可以概括为三点：
- 接口标准化：Google定义好HAL接口，厂商实现具体逻辑。比如Vehicle HAL，定义了getProperty、setProperty等标准方法。
- 模块化：每个硬件模块对应一个HAL库，互不干扰。音频有audio HAL，传感器有sensors HAL，车辆信号有vehicle HAL。
- 可替换性：只要遵循接口规范，你可以随时替换底层的HAL实现。我在项目中就遇到过，因为换了供应商的硬件，只需要重新实现对应的HAL模块，上层代码完全不用动。
实战经验：我在移植过程中发现，很多团队容易把业务逻辑写在HAL里。这是个坑！HAL只应该做硬件访问的封装，不要在里面做状态机、策略判断这些事。否则后面维护起来会非常痛苦。
7.3 AOSP源码目录结构
AOSP（Android Open Source Project）的源码目录，第一次看可能会觉得眼花缭乱。我刚开始接触时，光找vehicle HAL的代码就花了半天。下面我带你快速过一遍核心目录：
| 目录 | 说明 | 我的备注 |
|---|---|---|
frameworks/ |
Android框架层代码，包括核心服务、API等 | CarService就在这里 |
hardware/ |
HAL接口定义和参考实现 | 移植时重点关注 |
packages/ |
系统应用，如Launcher、Settings | Automotive有专属的CarLauncher |
vendor/ |
厂商定制代码，包括HAL实现、驱动等 | 我们移植的主要工作区 |
device/ |
设备相关配置，如BoardConfig、device tree | 板级适配的关键 |
kernel/ |
Linux内核源码 | 驱动开发的主战场 |
external/ |
第三方开源库 | 蓝牙、Wi-Fi协议栈等 |
举个例子，如果你想找Vehicle HAL的接口定义，路径是：
hardware/interfaces/automotive/vehicle/2.0/
├── IVehicle.hal # HAL接口定义
├── types.hal # 数据类型定义
├── default/ # 参考实现
│ ├── Vehicle.cpp
│ └── Vehicle.h
嗯，这里有个小技巧：我习惯在源码根目录下用find . -name "*.hal" | grep vehicle来快速定位。比手动翻目录快多了。
7.4 Automotive专属服务介绍
Android Automotive相比普通Android，多了几个核心服务。这些服务是汽车功能的基础，也是我们移植工作的重点。
7.4.1 CarService
CarService是Automotive的核心服务，运行在系统进程中。它负责管理车辆相关的所有功能，比如：
- 车辆属性（车速、里程、车门状态等）
- 驾驶模式（停车、行驶、倒车等）
- 车辆控制（空调、车窗、座椅等）
CarService通过Vehicle HAL与底层硬件通信。我遇到过一个问题：车辆启动后CarService一直报错，查了半天发现是HAL的初始化顺序不对。后来在CarService的启动脚本里加了依赖等待，才解决。
7.4.2 Vehicle HAL
这是连接CarService和车辆硬件的桥梁。它定义了一套标准的车辆属性接口，比如：
// IVehicle.hal 中的核心接口
getProperty(VehiclePropConfig prop, VehiclePropValue* value);
setProperty(VehiclePropConfig prop, VehiclePropValue value);
subscribe(VehiclePropConfig prop, float sampleRate);
每个属性都有一个唯一的ID，比如车速是VEHICLE_PROPERTY_CAR_SPEED。我在移植时，需要根据硬件手册，把CAN总线上的车速信号映射到这个属性上。
7.4.3 CarAudioService
汽车音频系统比手机复杂得多。它要支持多音区（驾驶员、乘客独立听音乐）、紧急提示音优先、导航混音等。CarAudioService就是管理这些音频策略的服务。
避坑指南：我曾经在移植CarAudioService时，忽略了音频焦点管理。结果导航播报时，音乐没有自动降低音量。用户投诉说"导航声音听不清"。后来在AudioPolicy配置里加了混音规则才解决。
7.4.4 CarClusterService
这个服务负责仪表盘显示。它从Vehicle HAL获取车速、转速、油量等数据，然后渲染到仪表盘屏幕上。注意，仪表盘对实时性要求很高，数据刷新率通常要达到60fps。
7.4.5 CarProjectionService
手机投屏服务，支持Android Auto和Apple CarPlay。这个服务需要处理蓝牙、Wi-Fi、USB等多种连接方式，还要做屏幕分辨率适配。
好了，以上就是Android Automotive系统架构的核心内容。从层次结构到HAL设计，从源码目录到专属服务，这些知识是后续移植工作的基础。记住一句话：理解架构，才能驾驭架构。
总结：Android Automotive的架构设计，本质上是为了解决"通用平台"和"专用硬件"之间的矛盾。HAL层是化解这个矛盾的关键。而Automotive专属服务，则是把汽车场景的特殊需求，优雅地融入到了Android生态中。
公众号:蓝海资料掘金营，微信deep3321