3. AOSP HAL框架回顾：Android HAL接口定义语言（HIDL/AIDL）、HAL Service与HAL Server模型、Treble架构对HAL的影响
在深入Vehicle HAL适配之前，必须系统回顾AOSP HAL框架的演进脉络。Android 8.0引入的Treble架构彻底重构了HAL层，将原本紧密耦合的vendor实现与Android框架解耦。本节聚焦三个核心维度：接口定义语言（HIDL vs AIDL）、运行时模型（Service vs Server）、以及Treble带来的架构变革。
3.1 接口定义语言：从HIDL到AIDL的演进
Android HAL接口定义语言决定了framework与vendor实现之间的契约形式。HIDL（HAL Interface Definition Language）是Treble时代的主语言，而AIDL（Android Interface Definition Language）在Android 13之后逐步成为统一选择。
| 对比维度 | HIDL | AIDL（HAL模式） |
|---|---|---|
| 引入版本 | Android 8.0 (Treble) | Android 13 (HAL AIDL) |
| 后端类型 | Passthrough / Binderized | 仅Binderized |
| 接口文件后缀 | .hal |
.aidl |
| 包命名规范 | android.hardware.xxx@X.Y |
android.hardware.xxx.IXxx |
| 版本管理 | 显式major.minor版本 | 通过接口继承实现 |
| 稳定性保证 | VTS强制接口冻结 | API review + 冻结机制 |
| 代码生成 | hidl-gen |
aidl + aidl_interface 构建规则 |
关键决策： 新项目应优先选择AIDL HAL模式。Google已明确HIDL进入维护模式，AIDL提供更简洁的语法、更好的工具链集成，且支持跨进程回调（oneway）和接口继承。
3.1.1 HIDL接口示例（Vehicle 2.0）
// android.hardware.automotive.vehicle@2.0
package android.hardware.automotive.vehicle@2.0;
interface IVehicle {
getAllPropConfigs() generates (vec<VehiclePropConfig> propConfigs);
get(VehiclePropValue requestedPropValue)
generates (StatusCode status, VehiclePropValue propValue);
set(VehiclePropValue propValue) generates (StatusCode status);
subscribe(IVehicleCallback callback, vec<SubscribeOptions> options)
generates (StatusCode status);
...
};3.1.2 AIDL HAL接口示例（Vehicle AIDL）
// android.hardware.automotive.vehicle.IVehicle.aidl
package android.hardware.automotive.vehicle;
interface IVehicle {
void getAllPropConfigs(out VehiclePropConfig[] propConfigs);
void get(in VehiclePropValue requestedPropValue,
out VehiclePropValue propValue);
void set(in VehiclePropValue propValue);
void subscribe(in IVehicleCallback callback,
in SubscribeOptions[] options);
...
};
迁移要点： AIDL HAL不再使用
generates关键字，改用out参数传递返回值；错误码通过ServiceSpecificException抛出，而非返回StatusCode枚举。
3.2 HAL Service与HAL Server模型
Treble架构下，HAL实现以两种运行时形态存在：HAL Service（服务端进程）和HAL Server（注册与管理实体）。理解二者的分工是编写稳定HAL的基础。
3.2.1 注册与发现流程
- HAL Service启动：vendor进程调用
registerAsService()向servicemanager注册自身实例。 - Framework获取服务：通过
IVehicle::getService()（HIDL）或IVehicle::getService()（AIDL）获取Binder代理。 - 直连通信：后续所有接口调用直接通过Binder IPC在Framework进程与HAL Service进程之间完成。
- 死亡通知：Framework注册
linkToDeath监听，HAL Service异常退出时触发重连逻辑。
常见陷阱： 多个HAL Service实例可能注册同一个接口名（如
default），servicemanager默认返回第一个注册的实例。Vehicle HAL通常只注册一个实例，但调试时需注意进程重启导致的注册竞争。
3.3 Treble架构对HAL的影响
Treble（Android 8.0+）是Android HAL历史上最重大的架构变革。它将vendor实现与framework编译时解耦，通过稳定接口保证系统升级时vendor镜像无需重新编译。
3.3.1 核心变革
| 变革维度 | Treble之前 | Treble之后 |
|---|---|---|
| 接口稳定性 | 无强制接口冻结，vendor与framework紧耦合 | VTS强制接口兼容性测试，冻结的.hal/.aidl文件 |
| 编译依赖 | vendor库链接framework内部头文件 | vendor仅依赖稳定NDK + HAL接口定义 |
| 进程模型 | 同进程加载（libhardware.so） | 强制Binderized（跨进程），仅legacy保留passthrough |
| 版本管理 | 无版本概念，直接修改头文件 | 显式major.minor版本，接口升级通过继承扩展 |
| 测试验证 | 依赖厂商自测 | VTS（Vendor Test Suite）自动化接口兼容性测试 |
3.3.2 Treble对Vehicle HAL的具体影响
- 接口冻结：Vehicle HAL 2.0（HIDL）和Vehicle HAL AIDL接口必须通过VTS兼容性测试，任何接口变更需Google审核。
- 独立进程：Vehicle HAL Service运行在独立的vendor进程中（如
/vendor/bin/hw/android.hardware.automotive.vehicle-service），与SystemServer隔离。 - SELinux策略：Treble强化了vendor与system分区的SELinux隔离，Vehicle HAL Service需要明确的
file_contexts和te规则才能访问硬件设备。 - OTA兼容性：framework OTA升级时，vendor镜像（包括Vehicle HAL Service）无需更新，只要接口版本匹配即可继续工作。
3.3.3 适配Vehicle HAL时的Treble注意事项
实战清单：
- 确认目标Android版本对应的HAL接口版本（Android 13+推荐AIDL，Android 8-12使用HIDL）。
- VTS测试必须通过：
VtsHalAutomotiveVehicleTargetTest覆盖所有必选属性。 - SELinux策略文件需包含：
hal_automotive_vehicle.te、file_contexts中声明service二进制路径。 - 使用
android.hardware.automotive.vehicle-service作为标准service名称，便于servicemanager发现。 - 实现
dump()方法支持dumpsys调试，这是VTS和开发者调试的关键入口。