1. 课程导入
大家好，我是老张。做车载开发这些年，我亲眼见证了车机系统从「能亮就行」到「智能座舱」的演变。今天咱们先聊聊 Android Automotive 到底是个什么东西，它跟 Android Auto 有什么区别，以及为什么各大车厂都在押注这个方向。
1.1 车载操作系统的发展简史
车载系统的发展，我把它分成三个阶段：
| 阶段 | 代表系统 | 特点 |
|---|---|---|
| 功能机时代 | WinCE、QNX、Linux 裁剪版 | 界面简陋，功能单一，基本没有生态 |
| 智能机时代 | Android Auto、CarPlay 投屏 | 手机算力外挂，车机只是个显示器 |
| 原生智能时代 | Android Automotive、鸿蒙座舱 | 系统直接跑在车机上，独立于手机 |
早期做车机，我接触过 WinCE 和 QNX。说实话，那会儿写个导航界面都得自己画控件，更别提联网了。后来 Android Auto 和 CarPlay 出来，算是把手机体验搬到了车上。但问题也很明显——你得先有台手机。
核心认知：Android Automotive 不是 Android Auto 的升级版，而是一个完全独立的、原生运行在车载硬件上的操作系统。
1.2 Android Automotive 与 Android Auto 的区别
这个问题我每次讲课都会被问到。很多人以为 Android Automotive 就是 Android Auto 的新名字，其实完全不是一回事。
我画了一张对比图，你看完就明白了：
我列个表格，把关键差异说清楚：
| 对比维度 | Android Auto | Android Automotive |
|---|---|---|
| 运行位置 | 手机端运行，车机端投屏 | 车机端原生运行 |
| 硬件依赖 | 依赖手机算力 | 依赖车机硬件 |
| 车辆访问 | 有限（通过协议桥接） | 直接访问 CAN、传感器、域控制器 |
| 应用生态 | 手机应用适配版 | 专为车载设计的原生应用 |
| 离线能力 | 弱（依赖手机网络） | 强（车机自带 4G/5G） |
| 多屏支持 | 有限 | 原生支持仪表、中控、HUD、后排屏 |
我的建议：如果你只是想把手机上的导航和音乐投到车上，Android Auto 就够了。但如果你要做真正的智能座舱——控制空调、读取车速、联动仪表盘——那就必须上 Android Automotive。
1.3 Android Automotive 的核心架构
Android Automotive 的底层还是 AOSP（Android Open Source Project），但 Google 在上面加了一层「汽车专用服务」。我画了张架构图：
这里有个关键点——Car Service。它是 Android Automotive 区别于普通 Android 的核心。通过 Car Service，应用可以读取车速、控制空调、获取方向盘按键事件。我在项目里踩过一个坑：直接去读 CAN 总线数据，结果被系统权限拦住了。后来才发现，所有车辆数据访问都必须通过 Car Service 的 API，不能绕过去。
注意：Android Automotive 的应用权限管理比手机版严格得多。比如读取车速、控制车窗这类操作，需要系统级签名权限。普通第三方应用默认拿不到。
1.4 Automotive 在车机领域的应用前景
说实话，这个方向现在很热。我列几个趋势：
- 多屏联动：仪表盘、中控屏、副驾屏、后排屏、HUD，五屏甚至七屏协同。Android Automotive 原生支持多 Display。
- 座舱域控：以前一个功能一个 ECU，现在一个芯片跑整个座舱系统。高通 8295、华为麒麟 9610A 都是这个路子。
- 生态开放：Google 在推 Automotive App Quality 标准，未来会有更多第三方应用上车。
- OTA 升级：系统级 OTA，不用去 4S 店刷机。我参与的项目里，OTA 已经能做到全量包 15 分钟升级完成。
你想想看，以后的车机就像手机一样，可以装应用、可以升级、可以个性化定制。这就是 Android Automotive 要干的事。
一句话总结：Android Automotive 不是把手机系统塞进车里，而是为汽车重新设计了一套操作系统。它懂车、能控车、能跟车深度绑定。
1.5 本章小结
这一章我们聊了三个核心问题：
- 车载系统从功能机到智能机的演变过程
- Android Automotive 与 Android Auto 的本质区别——一个原生、一个投屏
- Android Automotive 的架构分层：应用层 → Car Service → Framework → HAL → 内核