在Android中，AIDL（Android Interface Definition Language） 和 HIDL（HAL Interface Definition Language） 是两种用于定义跨进程通信接口的语言。AIDL 是 Android 系统最早支持的 IPC（进程间通信）机制，而 HIDL 是从 Android 8.0 开始引入，用于 HAL（Hardware Abstraction Layer）模块的接口定义。
随着 Android 的发展，Google 决定从 Android 11 开始将新的 HAL 统
一使用 AIDL 接口，而逐步放弃 HIDL。这种转变背后的原因涉及技术复杂度、性能、开发效率和生态统一性等多个方面。
1. AIDL 和 HIDL 的主要区别
1.1AIDL（Android Interface Definition Language）
用于 Android 系统中 App 层到 Framework 层之间的通信，也可以用于 Service 和 Client 的进程间通信。AIDL 使用 Binder 内核驱动程序进行调用。
AIDL 可以在 Android 中的任何进程之间使用：在平台组件之间使用或在应用之间使用均可。
他的主要的特点是：
- 语言支持：支持 Java、C++ 和 Kotlin，最初主要服务于 App 层（Java 环境）。
- 运行时绑定：通过 binder 驱动直接实现进程间通信，适合轻量的高频接口调用。
- AIDL 文件编译：通过工具生成 Stub 和 Proxy 代码，封装了序列化和反序列化逻辑，开发者只需实现核心逻辑。
1.2 HIDL（Hardware Interface Definition Language）
HIDL 旨在用于进程间通信 (IPC)。使用 HDL 创建的 HAL 称为绑定式 HAL，因为它们可以使用 Binder 进程间通信 (IPC) 调用与其他架构层进行通信。绑定式 HAL 在独立于使用它们的客户端的进程中运行。对于必须与进程相关联的代码库，还可以使用透传模式（在 Java 中不受支持）。
HIDL 可指定数据结构和方法签名，这些内容会整理归类到接口（与类相似）中，而接口会汇集到软件包中。尽管 HIDL 具有一系列不同的关键字，但 C++ 和 Java程序员对 HIDL 的语法并不陌生。此外，HIDL 还使用 Java 样式的注解。
他的主要的特点是：
- 使用场景：专为 HAL 设计，用于定义硬件抽象层和 Framework 层之间的接口。
- 语言支持：主要支持 C++，不直接支持 Java。
- 静态绑定：HIDL 在编译时生成接口代码，运行时通过 hwservicemanager 注册和发现服务。
- 接口版本化：支持接口的向前兼容和向后兼容，可以在同一个系统中并存多个版本的 HAL 模块。
- 复杂性：HIDL 引入了较复杂的构建工具链（如 HIDL 编译器）和运行时管理机制。
2. Google 放弃 HIDL，统一使用 AIDL 的原因
2.1 简化开发和维护
-
减少学习成本：
HIDL 的学习曲线较陡，开发者需要熟悉 HIDL 特有的语法和工具链，而 AIDL 更加简单直观，开发者容易上手。 -
统一接口开发方式
将 HAL 和应用层接口统一为 AIDL，减少了系统中不同接口定义语言的种类，便于开发者在不同层级使用相同的工具和模式。
2.2 降低系统复杂性
HIDL 的工具链和运行时机制引入了额外的复杂性，比如 hwservicemanager 和接口的版本化管理，而 AIDL 的实现相对简单，使用单一的 binder 机制即可满足需求。
2.3 性能优化
AIDL 在轻量通信场景下性能优于 HIDL：
- 序列化和反序列化效率高：AIDL 的传输格式更加精简。
- 运行时绑定更灵活：无需像 HIDL 那样依赖 hwservicemanager，可以减少通信开销。
对于大多数硬件接口调用场景，AIDL 的性能足以满足需求，HIDL 的版本管理和静态绑定机制显得多余。
2.4 推动 Kotlin 和 Rust 的生态
AIDL 逐步扩展了对 Kotlin 和 Rust 的支持（尤其是在安全性上），这是 Google 推动现代语言生态的重要一步。相比之下，HIDL 偏向 C++，缺乏对新语言的良好支持。
2.5 接口版本化的简化
尽管 HIDL 的多版本支持机制强大，但实际使用中却增加了维护成本。AIDL 的接口版本化从 Android 10 开始进行了改进，通过 stable AIDL 提供了更简洁的方式来处理接口的向前和向后兼容性问题。
3.举例说明
就拿音频举例，AIDL 实现与 HIDL 音频 HAL 实现之间的区别：
- 在 AIDL 音频核心 HAL 中，引入了新的 IConfig 接口，替代了 HIDL HAL 中通过 XML 文件定义的系统级参数。这些参数现在由框架直接从 Core HAL 读取，而不再依赖供应商提供的配置文件。例如，用于显示给用户以便控制的环绕声格式列表，现由 IConfig.getSurroundSoundConfig 方法直接提供。
- 在 AIDL 音效 HAL 中，原先在 HIDL 音效 HAL 的 XML 文件中定义的 effectProxy 相关逻辑已迁移到音频框架中。框架通过调用 IFactory.queryEffects 方法获取系统中所有效果实例的列表，并使用 IFactory.queryProcessing 方法查询所有效果处理信息。
- 为了避免“设备”一词在描述音频设备类型时可能产生的歧义，HIDL 音频 HAL 中的 IDevice 接口在 AIDL 音频 HAL 中被重新命名为 IModule。
- 此外，IPrimaryDevice 接口已被移除并由新的机制替代。现在，系统会将当前音频模式和屏幕旋转方向的更新发送到每个 IModule 实例。而涉及蓝牙同步音频连接（如 BT SCO）和免提配置文件（HFP）的参数，则由独立的 IBluetooth 接口管理。与电话相关的控制由专用的 ITelephony 接口提供支持。这两个接口的实例都可以通过 IModule 接口的主实例来获取。更多细节可参见核心 HAL 与相关功能的对比表。
- 与此同时，为了避免冗余，AIDL 音频 HAL 中移除了 IDevicesFactory 接口。HAL 模块（即 IModule 的实例）现在直接以其名称在 Service Manager 中注册，例如 bluetooth 或 r_submix。唯一的例外是主模块（primary module），它仍然以 default 作为实例名称进行注册。
4.接口映射内容：
所有 HIDL 接口都在 android.hardware.audio@N.M 软件包中，其中 N.M 表示 Major.Minor 版本。所有 AIDL 接口都在 android.hardware.audio.core 软件包中。
| HIDL API 接口和配置文件 | AIDL API接口 |
|---|---|
| IDevicesFactory | 在 ServiceManager注册 IModule。 |
| IDevice | IModule |
| IPrimaryDevice | ITelephony / IBluetooth |
| IStream /IStreamIn / IStreamOut | StreamDescriptor /IStreamIn / IStreamCommon / IStreamOut |
| audio_policy_configuration.xml / audio_policy_engine_configuration.xml | IConfig / IModule |
| 可配置的音频政策文件 | 在 Android 14 中使用HbL妥现。 |
