2. Android接口演进史
要理解HIDL到AIDL的迁移，不能只把它看成一次“换语言”或“换工具”的动作，而应放回Android系统架构演进的长周期中观察。HIDL的诞生、Treble计划的推进、Project Mainline的落地，以及AIDL最终成为稳定接口的统一载体，本质上都在回答同一个问题：当Android的框架、厂商实现、内核与模块更新节奏彼此不同步时，接口如何保持长期稳定，同时又不阻碍系统升级？
一、核心动因：Android升级为何长期受制于接口耦合
在Android 8.0之前，Framework与HAL（硬件抽象层）通常以动态库方式直接链接，二者运行在同一进程空间内。这种模式在早期有利于性能与开发效率，但随着Android版本迭代加快，问题逐渐暴露：
- 版本绑定严重：HAL实现依赖特定Framework版本，升级系统往往需要厂商同步重编译HAL。
- 升级成本高：一次Android大版本升级可能牵动大量芯片与外设厂商，导致设备长期停留在旧版本。
- 接口边界模糊：库函数调用没有明确的跨进程契约，兼容性难以验证。
- 安全与隔离不足：HAL与Framework同进程，单点故障或漏洞影响面更大。
因此，Android需要一种跨进程、可版本化、可独立更新的接口机制。HIDL正是在这一背景下被引入，它把HAL从Framework进程中拆出，通过Binder化通信建立稳定契约。
二、Treble计划：用HIDL把“升级”变成可工程化的问题
Treble计划的核心目标，是让Framework与Vendor实现解耦，使系统升级不再强依赖厂商HAL重编译。其关键手段包括：
- 引入HIDL接口：以
.hal文件定义接口，生成C++/Java客户端与服务端代码。 - 进程隔离：HAL运行在独立进程，通过Binder与Framework通信。
- VINTF与兼容性矩阵：用Vendor Interface描述接口版本，用兼容性矩阵约束Framework与Vendor的匹配关系。
- Vendor分区独立：Vendor实现与System分区解耦，支持分别升级。
Treble让“接口稳定性”第一次成为可检查、可测试、可发布的工程对象。但HIDL本身也带来了新的复杂度：接口定义、版本管理、Passthrough与Binder模式并存，且HIDL主要面向HAL，无法覆盖所有系统接口场景。
关键转折：Treble解决了“Framework与Vendor解耦”，但Android生态还需要一种更通用、更统一、能覆盖HAL、系统服务、应用间通信的接口语言。AIDL因此被重新推到台前。
三、Project Mainline与接口稳定性的关系
Project Mainline（模块化系统组件）从Android 10开始推进，目标是把部分系统组件做成可独立更新的Mainline模块，通过Google Play系统更新下发。它进一步强化了接口稳定性的要求：
- 模块边界必须稳定：模块与系统其余部分之间需要明确、版本化的接口。
- 更新不能破坏兼容性：模块升级后，旧接口仍需按约定工作。
- 接口需要统一治理：HIDL、AIDL、JNI、Binder等多套机制并存会增加维护成本。
于是，AIDL被选为稳定接口的统一方向。AIDL本身成熟、工具链完善、支持多种后端（Java、C++、NDK），并且天然适合Binder通信。Android 11之后，AIDL逐步扩展为HAL接口的推荐方案；Android 13起，新HAL接口基本以AIDL为主，HIDL进入维护状态。
四、案例场景：一个HAL接口的迁移判断
假设某设备有一个android.hardware.light@2.0的HIDL接口，现在要迁移到AIDL。迁移前需要先判断它属于哪类接口、是否涉及Mainline模块、是否已有AIDL替代版本。典型判断路径如下：
1. 确认接口类型：HAL / 系统服务 / 应用间
2. 检查是否属于 Mainline 模块边界
3. 查看 Android 版本与 VINTF 兼容性要求
4. 若目标版本 ≥ Android 13，优先使用 AIDL HAL
5. 保留 HIDL 兼容层，逐步切换调用方
6. 更新 VINTF 矩阵与兼容性声明
7. 回归测试：Binder 调用、权限、SELinux、版本协商这个路径说明，迁移不是简单地把.hal改成.aidl，而是涉及接口定义、版本策略、兼容矩阵、权限模型和测试验证的系统工程。
五、常见误区与复盘
误区一：认为AIDL只是HIDL的“语法替换”。实际上，AIDL在HAL场景下需要重新设计接口粒度、线程模型和稳定性标记。
误区二：忽略VINTF兼容性矩阵。迁移后若未同步更新矩阵，可能导致设备启动时接口匹配失败。
误区三：一次性全量切换。更稳妥的做法是保留HIDL兼容层，按模块逐步迁移，降低升级风险。
| 阶段 | 代表机制 | 接口稳定性手段 | 主要局限 |
|---|---|---|---|
| Android 7及以前 | 同进程动态库 | 无明确跨进程契约 | 升级强耦合，厂商适配成本高 |
| Android 8 Treble | HIDL + VINTF | 进程隔离、版本化接口、兼容矩阵 | HIDL复杂度高，覆盖面有限 |
| Android 10 Mainline | 模块化系统组件 | 模块边界稳定、独立更新 | 对接口统一性提出更高要求 |
| Android 11+ | AIDL 统一接口 | 多后端、版本化、稳定契约 | 迁移期需兼容HIDL与AIDL并存 |
从HIDL到AIDL的演进，表面上是接口描述语言的变化，实质上是Android对“接口稳定性”治理能力的升级。Treble解决了Framework与Vendor的解耦，Project Mainline把可更新模块推向更细粒度，而AIDL则承担起统一稳定接口的角色。理解这条演进链，才能在迁移工程中做出正确的接口设计、版本策略与兼容性判断。