2、Android Automotive OS 整体架构:分层架构总览

好,咱们正式开始聊架构。很多朋友第一次接触车机系统,都会问一个问题:这玩意儿跟手机上的 Android 到底有啥区别?

嗯,这个问题问得好。我当年刚转到车载项目时,也带着同样的疑惑。说白了,Android Automotive OS(简称 AAOS)并不是一个全新的系统,它是在 AOSP(Android 开源项目)基础上,针对汽车场景做了大量定制和裁剪。但它的骨架——也就是分层架构——跟手机 Android 是一脉相承的。

今天我们就从整体架构入手,把每一层拆开来看。你想想看,搞懂了分层,你就掌握了 AAOS 的“地图”,后面再深入细节就不会迷路。

Android Automotive OS 分层架构总览 应用层(Application Layer) 车载HMI · 地图导航 · 媒体应用 · 车辆设置 · 第三方应用 框架层(Framework Layer) CarService · Car API · 车辆属性管理 · 音频策略 · 显示管理 Android系统服务(AMS、WMS、PMS等) 硬件抽象层(HAL) Vehicle HAL · Audio HAL · Camera HAL · Sensor HAL 内核层(Linux Kernel) 硬件驱动 · 电源管理 · 内存管理 · 安全模块 · CAN总线驱动

2.1 应用层:看得见的“面子”

应用层是用户直接接触的部分。在手机上,你看到的是桌面、拨号、短信、微信。在车机上,你看到的是仪表盘、中控大屏、空调控制、导航地图。

我个人习惯把应用层分成两类:系统级应用第三方应用

  • 系统级应用:比如 Launcher(桌面)、Settings(设置)、Phone(蓝牙电话)、Media(音乐播放器)。这些是 AAOS 自带的,OEM 厂商可以深度定制 UI。
  • 第三方应用:比如高德地图车机版、QQ 音乐车机版、喜马拉雅车载版。这些应用通过 Google Play 或厂商应用商店分发。
注意:车机应用跟手机应用有个关键区别——驾驶安全。车机应用必须遵守“驾驶分心最小化”原则。比如视频播放器在车辆行驶时会被强制暂停,导航应用不能显示过于复杂的交互界面。

我记得在参与某款车型的 HMI 开发时,遇到过一个问题:第三方地图应用在横竖屏切换时崩溃。排查下来发现,车机屏幕的宽高比跟手机完全不同,应用没有适配好。嗯,这就是典型的“手机思维”带到车机上的坑。

2.2 框架层:承上启下的“里子”

框架层是 AAOS 最核心的部分。它既包含了标准 Android 的系统服务(ActivityManagerService、WindowManagerService、PackageManagerService 等),又新增了一套专门为汽车设计的服务——CarService

CarService 是 AAOS 的“灵魂”。它负责管理车辆相关的所有功能,比如:

  • 车辆属性(Vehicle Properties):车速、车门状态、空调温度、续航里程等
  • 音频策略(Audio Policy):导航音、电话音、媒体音、提示音的混音和优先级
  • 显示管理(Display Management):多屏异显(中控屏、仪表屏、副驾屏)
  • 驾驶模式(Driving Mode):停车时可操作全部功能,行驶中限制部分操作

你想想看,手机 Android 需要关心车速吗?不需要。但车机必须知道。这就是框架层最大的不同——它多了一层“汽车语义”的抽象。

一个小技巧:如果你要开发车机应用,建议先熟悉 android.car.* 命名空间下的 API。比如 CarPropertyManager 用来读取车辆传感器数据,CarAudioManager 用来控制音频焦点。这些 API 在手机 Android 上是没有的。

2.3 硬件抽象层:连接软硬件的“桥梁”

HAL 层的作用,说白了就是让上层框架不关心底层硬件是谁家的。你用的是博世的传感器还是大陆的传感器?上层代码不用改,只要 HAL 层实现了统一的接口就行。

在 AAOS 中,最重要的 HAL 是 Vehicle HAL。它定义了车辆属性(车速、转向、灯光、空调等)的标准接口。OEM 厂商需要根据自家硬件实现这个 HAL。

举个例子,读取当前车速:

// Vehicle HAL 接口示例(简化)
public class VehicleHal {
    // 获取车速(km/h)
    public float getVehicleSpeed() {
        // 不同厂商实现不同
        // 可能是从 CAN 总线读取,也可能是从传感器读取
        return canBusReader.getSpeed();
    }
}

我曾经在一个项目中踩过坑:某款车型的空调控制是通过私有 CAN 协议实现的,但 Vehicle HAL 的标准接口只支持通用的 HVAC(暖通空调)属性。最后我们不得不扩展了 HAL 层,添加了自定义属性。所以,做车机开发,一定要预留好 HAL 层的扩展能力。

2.4 内核层:最底层的“地基”

内核层就是 Linux Kernel,加上 Android 特有的驱动和补丁。在手机上,内核需要驱动摄像头、触摸屏、Wi-Fi、蓝牙等。在车机上,除了这些,还要驱动:

  • CAN 总线接口:车辆内部通信的骨干网络
  • 车载以太网:用于高速数据传输(如摄像头视频流)
  • GPS/GNSS 模块:定位导航
  • 车载诊断接口(OBD-II):车辆健康状态监测

内核层的稳定性至关重要。车机死机可不像手机死机那样重启就行——行驶中中控黑屏,那可是安全隐患。所以 AAOS 在内核层面做了很多实时性和安全性的增强。

避坑指南:我曾经遇到过一个问题——车辆在高温环境下(夏天暴晒后),内核的 CPU 调频策略导致系统卡顿。原因是车机的散热条件远不如手机,默认的调频策略过于激进。解决方案是修改内核的 cpufreq 参数,降低最高频率,优先保证稳定性。

2.5 与手机 Android 的异同总结

说了这么多,咱们用一张表来总结 AAOS 和手机 Android 的核心差异:

对比维度 手机 Android Android Automotive OS
核心服务 AMS、WMS、PMS 等标准服务 标准服务 + CarService + Vehicle HAL
交互方式 触摸为主 触摸 + 旋钮 + 语音 + 方向盘按键
显示系统 单屏为主 多屏异显(中控、仪表、HUD)
音频策略 简单优先级 多音区、多通道、驾驶安全优先级
电源管理 电池供电,深度睡眠 车载电源,常电 + ACC 模式
安全要求 数据安全为主 功能安全(ISO 26262)+ 数据安全
硬件接口 USB、Wi-Fi、蓝牙、NFC CAN、车载以太网、LIN、FlexRay

看到这张表,你应该明白了——AAOS 不是“手机 Android 改一改”,而是一个从底层到上层都做了针对性设计的系统。它保留了 Android 的生态优势(应用开发框架、Google 服务、开发者工具),同时加入了汽车行业必须的功能安全、多屏交互、车辆控制等能力。

嗯,这一章的内容就到这里。记住这个分层架构,后面我们深入每一层时,你就能知道当前讲的内容属于哪个层次,起到什么作用。


公众号:蓝海资料掘金营,微信deep3321