1、车载系统概述：Android Automotive简介、车载系统架构分层、与手机Android的区别、车载服务生态概览
大家好，我是你们这门课的主讲人。咱们直接开门见山。
说到车载系统，很多人第一反应是「不就是车上放个平板吗？」。嗯，我刚开始接触这个领域时，也这么想过。直到我真正参与了一个量产项目，才发现事情远没那么简单。今天这一章，我们先搭个框架，把 Android Automotive 到底是什么、长什么样、跟手机 Android 有啥区别，以及整个生态里都有谁，一次性讲清楚。
1.1 Android Automotive 是什么？
Android Automotive，注意不是 Android Auto。后者只是手机投屏，前者是真正跑在车机硬件上的完整操作系统。说白了，它就是 Google 专门为汽车打造的 Android 发行版。
我个人习惯把它理解成「去掉电话、短信、相机，加上空调、车窗、导航、仪表盘」的 Android。它不再依赖手机，自己就是一个独立的智能终端。
为什么会这样？因为汽车厂商需要一套能深度定制、又能快速迭代的系统。Android 开源、生态成熟，自然成了首选。我在项目中遇到过一家主机厂，他们之前用 Linux 从头攒系统，结果一个空调面板的动画效果就折腾了三个月。后来换了 Android Automotive，同样的功能两周搞定。
核心要点：Android Automotive 是原生车载操作系统，不是手机投屏方案。
1.2 车载系统架构分层
咱们来看看 Android Automotive 的架构。它跟手机 Android 很像，但多了几个关键层。我习惯从上往下讲，这样更符合开发者的视角。
| 层级 | 说明 | 我踩过的坑 |
|---|---|---|
| 应用层 | 车载专用 App（如 Launcher、HVAC、Media） | Launcher 的焦点管理，稍不注意就导致方向盘按键失灵 |
| Framework 层 | CarService、Vehicle HAL、权限管理 | CarService 启动顺序错了，空调界面直接黑屏 |
| 硬件抽象层 | Vehicle HAL（VHAL），连接 Framework 和硬件 | VHAL 的 Property ID 定义错了，车窗死活升不上去 |
| 内核与驱动层 | Linux Kernel + 车载专用驱动（CAN、GPIO） | 曾经因为 CAN 驱动中断优先级没调好，导致导航卡顿 |
这里重点说一下 Vehicle HAL。它是车载系统的「翻译官」。上层 App 说「我要把温度调到 25 度」，VHAL 就把它翻译成 CAN 总线能懂的信号。嗯，这里要注意：VHAL 的接口设计一旦定下来，后期改起来非常痛苦。我建议你在项目初期就拉上硬件团队，把每个 Property 的读写权限、类型、范围都敲死。
避坑指南：我曾经因为 VHAL 中一个布尔值属性的初始状态没处理好，导致车辆上电后空调自动开启。用户投诉说「车还没开，电先耗了一半」。从那以后，我要求所有 VHAL 属性必须有明确的默认值。
1.3 与手机 Android 的区别
很多人问我：「都是 Android，能有多大区别？」区别大了去了。我列几个最关键的差异点。
- 电源管理不同：手机可以关机，车机不行。车机有 ACC、ON、OFF 多种状态，而且不能随便休眠。你想想看，如果导航到一半，车机突然休眠了，那不得出事？
- 显示系统不同：手机通常一个屏，车机至少两个（中控+仪表），高端的有五个甚至更多。多屏互动、跨屏拖拽、异显同步，这些都是手机没有的。
- 输入方式不同：手机靠触摸，车机还要支持旋钮、方向盘按键、语音。而且触摸区域不能太小，否则开车时点不准。我记得有个项目，他们把手机上的「关闭」按钮直接搬到了车机上，结果被用户骂惨了——按钮太小，开车根本点不到。
- 安全要求不同：手机死机了重启就行，车机死机了可能影响行车安全。所以 Android Automotive 引入了「安全分区」和「看门狗」机制。说白了，就是系统要能自己检测自己有没有挂掉，挂了要能自动恢复。
- 生命周期管理：手机 App 可以随便杀后台，车机不行。比如导航 App，你切到音乐界面，导航还得在后台继续播报。所以 Android Automotive 引入了「Car App 优先级」的概念。
警告：千万不要把手机上的「一键清理后台」功能直接移植到车机上。我曾经见过一个团队这么干，结果导航被清掉了，司机在高速上错过了出口。嗯，后果很严重。
1.4 车载服务生态概览
最后，咱们聊聊车载服务生态。Android Automotive 不是孤立的，它需要跟一堆服务打交道。
- 地图与导航服务：高德、百度、Google Maps。这里有个坑：车机地图的定位精度要求比手机高，因为要支持车道级导航。我建议你直接使用厂商提供的 SDK，别自己写定位算法。
- 语音助手服务：小度、小爱、天猫精灵。语音是车载交互的核心，没有之一。你想想看，开车时用手点屏幕多危险。所以语音的唤醒率、识别率、响应速度，直接决定了用户体验。
- 音乐与音频服务：QQ 音乐、网易云、喜马拉雅。这里要注意音频焦点管理。导航播报时，音乐要自动降低音量；来电时，所有音频要暂停。Android Automotive 的 AudioManager 有一套专门的策略，跟手机不一样。
- 车辆控制服务：空调、车窗、座椅、灯光。这些通过 VHAL 与车辆硬件交互。我建议你把车辆控制做成一个独立的 Service，不要跟 UI 层耦合。否则换一个 UI 主题，整个控制逻辑都要重写。
- OTA 升级服务：系统升级、应用升级、固件升级。车机的 OTA 比手机复杂得多，因为要保证升级过程中车辆不能断电。而且升级失败要有回滚机制。我曾经遇到过一次 OTA 升级到一半，用户把车开走了，结果系统变砖。后来我们加了「升级前检测车辆状态」的逻辑。
好了，第一章的内容就到这里。这一章我们搭了个大框架，后面每一章都会深入一个具体的技术点。下一章，我会带大家手把手搭建 Android Automotive 的开发环境，包括 AOSP 源码下载、模拟器配置、以及第一个车载 App 的编译运行。到时候见。