1. 车机系统概述：Android Automotive与Android Auto的区别、车机系统架构、AOSP源码获取与分支选择
各位同学，欢迎来到《Android车机系统定制与编译实战》的第一章。
说实话，我刚开始接触车机开发时，也踩过不少坑。尤其是Android Automotive和Android Auto这两个概念，很多人一开始都搞混。今天咱们就把这事儿彻底理清楚。
1.1 Android Automotive vs Android Auto：别再傻傻分不清
这两个东西，名字像，但本质完全不同。我简单给你说透。
| 对比维度 | Android Automotive | Android Auto |
|---|---|---|
| 运行位置 | 直接跑在车机硬件上 | 手机投屏到车机屏幕 |
| 系统独立性 | 完整独立的操作系统 | 依赖手机，车机只是个显示器 |
| 硬件要求 | 车规级SoC，高可靠性 | 普通车机屏幕+手机 |
| 应用生态 | 专为车机设计的App | 手机App的驾驶模式 |
| 典型代表 | 沃尔沃XC40纯电版、Polestar 2 | 几乎所有支持CarPlay/Android Auto的车型 |
Android Automotive，说白了就是一套完整的Android系统，直接烧录在车机的硬件上。它不依赖任何手机，自己就能跑导航、听音乐、控制车辆设置。我参与过的一个项目，客户要求把Android 12移植到某款国产车机上，那就是典型的Automotive开发。
Android Auto呢？它其实只是个投屏协议。你的手机负责运算，车机屏幕只是显示和交互的终端。嗯，这里要注意：Android Auto不是操作系统，它只是个应用或服务。
核心区别一句话： Automotive是车机自己跑Android，Auto是手机跑Android投到车机上。
为什么会有人搞混？因为很多车厂宣传时，把"支持Android Auto"说成"搭载Android系统"，这误导了不少人。我建议你以后看车时，直接问销售：这车机是独立跑Android，还是需要连手机？
1.2 车机系统架构：从底层到应用层
车机系统的架构，其实和手机Android大同小异，但多了几个关键模块。我画个简化的分层图给你看：
┌─────────────────────────────────────┐
│ 应用层 (Launcher, 导航, 音乐) │
├─────────────────────────────────────┤
│ Automotive API / CarService │
├─────────────────────────────────────┤
│ 系统服务 (WMS, AMS, PMS...) │
├─────────────────────────────────────┤
│ HAL 层 (硬件抽象层) │
├─────────────────────────────────────┤
│ 内核层 (Linux Kernel + 驱动) │
├─────────────────────────────────────┤
│ 车规硬件 (SoC, CAN, 显示屏...) │
└─────────────────────────────────────┘从上往下，我挑几个重点说说：
1.2.1 CarService — 车机系统的灵魂
这是Android Automotive独有的服务。它负责管理车辆状态，比如车速、车门状态、空调温度、方向盘按键等。我在项目中遇到过一个问题：CarService启动顺序不对，导致导航App获取不到车速信息，定位一直飘。排查了两天才发现是Service的优先级配置错了。
1.2.2 Vehicle HAL — 硬件和系统的桥梁
Vehicle HAL是车机开发中最容易出问题的层。它定义了车辆属性和控制接口。比如你要读取当前车速，就得通过Vehicle HAL的get(VehicleProperty.PERF_VEHICLE_SPEED)来获取。
避坑指南： 我曾经在某个项目里，Vehicle HAL的属性和硬件实际支持的信号对不上，导致空调控制界面点了没反应。后来发现是HAL层的属性ID映射错了。所以，拿到硬件文档后，第一件事就是核对Vehicle HAL的属性列表。
1.2.3 多用户与安全机制
车机系统通常支持多用户：驾驶员、乘客、访客模式。每个用户的权限不同。比如驾驶员开车时不能看视频，但乘客可以。这个逻辑是在SystemUI和CarService里实现的。
1.3 AOSP源码获取与分支选择
好，理论说完了，咱们来点实操的。做车机开发，第一步就是拿到AOSP源码。但源码那么大，分支那么多，怎么选？
1.3.1 源码获取方式
我习惯用repo工具来管理AOSP源码。具体步骤：
# 1. 安装repo工具
mkdir ~/bin
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
# 2. 初始化仓库（以android-12.0.0_r32为例）
mkdir aosp_automotive
cd aosp_automotive
repo init -u https://android.googlesource.com/platform/manifest -b android-12.0.0_r32
# 3. 同步源码（这步最耗时，建议用国内镜像）
repo sync -j4 -c注意： 直接连Google的服务器下载，速度慢得你想哭。我建议用清华或中科大的AOSP镜像。比如：repo init -u https://mirrors.tuna.tsinghua.edu.cn/git/AOSP/platform/manifest -b android-12.0.0_r32
1.3.2 分支选择策略
分支怎么选？我个人的经验是：
- 看芯片平台： 高通平台通常用android-12.0.0_r32或android-13.0.0_rxx，联发科平台可能用更早的版本。你想想看，芯片厂商的BSP（板级支持包）决定了你能用哪个Android版本。
- 看项目周期： 如果项目要两年后上市，建议选最新的LTS版本。如果今年就要量产，选已经稳定验证过的版本。
- 看车厂要求： 有些车厂强制要求Android 12以上，因为Google对Automotive的支持从12开始才比较完善。
| Android版本 | 推荐分支 | 适用场景 |
|---|---|---|
| Android 11 | android-11.0.0_r48 | 老平台、低端车机 |
| Android 12 | android-12.0.0_r32 | 主流车机，推荐 |
| Android 13 | android-13.0.0_r41 | 新项目，长期维护 |
| Android 14 | android-14.0.0_r15 | 前沿项目，生态尚不完善 |
我的建议： 如果你刚开始学车机开发，从Android 12入手最稳妥。分支选android-12.0.0_r32，这个版本在车机领域验证得最多，资料也最全。
1.3.3 获取Automotive专用代码
普通的AOSP源码里，Automotive相关的代码是包含在内的。但有些车厂会提供额外的硬件适配包。比如高通的qcom_la分支，里面包含了显示、音频、GPS等驱动。
我记得有一次，客户给了个高通SA8155P的板子，我直接用AOSP主线编译，结果屏幕点不亮。后来才发现，必须用高通提供的qcom_la.v12.0分支，里面才有对应的显示驱动。
所以，拿到硬件后，先问芯片厂商要BSP分支。别自己瞎猜，不然编译出来跑不起来，排查问题能让你怀疑人生。
小结
这一章咱们把车机系统的基本概念理清了。Android Automotive和Android Auto的区别，说白了就是一个独立跑、一个靠投屏。车机架构的核心是CarService和Vehicle HAL，这两个层搞懂了，后面定制就顺了。源码获取和分支选择，记住一句话：先看芯片，再看项目周期，最后看车厂要求。
下一章，咱们开始搭建编译环境，手把手教你编译出第一个车机系统镜像。到时候你会看到，原来车机系统也没那么神秘。