汤不热吧从移动端到座舱域：Android Automotive OS 的架构演进
Android Automotive OS（简称 AAOS）是 Google 专为汽车座舱设计的原生操作系统，与普通 Android Auto 不同，AAOS 直接运行在车载硬件上，无需手机配合即可独立完成导航、娱乐、语音交互和车辆控制等功能。目前，沃尔沃、Polestar、通用、雷诺、福特等主流车企已在其量产车型中部署 AAOS，而国内蔚来、理想等新势力也在其底层深度借鉴了 AAOS 的架构思想。本文将从系统架构、应用框架、服务层、定制化开发和性能调优五个维度，深入剖析 AAOS 的核心实现原理。
理解 AAOS 的第一步是厘清它与普通 Android 系统的关键差异。AAOS 基于 Android Open Source Project (AOSP) 分支，但在底层加入了大量车载特有的硬件抽象层（HAL）和系统服务。与手机 Android 不同，AAOS 不需要考虑电池续航优化（车辆供电充足），却必须面对车载环境的极端温度范围、启动时间要求（通常要求在 2 秒内显示倒车影像）、多屏交互（仪表盘+中控+副驾娱乐屏+后排屏）以及功能安全等严苛约束。
AAOS 系统架构分层详解
AAOS 的整体架构可分为五个层级，自底向上依次为：硬件抽象层（HAL）、核心操作系统层、车载服务层、应用框架层和应用层。以下逐一分析每一层的职责与实现要点。
1. 硬件抽象层（Vehicle HAL）
Vehicle HAL 是 AAOS 最核心的差异化组件。它通过标准化的接口将车辆信号（车速、车门状态、空调温度、转向灯等）抽象为可编程的属性（Property），供上层应用和服务调用。Vehicle HAL 的实现通常由芯片供应商（如高通、瑞萨、芯驰）或 Tier 1 厂商完成，OEM 只需关注上层逻辑。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// hardware/interfaces/automotive/vehicle/2.0/types.hal
enum VehicleProperty : int32_t {
// 车辆速度（千米/小时）
VEHICLE_SPEED = 0x11100100,
// 发动机转速
ENGINE_RPM = 0x11100101,
// 驾驶员车门状态
DOOR_POS_DRIVER = 0x11400300,
// 车内温度（摄氏度 * 10）
HVAC_TEMPERATURE_CURRENT = 0x12400200,
// 方向盘转角
STEERING_WHEEL_ANGLE = 0x11100500,
};
struct VehiclePropValue {
int32_t prop_id; // 属性 ID
int32_t area_id; // 区域（如左前门、右后门）
VehiclePropertyStatus status;
VehiclePropValueRawValue value; // 实际值（支持 int32/float/bytes/string 等类型）
int64_t timestamp; // 时间戳
};
Vehicle HAL 采用发布-订阅模式。服务端（车辆信号网关）持续向 HAL 层推送属性变更事件，HAL 层将这些事件向上转发给 CarService，后者再通过 Android 标准的 Binder 机制通知已注册的应用。这种架构确保了从物理信号到应用层的端到端延迟可控制在 100ms 以内，满足大多数座舱交互场景的需求。
2. 车载服务层（CarService & CarPropertyService）
CarService 是 AAOS 中连接 Vehicle HAL 和上层应用的中枢系统服务。它运行在 system_server 进程中，以 Android Binder 服务的形式暴露车辆控制 API。CarService 内部包含多个子管理器，每个管理器负责一类车辆功能：
| 管理器 | 接口类 | 典型功能 |
|---|---|---|
| CarPropertyManager | android.car.CarPropertyManager | 读取/设置任意车辆属性 |
| CarHvacManager | android.car.climate.CarHvacManager | 空调温度、风量、风向控制 |
| CarAudioManager | android.car.media.CarAudioManager | 音区控制、音量平衡、音频焦点 |
| CarSensorManager | android.car.hardware.CarSensorManager | 车速、油耗、续航里程等传感器数据 |
| CarNavigationManager | android.car.navigation.CarNavigationManager | 仪表盘导航指令透传（转弯提示等） |
| CarOccupantZoneManager | android.car.CarOccupantZoneManager | 多乘客分区感知与交互 |
AAOS 应用框架的关键组件
1. 多用户与多显示管理
AAOS 的一大特色是原生支持多用户（Multi-User）和多显示（Multi-Display）。驾驶员登录主用户，副驾和后排乘客可以各自登录子用户，每个用户拥有独立的应用数据、设置偏好和显示区域。系统通过 DisplayManager 和 WindowManager 的扩展接口分配不同的物理屏幕给不同用户进程：
2
3
4
5
6
7
8
9
10
11
12
13
PRODUCT_PACKAGES += \\
CarLauncher \\
CarHvacApp \\
CarMediaApp
// 配置主副屏
PRODUCT_VENDOR_PROPERTIES += \\
ro.sf.dual_display=true
// 为副屏分配独立的 Display ID
// frameworks/native/services/display/DisplayManagerService.java
// createVirtualDisplay() 创建虚拟显示输出到副屏物理接口
在 Android 11 及其之后的版本中，AAOS 引入了 occupancy zone（乘员区域）的概念。系统通过车内摄像头或座椅传感器检测每个座位是否有人，并自动为用户绑定到对应的显示区域。这对 HVAC 分区控制、音频分区和隐私策略的实现至关重要。
2. 音频架构与音区控制
车载音频是座舱体验的核心之一。AAOS 的音频系统基于 Android 原生 AudioFlinger 之上做了大量扩展。CarAudioService 负责管理音频焦点、音量分区和路由策略。每个乘员区的音频可以独立控制：驾驶员听导航提示时，副驾可以继续播放音乐，后排乘客可以看视频——互不干扰。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<carAudioConfiguration>
<zones>
<zone name="driver" address="bus_0">
<volumeGroup name="navigation">
<deviceAddress>bus_0_device_1</deviceAddress>
</volumeGroup>
<volumeGroup name="media">
<deviceAddress>bus_0_device_2</deviceAddress>
</volumeGroup>
</zone>
<zone name="passenger" address="bus_1">
<volumeGroup name="media">
<deviceAddress>bus_1_device_1</deviceAddress>
</volumeGroup>
</zone>
</zones>
</carAudioConfiguration>
实现音区控制的关键依赖是底层车载芯片的音频 DSP 必须支持多路独立音频流输出。高通 8155/8295 等座舱芯片通过其 DSP 模块可以同时处理 4-6 路独立的音频输出，AAOS 的 CarAudioService 在此基础上实现音频焦点仲裁和音量独立调节。
3. 投影模式（Projection）与 CarPlay/Android Auto 共存
AAOS 本身是一个完整的操作系统，但为了兼容用户习惯，它仍然支持投影模式——即通过 USB 或无线连接手机，将手机的 Android Auto 或 Apple CarPlay 界面投射到座舱屏幕上。AAOS 通过 CarProjectionService 管理这种投屏的生命周期，支持将投屏内容渲染到特定的显示区域（通常是中控屏上半部分或独立窗口）。
实现这一功能需要车载系统同时支持以下协议：
- Android Auto（有线/无线）：基于 AOA 2.0（Android Open Accessory）协议，通过 USB 连接后建立 TCP 隧道传输 UI 渲染数据
- Apple CarPlay（无线）：基于 CarPlay over Wi-Fi 协议，通过 WPA2 加密通道传输 H.264 编码的视频流
- HUAWEI HiCar：华为自研投屏协议，在国内市场占有率较高
AAOS 应用开发实战
1. 创建车载应用的基本框架
AAOS 应用开发与普通 Android 应用开发在 API 层面有较大差异。应用需要继承 CarActivity 而非 Activity，并使用 CarAppBar 替代标准的 ActionBar：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
<uses-library android:name="android.car" android:required="true" />
// 应用入口 Activity
public class MainCarActivity extends CarActivity {
private Car car;
private CarPropertyManager propertyManager;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
// 获取 Car 服务连接
car = Car.createCar(this, new Car.CarLifecycleListener() {
@Override
public void onCarConnected(Car car) {
propertyManager = (CarPropertyManager)
car.getCarManager(Car.PROPERTY_SERVICE);
// 注册车辆属性监听
propertyManager.registerCallback(propertyCallback,
VehicleProperty.VEHICLE_SPEED,
VehicleProperty.ENGINE_RPM);
}
@Override
public void onCarDisconnected() {
// 服务断开时清理资源
}
});
car.connect();
}
private final CarPropertyManager.CarPropertyEventCallback propertyCallback =
new CarPropertyManager.CarPropertyEventCallback() {
@Override
public void onChangeEvent(CarPropertyValue value) {
if (value.getPropertyId() == VehicleProperty.VEHICLE_SPEED) {
float speed = (float) value.getValue();
updateSpeedDisplay(speed);
}
}
@Override
public void onErrorEvent(int propertyId, int zone) {
Log.e(TAG, "Property error: " + propertyId);
}
};
}
2. 导航指令透传到仪表盘
AAOS 一个很酷的特性是导航应用可以将转弯指令（Turn-by-Turn）直接发送到仪表盘或 HUD。这避免了驾驶员扭头看中控屏的需求，提升了安全性。实现方式是通过 CarNavigationManager：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
.setTurnEvent(new TurnEvent.Builder()
.setTurnAngle(90)
.setTurnSide(TurnEvent.TURN_SIDE_LEFT)
.setStreetName("长安街")
.setManeuver(TurnEvent.MANEUVER_TURN_LEFT)
.setDistanceToTurnMeters(200)
.build())
.setNextTurnEvent(new TurnEvent.Builder()
.setTurnAngle(45)
.setStreetName("建国路")
.setManeuver(TurnEvent.MANEUVER_KEEP_LEFT)
.build())
.build();
CarNavigationManager navManager = (CarNavigationManager)
car.getCarManager(Car.NAVIGATION_SERVICE);
navManager.sendNavigationState(navState);
3. 空调与车辆控制
2
3
4
5
6
7
8
9
10
11
12
CarHvacManager hvac = (CarHvacManager)
car.getCarManager(Car.HVAC_SERVICE);
// Zone 1 为驾驶员区域
hvac.setTemperature(1, 22.0f);
// 设置风量到 5 档
hvac.setFanSpeed(1, 5);
// 开启 AC
hvac.setAcOn(true);
AAOS 的车载定制化与性能调优
1. 快速启动优化
车载系统对启动时间有严格要求。AAOS 通过多种机制实现秒级启动：
- SystemUID 预加载：将 Launcher 和核心系统 UI 进程设为 persistent 进程，随 system_server 一起启动
- Snapshot Boot（Android 12+）：将系统启动到完成桌面渲染后的内存状态保存为快照，下次启动直接加载快照而非完整 re-boot
- 精简 init 脚本：移除不必要的 native 服务和 SELinux 策略优化，减少启动阶段的服务注册时间
- 提前挂载 userdata 分区：修改 fstab 顺序，将关键数据分区提前挂载
2. 电源管理策略
虽然车辆供电比手机充裕，但 AAOS 仍需管理好电源状态以支持低功耗睡眠（Deep Sleep）和快速唤醒。当车辆熄火后，系统进入 Deep Sleep 状态，只保留 CAN 总线唤醒信号监听。检测到车门解锁或点火后，系统在 500ms 内完成唤醒并显示倒车影像。这是通过在 PMIC（电源管理芯片）层面配置唤醒源实现的。
3. 安全与隐私机制
AAOS 继承了 Android 的沙盒机制和 SELinux 强制访问控制策略，并在此基础上增加了车载特有的安全约束：
- 驾驶模式锁定：车辆行驶中禁止显示视频内容，限制文字输入操作，通过
1CarUxRestrictionsManager
强制执行
- 隐私分区：副驾和后排乘客的账户数据与驾驶员完全隔离，敏感操作（如导航历史、通话记录）仅限主用户访问
- 车辆信号访问控制：非系统级应用需要声明
1android.car.permission.CAR_SPEED
等权限才能读取车辆属性，OEM 可以自定义权限级别
2
3
4
5
6
7
8
9
10
CarUxRestrictionsManager uxManager = (CarUxRestrictionsManager)
car.getCarManager(Car.CAR_UX_RESTRICTION_SERVICE);
CarUxRestrictions ux = uxManager.getCurrentCarUxRestrictions();
if (ux.isRequiresDistractionOptimization()) {
// 车辆行驶中，限制视频播放
videoPlayer.setVisibility(View.GONE);
Toast.makeText(this, "行驶中无法观看视频", Toast.LENGTH_SHORT).show();
}
国内车厂对 AAOS 的定制化实践
虽然 Google 的正式版 AAOS 在国内无法直接使用 Google 移动服务（GMS），但国内主流车厂和 Tier 1 厂商普遍采用了一种”类 AAOS”方案——基于 AOSP 深度定制，保留 AAOS 的核心框架（Vehicle HAL、CarService、多屏管理），但剥离对 GMS 的依赖，替换为自研或第三方服务。这种方案的优势在于既利用了 AAOS 成熟的车载框架架构，又避免了 Google 授权的合规风险。
以高通 8295 芯片平台为例，典型的国内 AAOS 定制化方案包括：
- 替换 Maps API：使用百度地图 SDK 或高德地图车机版替代 Google Maps
- 语音引擎替换：集成思必驰、科大讯飞或百度语音替代 Google Assistant
- 应用商店：使用华为 AppGallery Auto 或自建应用市场替代 Google Play
- 账号系统：使用 OEM 自有的用户中心替代 Google Account
总结与展望
Android Automotive OS 正在成为智能座舱操作系统的中坚力量。与传统 QNX 和 Linux 方案相比，AAOS 的优势在于其成熟的应用生态、完善的开发者工具链（Android Studio 直接开发车载应用）、以及 Google 持续投入的快速迭代能力。但挑战也十分明显：系统启动时间仍需优化（Snapshot Boot 尚未在所有平台上成熟）、OTA 升级的兼容性管理复杂、以及国内 GMS 不可用导致的高度定制化成本。
展望未来，随着 Android 15 及后续版本进一步强化车载特性（如更完善的 VHAL 热插拔支持、更强的多屏多用户隔离机制），以及高通 Snapdragon Ride Flex、英伟达 Thor 等新一代异构芯片的量产，AAOS 在智能座舱中的地位将更加稳固。对于座舱应用开发者和系统集成工程师而言，深入理解 AAOS 架构已经成为不可或缺的核心技能。
技术发展日新月异，建议读者持续关注 AOSP 的 automotive 分支更新（source.android.com/docs/automotive）以及 Google I/O 上关于 AAOS 的最新动态，以跟上行业快步前进的节奏。