HIDL 即HAL interface definition language，在 Android Project Treble 中被起草，在 Android O 中被全面使用, HIDL用于进程间通信(IPC)。
在此之前Android 有AIDL，架构在Android binder 之上，用来定义Android 基于Binder通信的Client 与Service之间的接口。HIDL也是类似的作用，只不过定义的是Android Framework与Android HAL实现之间的接口。
在AIDL机制中Android 会提供一系列工具会将用户定义的*.aidl文件编译生成Client端代码与Service端代码，用户仅仅 需要1）在Service端实现所需要实现的接口。2）在Client端调用相关接口。基于Binder机制，在Clinet端的调用会自动通过binder驱动跨进程到service进程当中。
而在HIDL里，与AIDL比较类似，底层也是基于binder机制。但是也有稍微不一样的地方。为了支持HIDL，Android 对BInder做了一定程度的修改。
关于HIDL的设计
HIDL的设计目的是为了能够在不重新编译HALs的情况下能够替换framework。HALs将由供应商或SOC制造商构建，并放在设备的vendor下的分区中，而framework框架在它自己的分区中发挥作用，能够被OTA替换而不重新编译HALs。
HIDL的设计平衡了以下问题:
共用性
在进程间创建可靠的共用接口，而这些进程可能有不同的架构、工具链和构建配置。HIDL接口是版本化的，在发布后不能更改。
效率
HIDL会将复制的次数最小化。HIDL定义的数据以C++标准layout data structures的形式传递给c++代码，这种数据结构可以不打包的情况下使用。HIDL还提供共享内存接口，由于RPCs天生有点慢，HIDL无需使用RPC调用，而支持两种传输数据的方法:shared memory （共享内存）和 Fast Message Queue (FMQ).
直观
对于RPC，HIDL只使用参数(参见AIDL)，避免了内存所有权的棘手问题;不能有效通过方法返回的值通过回调函数返回。既不将数据传递到HIDL，也不从HIDL接收数据，改变数据的所有权。数据只需要在被调用函数的持续时间内存在，并且可以在被调用函数返回后立即销毁。
稍微总结下HIDL相关的内容：
1）HIDL是Android O里的Treble计划的核心。目的是通过HIDL语法构建出一个松耦合的系统，最终目的是为了方便Android 升级，解决碎片化的问题。
2）Android为了实现 Binderized HAL有一个比较清晰的road map：