第一章：Android Automotive概述

1.1 车载系统发展史

说实话，我入行那会儿，车载系统还停留在「能听收音机就不错」的阶段。那时候的车机，说白了就是个带屏幕的MP3播放器。嗯，让我给你捋一捋这段历史。

第一阶段：功能机时代（2000-2010）

这个阶段的车载系统，核心功能就是导航+音乐。我记得最早接触的是WinCE系统，那玩意儿启动要半分钟，地图数据还得刻光盘。你想想看，那时候开车去陌生城市，得提前规划好路线，因为导航一旦跑偏，重新计算路线能急死人。

第二阶段：智能机萌芽（2010-2015）

Android和iOS的爆发，彻底改变了车载系统。特斯拉率先把17寸大屏塞进车里，我当时看到第一反应是「这玩意儿不会挡视线吗？」后来发现，人家玩的是生态。这个阶段，CarPlay和Android Auto开始出现，说白了就是把手机投屏到车机上。

第三阶段：原生车载系统（2015至今）

Google在2017年正式推出Android Automotive，注意，这不是Android Auto那种投屏方案，而是真正跑在车机硬件上的原生系统。我在2018年参与过一个项目，客户要求从QNX迁移到Android Automotive，那叫一个折腾。不过现在回头看，这个方向是对的。

1.2 Android Automotive与AOSP的区别

很多新手会问：「Android Automotive不就是AOSP改个UI吗？」

我刚开始也这么想，直到被坑过一次才明白——这两者差别大了去了。

对比维度	AOSP	Android Automotive
核心定位	通用移动平台	车载专用平台
应用模型	全屏应用	多窗口、分屏、仪表盘
电源管理	手机电池模式	车载电源（常电+ACC）
硬件抽象	标准HAL	Vehicle HAL（VHAL）
音频策略	简单音频路由	多音区、紧急优先级
安全要求	一般安全	ISO 26262功能安全

举个例子，AOSP的电源管理是给手机设计的，屏幕一关就进休眠。但车载系统不一样，车熄火了，防盗系统、远程控制这些还得跑着。我曾经遇到一个bug，车停了一晚上，第二天电瓶亏电了——就是因为没处理好常电和ACC的切换逻辑。

1.3 系统架构总览

Android Automotive的架构，说白了就是「三层两通道」。

应用层

• 车载专用应用：Launcher、Settings、Phone等
• 第三方应用：通过Google Play Automotive分发
• 仪表盘应用：独立于中控的显示域

框架层

• CarService：核心服务，管理车辆状态
• Vehicle HAL：硬件抽象层，连接车控ECU
• Audio Policy：多音区管理，比如导航和音乐可以走不同声道

内核层

• Linux Kernel + 实时补丁
• 硬件驱动：CAN、以太网、显示
• 安全隔离：TrustZone、Hypervisor

我记得第一次看Android Automotive的架构图，最让我困惑的是「为什么要有两个显示系统？」后来才明白，中控和仪表盘是物理隔离的。中控可以卡顿，但仪表盘必须流畅——这关系到驾驶安全。

嗯，这里要提一下VHAL。它是整个系统的关键，负责把车辆信号（车速、转向、灯光等）转换成Android能理解的接口。我见过最坑的VHAL实现，是把所有信号都轮询读取，结果CPU占用率直接飙到80%。正确的做法是用回调机制，只有信号变化时才通知上层。

// VHAL回调示例
public class VehicleCallback extends IVehicleCallback.Stub {
    @Override
    public void onPropertyEvent(VehiclePropValue[] propValues) {
        for (VehiclePropValue value : propValues) {
            switch (value.prop) {
                case VehicleProperty.SPEED:
                    // 车速变化，更新仪表盘
                    updateSpeedometer(value.value.int32Values[0]);
                    break;
                case VehicleProperty.HVAC_TEMP:
                    // 空调温度变化
                    updateHvacTemp(value.value.floatValues[0]);
                    break;
            }
        }
    }
}

这个回调机制，说白了就是「别主动问，等通知」。我在项目中遇到过，有人把轮询间隔设成10ms，结果系统负载直接炸了。后来改成事件驱动，CPU占用率降到了5%以下。

最后说一句，Android Automotive的架构设计，核心思想就是「安全第一，功能第二」。所有设计决策，都要先问一句：「如果这个功能出问题，会不会影响驾驶安全？」