2. 车载Android系统与座舱环境认知

在手机或平板上开发 Android 应用，我们面对的是一个相对统一的运行环境：一块屏幕、一个前台用户、一套完整的 Google 移动服务、随时可用的网络与电源。而车载 Android（Android Automotive OS，简称 AAOS）从系统架构到运行约束都发生了根本性变化。理解这些差异，是后续所有架构设计决策的前提。本节从系统分层、HAL 与 CarService、车辆属性、驾驶状态、多屏多用户以及应用运行约束六个方面，建立座舱环境的整体认知。

一、AAOS 系统架构：在 AOSP 之上叠加车辆层

AAOS 并不是一个全新的操作系统，而是以 AOSP 为底座，在系统层叠加了一整套车辆相关的能力。从下往上可以这样理解：最底层是 Linux 内核与硬件抽象层（HAL），负责与 SoC、CAN 总线、MCU、显示屏、音频 DSP 等硬件交互；其上是原生 Android 系统服务（ActivityManager、WindowManager、PackageManager 等）；再往上是车辆专属的系统服务层，核心是 CarService 及其配套的 Car API；最上层才是面向用户的应用，包括系统应用（如车控、空调、媒体）和第三方应用。

关键区别在于：手机应用通过标准 Android Framework API 就能完成绝大多数事情，而车载应用往往需要经过 Car API 才能访问车辆信号、驾驶状态、多屏区域等座舱专属能力。Car API 是应用与车辆世界之间的唯一正规通道，绕过它直接读 CAN 或写硬件，在量产项目中既不可维护也不被允许。

二、HAL 与 CarService：车辆能力的两个关键枢纽

HAL 是 Android 与硬件之间的契约层。在车载场景中，最重要的当属 Vehicle HAL（VHAL）。VHAL 定义了一组标准化的车辆属性接口，把来自 CAN、LIN、以太网或 MCU 的原始信号，翻译成 Android 系统能理解的属性读写操作。例如车窗位置、空调温度、车速、挡位、车门锁状态，都会以属性 ID 的形式暴露出来。VHAL 的实现通常由 Tier1 或车厂提供，应用开发者一般不直接接触它。

CarService 则是运行在系统进程中的车辆服务集合，它通过 Binder 与 VHAL 通信，并把车辆能力封装成 Car API 提供给应用。CarService 内部包含多个子服务：CarPropertyService 负责属性读写与订阅，CarDrivingStateService 负责驾驶状态判定，CarUxRestrictionsService 负责驾驶分心限制，CarOccupantZoneService 负责乘员与屏幕区域映射。应用通过 Car.createCar() 获取 Car 对象，再从中取出对应的 Manager 使用。

// 获取 Car 对象与属性管理器（示例）
Car car = Car.createCar(context);
CarPropertyManager propMgr =
        (CarPropertyManager) car.getCarManager(Car.PROPERTY_SERVICE);

// 订阅车速属性，车速变化时回调
propMgr.registerCallback(callback,
        VehiclePropertyIds.PERF_VEHICLE_SPEED,
        CarPropertyManager.SENSOR_RATE_ONCHANGE);

三、车辆属性：座舱数据的统一表达

车辆属性是 AAOS 中表达车辆状态的核心抽象。每个属性由属性 ID、区域（Area）、数据类型和访问权限共同定义。区域是车载特有的概念，用于区分同一属性的不同物理位置，例如四个车门、多个温区、左右座椅。属性按访问方式分为读、写、读写三类，按变化特性分为静态属性（如 VIN 码）和动态属性（如车速）。

属性订阅有两种速率策略：SENSOR_RATE_ONCHANGE 表示仅在值变化时回调，适合车门、挡位这类事件型信号；SENSOR_RATE_FAST 或指定 Hz 表示按固定频率上报，适合车速、转速这类连续信号。选择不当会带来明显代价：对高频信号用 ONCHANGE 可能丢失中间状态，对低频事件用 FAST 则会造成无谓的 Binder 与 CPU 开销。

四、驾驶状态与 UX 限制：安全优先的硬约束

驾驶状态由 CarDrivingStateService 根据挡位、车速等信号综合判定，通常分为停车（Parked）、怠速（Idling）、行驶（Moving）等状态。驾驶状态直接决定 UX 限制等级：当车辆处于行驶状态时，CarUxRestrictionsManager 会下发限制，要求应用限制交互复杂度，例如禁止长文本输入、限制列表滚动项数、禁止视频播放、简化界面层级。

五、多屏与多用户：座舱的空间与身份维度

座舱通常包含中控屏、仪表屏、副驾屏、HUD 等多个显示区域，AAOS 通过 CarOccupantZone 把乘员、显示区域、音频区域关联起来。应用需要明确自己运行在哪个屏幕上，并据此调整布局与交互。仪表屏通常由系统应用独占，第三方应用一般只能运行在中控或副驾屏。

多用户方面，AAOS 支持为不同驾驶员建立独立用户空间，每个用户拥有独立的应用数据、账号与偏好设置。用户切换时，应用进程可能被重启或收到用户切换回调。应用必须正确处理数据隔离，不能把上一个用户的数据带到下一个用户，尤其是账号、导航历史和个性化配置。

六、应用运行环境约束

综合来看，车载应用面临以下约束：第一，车辆信号访问必须通过 Car API，且部分属性需要系统权限或签名；第二，驾驶状态会动态改变可用交互能力；第三，多屏意味着布局不能假设单一屏幕尺寸与方向；第四，多用户要求数据严格隔离；第五，座舱硬件资源（内存、CPU、存储）通常比旗舰手机紧张，且要求快速冷启动与长期稳定运行；第六，车辆下电、休眠、唤醒等电源状态变化会触发应用生命周期事件。

把上述内容串起来看，AAOS 的本质是在通用 Android 之上，通过 HAL、CarService 和 Car API 三层协作，把车辆信号、驾驶状态、多屏多用户等座舱专属能力，以受控、安全、可审计的方式暴露给应用。应用架构设计的每一步，都要在这个受约束的环境中寻找平衡点。