3、Android Automotive系统架构：系统框架层、HAL层、车载服务、应用层架构、与手机Android的差异
各位同学，今天我们来聊聊Android Automotive的系统架构。说实话，我第一次接触这个架构时，心里想的是：「这不就是手机Android改了个皮肤吗？」后来被现实狠狠教育了一顿。嗯，它俩确实同根同源，但差异之大，足以让你在项目里踩出一个个坑。
我个人习惯把Android Automotive的架构想象成一栋楼。地基是Linux内核，往上盖的是HAL层，再往上就是各种系统服务和框架，最顶层才是咱们开发者最熟悉的——应用层。每一层都有它的脾气，咱们一层层拆开看。
核心观点：Android Automotive不是手机Android的简单移植，而是针对车载场景重新设计的操作系统。它的架构设计围绕「安全性」、「稳定性」、「驾驶专注度」三个核心原则展开。
3.1 系统框架层（Framework Layer）
框架层说白了就是给上层应用提供API的那一层。在手机Android里，你调用LocationManager获取位置，调用TelephonyManager打电话。但在车上，这些API的底层实现完全不同。
举个例子，我在做某个车机项目时，发现CarPowerManager这个类在手机Android里根本不存在。它负责管理车辆的电源状态——ACC上电、引擎启动、休眠、深度睡眠。你想想看，手机可以随时关机重启，但车机不行。车机必须能在几秒钟内从休眠状态唤醒，同时还要保证导航、音乐等关键服务不中断。
框架层里新增了几个核心模块：
- CarService：车载服务的总入口，管理所有车载硬件抽象
- CarPropertyManager：读写车辆属性，比如车速、油量、车门状态
- CarSensorManager：访问车辆传感器，比如加速度计、陀螺仪（注意，这些和手机上的传感器不是一回事）
- CarAudioManager：管理车载音频区域，比如驾驶座和后排可以播放不同音源
避坑指南：我曾经在项目里直接用手机Android的AudioManager来控制车机音量，结果发现左右声道完全不受控。后来才意识到，车载音频有独立的音频区域（Audio Zone）概念，必须用CarAudioManager来操作。
3.2 HAL层（Hardware Abstraction Layer）
HAL层是连接系统框架和硬件驱动的桥梁。手机Android的HAL主要管摄像头、传感器、音频等。车载HAL呢？多了很多「车专属」的东西。
我列几个典型的车载HAL模块：
| HAL模块 | 功能说明 | 手机Android对应 |
|---|---|---|
| Vehicle HAL | 读写车辆CAN总线数据，如车速、转向灯、车门状态 | 无 |
| Car Audio HAL | 管理多区域音频输出、回声消除、噪声抑制 | Audio HAL（单区域） |
| Car Display HAL | 管理多屏幕显示，如仪表盘、中控屏、副驾屏 | Display HAL（单屏） |
| Car Network HAL | 管理车载以太网、Wi-Fi、蜂窝网络 | Network HAL |
这里有个关键点：Vehicle HAL是Android Automotive独有的。它通过IVehicle接口与车辆硬件通信。我记得第一次调试时，发现车速数据一直读不到，折腾了两天，最后发现是CAN总线上的信号ID配错了。嗯，这种问题在手机开发中根本不会遇到。
注意：Vehicle HAL的实现高度依赖硬件平台。不同车厂、不同车型的CAN协议可能完全不同。所以HAL层往往是OEM（车厂）定制最多的部分。如果你在第三方应用层开发，基本碰不到这层代码，但理解它的存在很重要。
3.3 车载服务（Car Services）
车载服务是Android Automotive的核心。它运行在系统进程中，负责管理所有与车辆相关的功能。我把它比作车机的「大管家」。
主要服务包括：
- CarService：总服务，负责启动和协调其他子服务
- VehicleService：直接与Vehicle HAL通信，提供车辆数据读写接口
- CarAudioService：管理音频焦点、音量、音频区域
- CarNavigationService：管理导航状态，比如是否在导航中、下一路口信息
- CarProjectionService：负责手机投屏，比如Android Auto、CarPlay
你可能会问：「这些服务跟手机Android的Service有什么区别？」区别大了。手机Android的Service是给单个应用用的，而车载服务是系统级的，所有应用都可以通过Car类来访问。而且，车载服务有严格的权限控制——不是随便一个App都能读车速的。
个人经验：我在做手机车机互联功能时，最常用的是CarProjectionService。它负责把手机屏幕投射到车机上。但有个坑：不同车厂对这个服务的实现差异很大。有的支持无线投屏，有的只支持有线。有的支持双向控制，有的只能单向显示。所以，写投屏代码时一定要做好兼容性处理。
3.4 应用层架构
应用层是咱们开发者最熟悉的。但Android Automotive的应用层有几个特殊之处：
第一，多窗口是标配。手机Android虽然也支持分屏，但车机上是强制多窗口。中控屏、仪表盘、副驾屏、后排屏，每个屏幕都可以独立运行应用。而且，不同屏幕之间还有交互——比如中控屏上的导航信息可以同步到仪表盘。
第二，驾驶模式限制。车辆行驶时，很多操作是被禁止的。比如视频播放、长文本输入。系统通过CarUxRestrictionsManager来管理这些限制。我建议你在开发车载应用时，一定要监听驾驶状态变化，及时调整UI。
第三，应用生命周期不同。手机Android的应用可以随时被用户切到后台。但在车上，导航、音乐这类应用通常需要常驻前台。系统会通过CarTaskMonitor来管理应用的优先级。
来看一个简单的应用层代码示例，演示如何获取车速：
// 获取Car实例
Car car = Car.createCar(context);
// 连接Car服务
car.connect();
// 获取车辆属性管理器
CarPropertyManager propertyManager =
(CarPropertyManager) car.getCarManager(Car.PROPERTY_SERVICE);
// 读取车速（单位：km/h）
float speed = propertyManager.getFloatProperty(
VehiclePropertyIds.PERF_VEHICLE_SPEED, 0);
// 注意：需要权限 android.car.permission.CAR_SPEED提示：上面的代码在模拟器上可能返回0，因为模拟器没有真实的CAN总线数据。我一般会在模拟器上用VehicleHalEmulator来模拟车速数据，方便调试。
3.5 与手机Android的差异
最后，咱们来总结一下Android Automotive和手机Android的核心差异。我画了一张图，帮你快速理解：
从这张图可以清楚看到，Android Automotive在每一层都做了「车载化」改造。我总结几个关键差异点：
- 多屏幕支持：手机Android原生只支持单屏，车机必须支持多屏异显
- 音频区域：手机只有一个音频输出，车机可以分区控制
- 电源管理：手机可以关机，车机必须支持快速唤醒和深度休眠
- 硬件接口：手机没有CAN总线，车机通过Vehicle HAL读写车辆数据
- 安全限制：手机没有驾驶模式限制，车机必须遵守驾驶安全规范
- 应用生态：手机应用可以自由安装，车机应用需要经过安全审核
重要提醒：千万不要把手机Android的代码直接搬到车机上。我见过一个团队把手机上的视频播放器直接移植到车机上，结果车辆行驶时视频还在播放，被安全测试直接打回。车机应用必须遵守CarUxRestrictions规则，否则无法通过认证。
好了，这一章的内容就到这里。Android Automotive的架构虽然复杂，但只要理解了它的设计初衷——为驾驶场景而生，很多问题就迎刃而解了。下一章我们会深入Vehicle HAL，看看它到底是怎么跟车辆硬件打交道的。
公众号:蓝海资料掘金营，微信deep3321