一、车机系统概述：Android Automotive 与 AOSP 的区别
做车机移植这么多年，我经常被问到同一个问题：「Android Automotive 不就是 AOSP 改了个名字吗？」
嗯，这个问题其实挺有代表性的。我刚开始接触车机项目时，也这么想过。但实际动手做起来才发现——差远了。
1.1 Android Automotive 是什么？
Android Automotive 是 Google 专门为汽车打造的原生操作系统。它不是一个「改装版」，而是一个从底层就为车载场景设计的独立分支。
说白了，AOSP（Android Open Source Project）是给手机、平板用的。而 Automotive 是给车用的。两者虽然共享同一套内核和框架，但上层应用、交互逻辑、硬件抽象层完全不同。
核心区别一：应用生态
- AOSP：依赖 Google 移动服务（GMS），应用从 Play Store 下载
- Automotive：内置 Automotive 专用应用（如车载地图、媒体、电话），不支持普通手机应用直接运行
我记得第一次在车机上跑一个普通 AOSP 的 Launcher，结果触摸事件完全不对——因为车机用的是旋钮+触摸板，不是手机那种电容屏滑动。嗯，这个坑我踩过。
1.2 两者在架构上的差异
| 对比项 | AOSP | Android Automotive |
|---|---|---|
| 窗口管理 | 单窗口、多任务 | 多窗口、分屏、画中画（车载专用） |
| 输入系统 | 触摸为主 | 触摸+旋钮+方向盘按键+语音 |
| 电源管理 | 手机待机/休眠 | 车辆点火/熄火、深度睡眠、快速唤醒 |
| 音频策略 | 单一音频焦点 | 多音频区域（导航、电话、媒体独立控制） |
| 安全认证 | Google 认证 | Automotive 认证 + 车规级安全要求 |
你想想看，手机可以随便关机重启，但车机不行。车在行驶中，导航突然重启？那可不是闹着玩的。所以 Automotive 在稳定性、实时性、安全性上做了大量定制。
我的建议：如果你是从 AOSP 转过来做 Automotive，第一件事就是忘掉手机那套电源管理逻辑。车机的「熄火不关机」机制，会让你重新理解什么叫「系统休眠」。
二、车机硬件架构：SoC、MCU、GPU
车机的硬件架构，说白了就是「一个大脑 + 一个管家 + 一个画师」。
2.1 SoC（系统级芯片）—— 大脑
SoC 是车机的核心计算单元。它集成了 CPU、GPU、DSP、ISP、NPU 等模块。目前主流的有高通 SA8155/8295、瑞萨 R-Car H3、NXP i.MX8 等。
我个人习惯把 SoC 比作「车机的心脏」。它决定了系统的流畅度、应用启动速度、多任务能力。
选型时要注意：
- CPU 核心数：至少 4 核，推荐 8 核（A76/A78 架构）
- 制程工艺：7nm 以下（散热和功耗更友好）
- 车规级温度范围：-40°C ~ 85°C（消费级芯片扛不住）
我曾经在一个项目里用了消费级 SoC，结果夏天暴晒后车机直接死机。嗯，那之后我再也不敢省这个钱了。
2.2 MCU（微控制器）—— 管家
MCU 负责车机的实时控制和安全相关任务。它不跑 Android，而是跑 RTOS（实时操作系统）。
为什么需要 MCU？因为 Android 不是实时系统。你想想看，刹车信号来了，Android 还在 GC（垃圾回收）？那后果不堪设想。
MCU 负责的事情包括：
- 电源管理（点火/熄火时序）
- CAN 总线通信（车速、车门、灯光等）
- 安全监控（看门狗、温度检测）
- 唤醒管理（蓝牙、Wi-Fi、语音唤醒）
注意：MCU 和 SoC 之间通常通过 SPI/UART/I2C 通信。我曾经遇到过 MCU 发送的 CAN 数据包被 SoC 的 Android 层延迟处理，导致仪表显示滞后。解决方案是在 MCU 端做数据缓存和优先级标记。
2.3 GPU（图形处理器）—— 画师
车机的 GPU 不仅要渲染 UI，还要处理仪表盘、导航地图、360° 全景影像。这比手机游戏的要求高多了。
目前主流车机 GPU 有：
- 高通 Adreno 系列（SA8155 配 Adreno 640）
- ARM Mali 系列（瑞萨 R-Car 配 G610）
- Imagination PowerVR 系列（部分老平台）
我建议你在选 GPU 时，重点关注多图层合成能力。车机 UI 通常有 4-6 个图层（导航、媒体、仪表、HUD、倒车影像等），GPU 需要同时合成并输出到不同屏幕。
避坑指南：我曾经在一个项目里用了低端 GPU，结果 360° 全景影像的拼接算法跑不动，画面延迟超过 200ms。后来换了 Adreno 640，延迟降到 30ms 以内。所以，GPU 的钱不能省。
三、车机软件分层：应用层、框架层、HAL层、内核层
车机的软件架构，和手机 Android 类似，但每一层都有车载特有的定制。我按从顶到下的顺序给你捋一遍。
3.1 应用层（Application Layer）
这一层是用户直接看到的。包括：
- Launcher（主界面）
- 车载地图（高德、百度、Google Maps）
- 媒体播放（音乐、电台、视频）
- 电话/通讯
- 车辆设置（空调、座椅、灯光）
- 仪表盘应用（速度、转速、续航）
应用层开发，说白了就是写 Android App。但要注意：车机应用不能随便用第三方 SDK。比如定位服务，必须用车载专用的高精度定位 API，而不是手机那种粗略定位。
3.2 框架层（Framework Layer）
框架层是 Android 的核心。在车机上，Google 新增了以下关键模块：
- CarService：车机服务的核心，管理车辆状态、驾驶模式、车辆属性
- CarAudioService：多音频区域管理（导航、电话、媒体独立音量）
- CarInputService：旋钮、方向盘按键、触摸板等输入设备管理
- CarProjectionService：手机投屏（Android Auto / CarPlay）
- VehicleHalManager：车辆硬件抽象层管理
重点：框架层是移植工作的核心。你需要修改 CarService 来适配你的车辆属性（VHAL），修改 CarAudioService 来适配你的音频路由，修改 CarInputService 来适配你的物理按键。
3.3 HAL 层（Hardware Abstraction Layer）
HAL 层是 Android 和硬件之间的桥梁。在车机上，最重要的 HAL 是：
- Vehicle HAL（VHAL）：车辆属性接口（车速、车门、空调、灯光等）
- Audio HAL：音频路由和混音
- Camera HAL：车载摄像头（倒车影像、环视）
- Display HAL：多屏显示（中控、仪表、HUD）
- Sensors HAL：车辆传感器（GPS、IMU、轮速）
我做过最头疼的事，就是写 VHAL。每个车厂的 CAN 协议都不一样，你需要把 CAN 信号解析成 Android 能理解的 VehicleProperty。比如车速信号，有的车厂用 km/h，有的用 mph，还有的用脉冲数。嗯，这个坑我踩过不止一次。
注意：VHAL 的实现必须考虑实时性。我曾经见过一个项目，VHAL 通过 Java 层轮询 CAN 数据，结果延迟超过 500ms。正确的做法是在 Native 层用 C++ 实现，通过共享内存或 Binder 回调给 Java 层。
3.4 内核层（Kernel Layer）
内核层是 Android 的基础。在车机上，你需要关注：
- Linux 内核版本：推荐 5.10 以上（支持更多车规级驱动）
- 设备树（Device Tree）：描述硬件拓扑（SoC、外设、内存映射）
- 驱动开发：CAN 驱动、GPIO 驱动、I2C/SPI 驱动、显示驱动
- 电源管理：suspend/resume、wakeup sources、regulator
- 安全模块：SELinux、dm-verity、AVB（Android Verified Boot）
我个人习惯把内核层比作「地基」。地基不稳，上面盖的楼再漂亮也没用。我见过太多项目，应用层改得花里胡哨，结果内核驱动一塌糊涂，系统三天两头死机。
我的经验：移植车机系统，70% 的工作量在内核和 HAL 层。应用层反而是最简单的。所以，别急着写 UI，先把底层调稳了再说。
小结
这一章我们聊了：
- Android Automotive 和 AOSP 的区别——不是改名，是重写
- 车机硬件架构——SoC 是大脑，MCU 是管家，GPU 是画师
- 车机软件分层——应用层、框架层、HAL 层、内核层，每一层都有坑
下一章，我会带你搭建车机开发环境，包括 AOSP 源码下载、编译工具链配置、模拟器调试。到时候咱们手把手操作，你就能真正感受到车机移植的乐趣了。
嗯，今天就到这里。有什么问题，欢迎随时交流。