1、Android Automotive 概述：车载系统演进、Android Automotive 架构概览、与手机Android的区别
1.1 车载系统的演进之路
说实话，我入行那会儿，车载系统还处于「功能机」时代。那时候的车机，说白了就是个带屏幕的收音机加导航。我记得2015年第一次接触某德系车的IVI项目，系统还是基于QNX的，界面卡顿得让人抓狂。
车载系统的演进，大致经历了这么几个阶段：
- 第一阶段：纯嵌入式系统（2000-2010年）
封闭、定制化、无生态。每个车厂自己搞一套，互不兼容。我当年调一个CAN总线协议，整整折腾了两周。 - 第二阶段：Linux/QNX + 中间件（2010-2017年）
开始引入POSIX系统，但应用层还是各玩各的。GENIVI联盟就是这时候兴起的，不过说实话，生态碎片化太严重了。 - 第三阶段：Android Automotive 时代（2017年至今）
Google正式推出Android Automotive，把手机生态的成熟经验搬到了车上。嗯，这里要注意，Android Automotive和Android Auto完全是两码事，后面我会细说。
核心观点：车载系统的本质，正在从「硬实时控制」向「软实时服务」转变。你想想看，现在的用户要的不是一个能导航的车机，而是一个能跟手机、智能家居联动的「第三生活空间」。
1.2 Android Automotive 架构概览
Android Automotive的架构，说白了就是标准Android的「车载定制版」。我习惯把它分成四层来看：
| 层级 | 组件 | 说明 |
|---|---|---|
| 应用层 | 车载Launcher、设置、电话、媒体 | 基于CarAppLibrary开发，支持多窗口 |
| 框架层 | CarService、CarPropertyManager | 提供车辆硬件抽象接口 |
| 硬件抽象层 | Vehicle HAL、Audio HAL | 与ECU通信的桥梁 |
| 内核层 | Linux Kernel + 车载驱动 | 支持CAN、以太网、电源管理 |
这里我想重点聊聊CarService。我在项目中遇到过一个问题：为什么手机上的Android不能直接用在车上？原因就在于CarService。它负责管理车辆状态，比如车速、车门、空调、方向盘按键等。没有它，你的App根本不知道车现在是在行驶还是停车。
个人经验：刚开始做车载开发时，我总把CarService当成普通的系统服务。后来发现，它的生命周期管理非常特殊——车辆熄火后，系统会进入深度睡眠，CarService必须能优雅地保存状态。我曾经因为没处理好这个，导致用户每次启动车机都要重新配对蓝牙，被测试团队追着骂了一周。
1.3 与手机Android的核心区别
很多人问我：「Android Automotive不就是Android加了个车载壳吗？」
我的回答是：差远了。说白了，这是两个完全不同的物种。
我总结了几个关键区别：
- 窗口管理机制不同
手机Android是「单窗口全屏」逻辑，而车载系统必须支持「多窗口叠加」。比如导航App常驻后台，音乐App在前台，还要支持画中画显示倒车影像。嗯，这个后面章节会详细讲。 - 电源管理策略不同
手机可以随时关机重启，但车机不行。车辆熄火后，系统要进入「深度睡眠」而不是关机，同时还要保持CAN总线监听，以便用户按钥匙时能秒级唤醒。我见过一个项目，因为电源管理没做好，导致车辆停放一晚后电瓶亏电——这可不是闹着玩的。 - 安全优先级不同
手机App崩溃了，大不了重启。车载App崩溃？尤其是在高速行驶时导航突然黑屏，那后果就严重了。所以Android Automotive引入了「安全关键路径」的概念，某些系统进程是禁止被杀死的。 - 硬件抽象层不同
手机只需要管理触摸屏、摄像头、传感器。车机要管理的东西就多了：CAN总线、以太网AVB、车载麦克风阵列、多屏输出（仪表盘+中控+副驾屏+后排屏）。
避坑指南：我曾经接手过一个项目，团队直接把手机上的AOSP代码移植到车机上，结果发现车载的「多用户切换」逻辑完全不对。手机的多用户是给不同人用的，而车载的多用户是给「驾驶模式」和「停车模式」用的。这两个场景下的窗口策略完全不同——驾驶模式下，视频播放App必须被强制暂停。这个坑，我踩过，希望你别踩。
1.4 为什么选择Android Automotive？
你可能会问：既然QNX和Linux也能做车机，为什么Google要搞Android Automotive？
我个人觉得，核心原因就两个：
- 生态优势——全球有数百万Android开发者，车厂不需要重新培养一个车载开发团队。我见过很多传统车厂，招一个QNX工程师要等半年，而Android工程师一抓一大把。
- 迭代速度——手机Android每年一个大版本，车载系统也能跟上。传统嵌入式系统，一个版本用三年，等你想升级的时候，硬件已经过时了。
当然，Android Automotive也有它的短板。比如实时性不如QNX，安全认证流程复杂。但说实话，对于90%的车载场景，Android Automotive已经足够用了。
好了，这一章就到这里。下一章我会深入讲解Android Automotive的窗口管理核心——WindowManagerService在车载环境下的特殊实现。到时候我会分享一些我在实际项目中踩过的坑，比如多屏显示时的焦点管理问题，保证让你有收获。