AAOS设备节点监听与uevent机制驱动开发 - 第1节
1.1 Android Automotive OS 架构全景
Android Automotive OS（AAOS）是 Google 专为车载环境打造的完整操作系统，其架构在 AOSP 基础上针对车辆硬件、安全、交互和生命周期做了深度定制。AAOS 采用分层架构，从上到下依次为：
核心分层：应用层 → 应用框架层 → 系统服务层 → HAL 硬件抽象层 → Linux 内核层。每一层都针对车载场景增加了专用模块。
1.2 AAOS 与 AOSP 的核心区别
AAOS 并非简单地在 AOSP 上叠加车载应用，而是从系统底层到上层框架做了大量定制。下表从多个维度对比两者的关键差异：
| 对比维度 | AOSP（通用 Android） | AAOS（车载 Android） |
|---|---|---|
| 目标设备 | 手机、平板、手表、电视 | 车载信息娱乐系统（IVI）、数字仪表盘 |
| 用户交互 | 触摸为主，多指手势 | 触摸 + 旋钮 + 方向盘按键 + 语音 |
| 电源管理 | 电池供电，深度睡眠/唤醒 | 车载电源（12V/48V），ACC 信号控制，常电模式 |
| 硬件抽象 | Camera HAL、Sensor HAL、Audio HAL | 增加 Vehicle HAL，定义车辆属性（速度、车门、空调等） |
| 多用户 | 可选，非核心场景 | 强制多用户，驾驶/乘客/访客模式隔离 |
| 安全要求 | 应用沙箱、权限模型 | ISO 26262 功能安全、ASIL 等级、安全启动 |
| 设备节点 | 标准 Linux 设备节点（/dev/） | 增加车载专用设备节点（CAN、GPIO、PWM、ADC） |
| uevent 用途 | USB 热插拔、SD 卡挂载 | 车辆状态变化（点火、车门、充电）、传感器接入 |
关键认知：AAOS 在 AOSP 基础上新增了 Vehicle HAL 和 CarService 两大核心模块。Vehicle HAL 负责与车辆硬件通信，CarService 则向上层应用提供统一的车辆属性接口。设备节点监听和 uevent 机制正是连接 Vehicle HAL 与 Linux 内核的桥梁。
1.3 AAOS 在车载领域的应用场景
AAOS 已广泛应用于全球主流车厂的量产车型中，覆盖以下典型场景：
1.3.1 信息娱乐系统（IVI）
- 导航与地图：Google Maps Automotive、高德地图车机版，支持实时路况、充电站规划
- 媒体播放：Spotify、Apple Music、本地 USB/蓝牙音频，支持多音区控制
- 语音助手：Google Assistant、百度 DuerOS，支持免唤醒词控制空调、车窗
- 应用生态：通过 Google Play 商店或第三方应用市场安装车载适配应用
1.3.2 数字仪表盘与 HUD
- 仪表盘渲染：使用 Android SurfaceFlinger 实现 60fps 流畅渲染，显示车速、转速、续航
- HUD 投射：将导航指示、ADAS 警告投射到前挡风玻璃
- 多屏互动：中控屏、仪表屏、副驾屏、后排屏独立显示与协同
1.3.3 车辆控制与车身域
- 空调控制：通过 Vehicle HAL 读取/设置温度、风量、风向
- 门窗控制：监听车门状态 uevent，控制车窗升降、门锁
- 灯光控制：根据环境光传感器自动切换远近光、氛围灯
- 充电管理：监听充电桩插入/拔出 uevent，管理电池状态
1.3.4 智能驾驶辅助（ADAS）集成
- 传感器数据接入：通过设备节点读取超声波雷达、毫米波雷达、摄像头数据
- 报警提示：车道偏离、前向碰撞预警通过 AAOS 音频/视觉通道输出
- 泊车辅助：360° 环视影像拼接与显示
工程注意：在车载场景中，设备节点监听不能采用轮询方式，必须使用 uevent 异步通知机制。轮询会占用 CPU 资源、增加功耗，且无法满足 ISO 26262 对实时性的要求。本课程后续章节将深入讲解如何基于 uevent 实现高效、可靠的设备节点监听驱动。
1.4 本章小结
- AAOS 是 Google 面向车载场景的完整操作系统，采用分层架构，在 AOSP 基础上增加了 Vehicle HAL 和 CarService 等车载专用模块。
- AAOS 与 AOSP 在目标设备、电源管理、硬件抽象、多用户、安全要求、设备节点和 uevent 用途等方面存在显著差异。
- AAOS 广泛应用于信息娱乐、数字仪表盘、车辆控制和 ADAS 集成四大场景，设备节点监听与 uevent 机制是连接上层服务与底层硬件的关键通道。