2. Android Automotive架构：分层、CarService与Vehicle HAL详解
好，咱们进入正题。Android Automotive OS，说白了就是Google把手机上的Android搬到了车上，但绝不是简单移植。你想想看，手机死机了重启一下就行，车机要是死机了，空调打不开、导航黑屏，那可就麻烦了。所以，它的架构设计必须足够健壮、分层清晰。
我个人习惯把Android Automotive OS分成三个大层来看：
- 应用层：就是用户能看到的那些App，比如地图、音乐、空调控制面板。
- 框架层：这是核心，包括CarService、各种Manager（比如CarDrivingStateManager）。
- 硬件抽象层：也就是Vehicle HAL，它负责把车厂那些千奇百怪的硬件信号，翻译成Android能听懂的语言。
嗯，这里要注意，这三层之间通信是有严格规范的。应用不能直接操作硬件，必须通过CarService。这样做的好处是安全，坏处是……延迟会高一点。我在项目中遇到过，有些车厂为了追求空调响应速度，想绕过CarService直接调HAL，结果导致系统稳定性出问题，后来还是乖乖走标准流程。
2.1 CarService：车载服务的“大脑”
CarService是整个车载系统的核心服务。它运行在一个独立的进程中，负责管理所有车辆相关的状态和功能。
说白了，它就是车机世界的“交通警察”。所有App想获取车速、车门状态、空调温度，都得先问它。它再通过Vehicle HAL去问硬件。
CarService里包含几个关键模块：
- CarPropertyService：管理车辆属性，比如车速、里程、油量。这些属性是只读的，App只能订阅变化。
- CarDrivingStateService：判断驾驶状态，比如停车、行驶、倒车。这个很重要，很多App在行驶中会被限制操作。
- CarAudioService：管理车载音频，比如导航音、电话音、媒体音的音量分配和混音。
- CarInputService：处理方向盘按键、旋钮等物理输入。
关键点：CarService是系统级服务，它的启动顺序早于普通App。如果CarService挂了，整个车机系统基本就瘫痪了。我曾经调试过一个bug，就是CarService因为一个空指针异常崩溃，导致所有车辆状态显示为“未知”，最后发现是某个HAL返回的数据格式不对。
2.2 Vehicle HAL：连接硬件与系统的桥梁
Vehicle HAL是Android Automotive里最“接地气”的一层。它定义了一套标准接口，让车厂把自己的硬件（CAN总线、LIN总线、以太网）映射到Android的属性系统上。
我建议你把它理解成一个“翻译官”。车上的传感器说“0x1234 0x5678”，Vehicle HAL把它翻译成“车速：60km/h”。
Vehicle HAL的核心数据结构是VehicleProperty。每个属性都有一个唯一的ID，比如：
// 车速属性
VehicleProperty.PERF_VEHICLE_SPEED
// 车门状态
VehicleProperty.DOOR_POS
// 空调温度
VehicleProperty.HVAC_TEMPERATURE_SET每个属性还有自己的类型、区域（比如左前门、右后门）、权限（读/写/订阅）。
| 属性ID | 名称 | 类型 | 区域 | 权限 |
|---|---|---|---|---|
| 0x1110 | 车速 | INT32 | 全局 | 只读 |
| 0x1120 | 车门状态 | INT32 | 按车门 | 只读 |
| 0x1140 | 空调温度设置 | FLOAT | 按区域 | 读写 |
嗯，这里有个坑。Vehicle HAL的实现方式有两种：
- 默认实现（Default Vehicle HAL）：Google提供的参考实现，适合原型开发。但别指望它能在真车上跑。
- 自定义实现（Custom Vehicle HAL）：车厂自己写的，直接对接CAN总线。这才是量产车用的。
警告：千万不要在生产环境中使用Default Vehicle HAL。我曾经见过一个项目，工程师偷懒直接用默认实现，结果车机在高速上突然显示“车速为0”，导致导航误判。后来排查发现，默认实现里车速是写死的模拟值，根本没连CAN总线。
2.3 数据流：从硬件到App的完整路径
咱们走一遍完整的数据流，这样你就能理解这三层是怎么协作的了。
假设用户想查看当前车速：
- 硬件层：CAN总线上传来一个报文，包含车速数据。
- Vehicle HAL：HAL的实现代码解析这个报文，转换成
VehicleProperty.PERF_VEHICLE_SPEED，并调用onPropertyEvent回调。 - CarService：CarService收到HAL的回调，更新内部状态，并通过Binder通知所有订阅了车速变化的App。
- App：App的
CarPropertyManager回调被触发，更新UI显示。
整个过程看起来简单，但实际调试时你会发现，延迟可能出现在任何一个环节。我建议你在每个关键节点都打上日志，方便定位问题。
技巧：调试Vehicle HAL时，可以用dumpsys car_service命令查看当前所有车辆属性的值。这个命令能帮你快速确认是HAL层没上报数据，还是CarService处理出了问题。
2.4 避坑指南：我踩过的几个坑
做车载开发这几年，我踩过不少坑。分享几个典型的：
- 属性权限没配好：App读车速时返回“权限拒绝”。后来发现是Vehicle HAL里把属性权限设成了“系统应用”，而我的测试App是第三方应用。解决办法：要么改权限，要么用系统签名。
- 区域搞混了：空调温度设置，左前和右后搞反了。用户说“我调左边温度，右边变热了”。这个问题排查了很久，最后发现是HAL里区域枚举值映射错了。
- 订阅回调不触发：App订阅了车速变化，但就是不回调。原因：CarService里有个优化，如果属性值变化小于某个阈值，就不会通知。解决办法：在HAL层强制上报，或者调整CarService的阈值配置。
嗯，这些坑说起来都是泪。但经历过一次，你就记住了。
2.5 小结
Android Automotive OS的分层设计，说白了就是为了安全和稳定。CarService是核心，Vehicle HAL是桥梁。理解这两者的关系，你就能在车载开发中少走弯路。
下一章，咱们会深入Vehicle HAL的代码实现，手把手教你写一个自定义HAL。到时候，我会用实际项目中的例子，带你避开那些常见的坑。