2. AOSP与AAOS：AOSP基础架构、AAOS新增组件、Google Automotive Services (GAS) 介绍
好，我们直接进入正题。这一章，我们来聊聊AOSP和AAOS到底差在哪。
很多刚接触车载的朋友会问我：「车载系统不就是Android改个UI吗？」
嗯，这么说吧——如果AOSP是毛坯房，那AAOS就是精装修过的智能住宅。但精装修不是随便贴个壁纸就完事了，它动了整个房子的水电结构。
2.1 AOSP基础架构：你得先知道地基长什么样
先回顾一下AOSP。我习惯把Android系统架构分成四层，从上往下看：
- 应用层——你写的那些APK，包括系统UI、Launcher、设置等。
- 应用框架层——Java API，比如ActivityManager、WindowManager、PackageManager这些服务。
- 系统运行层——包括ART虚拟机、Native库（libc、SurfaceFlinger等）、HAL层。
- Linux内核层——驱动、内存管理、进程调度这些底层能力。
说白了，AOSP给手机厂商留了很多「定制空间」。比如你可以换Launcher、改SystemUI、甚至替换掉默认的电话应用。但车载场景不一样——你不能让用户随便装个第三方Launcher就把中控台搞得面目全非，对吧？
核心差异点： AOSP是为「手持设备」设计的，交互以触摸为主，生命周期管理围绕「前台/后台」切换。而AAOS是为「驾驶场景」设计的，交互以方向盘、旋钮、语音为主，生命周期管理围绕「驾驶安全」。
我在做第一个车载项目时，踩过一个坑：直接把手机上的后台策略搬到了车机上。结果导航在后台被杀了，用户开着开着找不到路……嗯，从那以后我明白了——车载系统不能简单复用手机的那套逻辑。
2.2 AAOS新增组件：Google往AOSP里塞了什么？
Google在AOSP基础上，为汽车场景新增了几个关键组件。我挑最重要的几个讲：
2.2.1 CarService —— 车载系统的「大脑」
CarService是AAOS最核心的服务。它运行在系统进程中，负责管理车辆硬件和上层应用的交互。
你可以把它理解成车载版的「SystemServer」。但它不是简单的复制——它专门处理车辆特有的功能：
- CarPropertyManager：管理车辆属性，比如车速、油量、车门状态。
- CarSensorManager：管理传感器数据，比如GPS、加速度计、陀螺仪。
- CarInfoManager：提供车辆信息，比如VIN码、车型、制造商。
举个例子，你想知道当前车速：
// 获取CarService实例
Car car = Car.createCar(context);
// 获取属性管理器
CarPropertyManager propertyManager = (CarPropertyManager) car.getCarManager(Car.PROPERTY_SERVICE);
// 读取车速（单位：km/h）
float speed = propertyManager.getFloat(VehicleProperty.PERF_VEHICLE_SPEED, 0);
我个人习惯把CarService看作一个「中间人」——它不直接操作硬件，而是通过Vehicle HAL与底层通信。这样做的好处是：上层应用不需要关心你是CAN总线还是以太网，CarService帮你屏蔽了差异。
2.2.2 Vehicle HAL —— 硬件抽象层的「汽车版」
Vehicle HAL是连接CarService和车辆硬件的桥梁。它定义了一组标准化的接口，用来读写车辆属性。
你想想看，不同车企的CAN协议千差万别。有的用J1939，有的用OBD-II，还有的自定义协议。如果没有Vehicle HAL，CarService就得为每种车型写一套适配代码——那维护成本就太高了。
Vehicle HAL的核心接口是IVehicle：
// Vehicle HAL 核心接口（简化版）
interface IVehicle {
// 获取所有支持的属性
VehiclePropConfig[] getAllProperties();
// 获取属性值
StatusCode get(VehiclePropValue request, VehiclePropValue[] outValue);
// 设置属性值
StatusCode set(VehiclePropValue value);
// 订阅属性变化
StatusCode subscribe(VehiclePropValue request, float sampleRate);
}
这里要注意：Vehicle HAL运行在独立的进程中，通过binder与CarService通信。这样做是为了隔离——即使HAL层崩溃，也不会影响到系统服务。
避坑指南： 我曾经在调试一个项目时，发现车速数据偶尔会跳变。排查了半天，最后发现是HAL层在读取CAN数据时没有做「去抖」处理。车辆信号本身就有噪声，你直接拿原始数据用，上层应用就会看到忽高忽低的值。所以，在HAL层或CarService层做数据滤波是必须的。
2.2.3 Car UI Library —— 专为驾驶场景设计的UI组件
Google提供了一套Car UI Library，包含了一些预制的UI组件：
- CarToolbar：顶部导航栏，支持返回、标题、操作按钮。
- CarDrawer：侧边抽屉菜单，用于切换应用。
- CarCardView：卡片式布局，适合展示音乐、导航等信息。
- CarScrollBar：大尺寸滚动条，方便旋钮操作。
这些组件都遵循了「驾驶安全」的设计原则——触摸目标不小于48dp，文字对比度足够高，动画时长控制在300ms以内。
我建议你在开发车载应用时，尽量使用这些组件。别自己从头写——你想想看，如果每个应用都自定义一套UI，用户在不同应用间切换时就会感到割裂。而且，Car UI Library已经帮你处理好了焦点管理、旋钮事件等车载特有的交互逻辑。
2.3 Google Automotive Services (GAS)：Google的「全家桶」
GAS是Google为AAOS提供的一套预装应用和服务。它和手机上的GMS（Google Mobile Services）类似，但针对驾驶场景做了深度定制。
GAS包含哪些东西？我列个表：
| 服务/应用 | 功能说明 | 与手机版的区别 |
|---|---|---|
| Google Maps | 导航、实时路况、POI搜索 | 专为驾驶优化，支持HUD投影、车道级导航 |
| Google Assistant | 语音控制、信息查询、设备控制 | 支持「Hey Google」唤醒，可控制车窗、空调 |
| Google Play Store | 应用商店 | 只展示「汽车优化版」应用，过滤掉不适合驾驶的应用 |
| Google Calendar | 日程管理 | 可自动导航到下一个会议地点 |
| YouTube | 视频播放 | 仅限停车时使用，行驶中自动禁用 |
这里有个关键点：GAS不是开源的。它是Google的专有服务，需要车企与Google签订授权协议才能使用。如果你做的是开源项目，或者不想依赖Google，那就只能用AOSP自带的组件。
我的建议： 如果你在做一个量产项目，而且目标市场是海外，那GAS几乎是必选项。因为用户已经习惯了Google Maps的导航体验，你很难自己做一个同样好用的地图应用。但如果你做的是国内市场，或者定制化程度很高的项目，那可以考虑用第三方服务替代GAS——比如高德地图、百度CarLife等。
2.4 三者之间的关系：一张图说清楚
我试着用一句话总结：
AOSP是基础，AAOS是AOSP的「汽车增强版」，GAS是AAOS上的「Google增值服务」。
具体来说：
- AOSP提供了Android的核心能力——应用管理、进程调度、UI框架等。
- AAOS在AOSP之上，增加了CarService、Vehicle HAL、Car UI Library等汽车专属组件。
- GAS在AAOS之上，提供了Google Maps、Assistant等用户直接感知的应用和服务。
你想想看，如果没有AOSP，AAOS就得从零开始写操作系统——那工作量就太大了。如果没有AAOS，GAS就没办法与车辆硬件交互——Google Maps怎么知道车速？怎么控制空调？
所以，这三者是层层递进的关系。每一层都依赖下一层提供的能力。
2.5 实际项目中的选择策略
最后，我分享一下在实际项目中如何选择：
- 如果你做的是开源项目：用AOSP + AAOS开源部分就够了。不要碰GAS，因为授权问题会很麻烦。
- 如果你做的是海外量产车：强烈建议用AAOS + GAS。用户对Google服务的依赖度很高，而且Google会帮你做合规认证。
- 如果你做的是国内量产车：可以用AAOS，但GAS在国内用不了。你需要自己找替代方案——比如用高德地图替换Google Maps，用百度语音替换Google Assistant。
- 如果你做的是定制化很强的项目：比如商用车、特种车辆，那可能连AAOS都不需要。直接在AOSP上做深度定制，只保留你需要的功能。
嗯，这一章的内容就到这里。下一章我们会深入CarService的内部实现，看看它到底是怎么管理车辆属性的。