1. Android Automotive 概述：什么是 Android Automotive、与 Android Auto 的区别、车载系统架构概览
大家好，我是你们的老朋友。今天咱们正式开讲《Android Automotive 系统服务深度解析》的第一章。
说实话，每次开新课程我都有点小兴奋。尤其是讲车载系统——这个领域变化太快了。几年前大家还在争论“车机到底要不要用安卓”，现在呢？几乎成了标配。
好，咱们直接进入正题。
1.1 什么是 Android Automotive？
Android Automotive，说白了，就是 Google 为汽车量身定制的原生 Android 操作系统。它直接跑在车机的硬件上，不依赖手机。
你想想看，传统车机是什么样？要么是 QNX，要么是 Linux 改一改，再加个定制 UI。每个厂商自己搞一套，底层千奇百怪。开发者想做个导航应用？得适配七八种平台，累死。
Android Automotive 的出现，就是为了解决这个痛点。
它跟手机上的 Android 同源，但做了大量裁剪和增强。比如：
- 去掉了电话、短信等手机专属功能——车机不需要这些
- 增加了车辆相关的 API——比如车速、车门状态、空调控制
- 重新设计了 UI 框架——要适合驾驶场景，不能分散注意力
- 引入了 Car Service——这是车载系统的核心服务，后面我们会花好几章来讲
我记得第一次接触 Automotive 项目时，心里还嘀咕：“这不就是改改 UI 吗？”结果一深入才发现，完全不是那么回事。底层架构、权限模型、生命周期管理，全都不一样。
核心要点：Android Automotive 是一个完整的、独立的操作系统。它运行在车机硬件上，提供车载应用运行环境，并通过 Car Service 与车辆硬件交互。
1.2 Android Automotive 与 Android Auto 的区别
这个问题，我几乎每次培训都会被问到。很多人搞混这两个概念，很正常。名字太像了。
咱们用一个表格来对比，一目了然：
| 对比维度 | Android Automotive | Android Auto |
|---|---|---|
| 运行位置 | 车机硬件上直接运行 | 手机上运行，投射到车机屏幕 |
| 是否需要手机 | 不需要，独立运行 | 必须连接手机 |
| 系统完整性 | 完整的操作系统 | 只是一个应用模式/投射协议 |
| 应用生态 | 专为车载优化的原生应用 | 手机应用的投射版本 |
| 车辆控制能力 | 强，可直接控制车辆硬件 | 弱，只能读取部分信息 |
| 典型代表 | 沃尔沃 Polestar 2、宝马 iDrive 8 | 几乎所有支持 Android Auto 的车型 |
简单来说：Android Auto 是“手机投屏”，Android Automotive 是“车机原生系统”。
我曾经遇到一个客户，非要我们在 Automotive 上跑 Android Auto 的应用。嗯，理论上可以，但体验很差。因为 Android Auto 的应用设计时假设了手机的存在，很多功能依赖手机的网络和传感器。强行移植，反而会出问题。
我的建议：如果你要开发车载应用，先搞清楚目标平台。如果是 Automotive，就按 Automotive 的规范来；如果是 Auto，就按手机应用的标准来。别混着来，容易踩坑。
1.3 车载系统架构概览
好，接下来咱们看看 Android Automotive 的整体架构。这部分很重要，后面的章节都会围绕这个架构展开。
我把架构分成四层，从上到下：
1.3.1 应用层（Application Layer）
这一层就是我们平时看到的那些车载应用：导航、音乐、电话、车辆设置等。
跟手机不同的是，车载应用有严格的驾驶安全约束。比如：
- 驾驶中不能播放视频（除非是副驾或后排）
- 导航应用必须优先显示
- 通知不能弹窗干扰驾驶
这些约束由 Car UX Restrictions 模块管理。嗯，这个模块很有意思，后面我们会专门讲。
1.3.2 框架层（Framework Layer）
这一层是 Android Automotive 的核心。它包含：
- Car Service：车载系统的“大脑”，管理车辆状态、应用生命周期、驾驶模式等
- Car API：提供给应用开发者使用的接口，比如获取车速、控制空调
- Vehicle HAL：硬件抽象层，屏蔽不同厂商的硬件差异
- Car App Library：一些通用的车载 UI 组件和工具类
我个人觉得，Car Service 是整个系统最复杂、也最精彩的部分。它要处理的事情太多了：
- 车辆启动时，要按顺序启动各个服务
- 车辆熄火时，要优雅地关闭，不能丢数据
- 驾驶模式切换时，要通知所有应用
- 还要处理各种车辆事件，比如车门开关、安全带状态
我曾经在一个项目中，Car Service 启动顺序没调好，导致每次车辆启动后，空调要等 30 秒才能响应。用户投诉说“这车机还不如十年前的老车”。后来我们花了整整一周，才把启动时序理顺。
1.3.3 硬件抽象层（HAL Layer）
这一层的作用，说白了就是“让上层代码不关心底层硬件是谁家的”。
Android Automotive 定义了一套标准的 Vehicle HAL 接口。车厂只需要实现这些接口，上层就能正常工作。
比如，获取车速：
// Vehicle HAL 接口定义
public class VehicleHAL {
// 获取当前车速（km/h）
public abstract float getVehicleSpeed();
// 获取发动机转速（rpm）
public abstract int getEngineRpm();
// 控制车窗升降
public abstract void setWindowPosition(int windowId, int position);
}不同厂商的硬件实现可能完全不同。有的用 CAN 总线，有的用以太网，有的用私有协议。但只要实现了这个接口，上层代码就不用改。
注意：HAL 层的性能很关键。我曾经见过一个项目，HAL 层读取车速的延迟高达 200ms，导致导航应用显示的车速总是慢半拍。用户在高架上开着 120km/h，导航还显示 100km/h，这体验能好吗？所以，HAL 层的实时性一定要保证。
1.3.4 内核层（Kernel Layer）
这一层就是 Linux 内核，加上一些车载相关的驱动和补丁。
Android Automotive 对内核有一些特殊要求：
- 实时性：某些车辆控制需要微秒级的响应
- 安全性：要支持 SELinux，隔离不同应用的权限
- 稳定性：不能随便崩溃，车机死机可不是闹着玩的
嗯，内核层咱们不会深入太多，毕竟这是系统服务课程，不是内核课程。但了解它的存在和职责，还是很有必要的。
1.4 架构图（文字描述）
虽然不能放图片，但我用文字描述一下这个架构的层次关系：
+------------------------------------------+
| 应用层 |
| (导航、音乐、电话、车辆设置等) |
+------------------------------------------+
| 框架层 |
| Car Service | Car API | Vehicle HAL |
| Car App Library | UX Restrictions |
+------------------------------------------+
| 硬件抽象层 |
| Vehicle HAL 实现 (CAN/以太网/私有协议) |
+------------------------------------------+
| 内核层 |
| Linux Kernel + 车载驱动 + SELinux |
+------------------------------------------+
| 硬件层 |
| (SoC、传感器、执行器、总线等) |
+------------------------------------------+每一层都依赖下一层提供的服务，同时向上层屏蔽细节。这就是分层架构的好处——各司其职，互不干扰。
1.5 本章小结
好，第一章的内容就到这里。咱们回顾一下：
- Android Automotive 是原生车载操作系统，独立运行在车机上
- 它和 Android Auto 是两码事，一个是系统，一个是投屏
- 车载系统架构分四层：应用层、框架层、HAL 层、内核层
- Car Service 是核心，后面我们会重点讲解
下一章，咱们会深入 Car Service 的启动流程。我会带着大家一步步看代码，看看车辆启动时，系统到底在干什么。
到时候见。