在 Android 8.0 时，Treble Project 重新设计了 Android 操作系统框架，以便让制造商能够以更低的成本，更轻松、更快速地将设备更新到新版 Android。在这种新架构中，采用 HIDL（HAL 接口定义语言，发音为 “hide-l”）来指定 framework 和 HAL 层之间的接口，从而可以实现无需重新编译 HAL，只烧写 GSI 便能升级系统。

HAL 类型和概念

这一块感觉官方文档的描述不够清楚，稀里糊涂的，单读文档概念都不明白。尝试先搞清楚 Treble 中绑定式和直通式 HAL 的概念。官方的中文翻译是：

  • 绑定式 HAL。 以 HAL 接口定义语言 (HIDL) 表示的 HAL。这些 HAL 取代了早期 Android 版本中使用的传统 HAL 和旧版 HAL。在绑定式 HAL 中，Android 框架和 HAL 之间通过 Binder 进程间通信 (IPC) 调用进行通信。所有在推出时即搭载了 Android 8.0 或更高版本的设备都必须只支持绑定式 HAL
  • 直通式 HAL。 以 HIDL 封装的传统 HAL 或旧版 HAL。这些 HAL 封装了现有的 HAL，可在绑定模式和 Same-Process（直通）模式下使用。升级到 Android 8.0 的设备可以使用直通式 HAL

这里的绑定式 HAL(Binderized HALs)、直通式 HAL (Passthrough HALs)，应该指的是 HAL 层的共享库 .so 文件。其中直通式 HAL，是把 Treble Project 之前的传统 HAL 或旧版 HAL 库文件使用 HIDL 进行了封装，而封装后的库文件可用于 Treble Project 中的绑定模式和 Same-Process（直通）模式。

在看一下官方的 roadmap:

HAL Roadmap

这 ①②③④ 四种模式，是到目前为止四种实现架构。

  1. ① 是 Treble Project 之前使用的实现架构，使用的是传统 HAL 和旧版 HAL
  2. ② 直通模式，passthrough mode。如图所示，Framework 和 HAL 层工作在同一个进程当中，下面的 HAL 是使用 HIDL 封装后的库，是直通式 HAL。这些库文件也可用于 ③ 绑定模式
  3. ③ 绑定模式，binderized mode。是直通式 HAL binder 化，变为绑定式 HAL。Framework 和 HAL 层工作在不同的进程，之间通过 Binder 进行 IPC
  4. ④ 纯绑定式。相对于 ③ 来说，绑定式 HAL 中并不包含直通式 HAL，因此称为纯绑定式

因此根据谷歌要求，出厂时就搭载 8.0 的设备，除了谷歌规定的 android.hardware.graphics.mapper@1.0 和 android.hardware.renderscript@1.0 需使用 ②直通模式，其它 HAL 只能采用 ③ 和 ④ 模式的实现架构。

而升级到 8.0 的设备，除谷歌规定外，其它 HAL 则可使用 ②③④ 三种实现架构。既是供应商映像提供的所有其他 HAL 既可以在直通模式下使用，也可以在绑定模式下使用，也可完全使用纯绑定式。

补充：
旧版 HAL 是直接被编译进系统，如 WLAN 就在libhardware_legacy 中；传统 HAL 是通过 libhardware 库中 get_hw_module() 的方式来获取。未使用 HIDL 表示的 HAL 有 openGL 和 Vulkan。

实现模式的架构差异

②③④ 三种实现架构从实现上来看，当然也是不同的

直通模式

和 Framework 工作在同一个进程当中，因没有 service 进程，服务也没有被事先注册到 hwservicemanager，Framework 通过 Binder 得到的是同一个进程中的实例。在 manifest.xml 中 transport 类型为 passthrough。以 android.hardware.graphics.composer@2.1 为例，在 Android.bp 中，Hwc.cpp 被编译为 android.hardware.graphics.composer@2.1-impl.so，其 HIDL_FETCH_IComposer 方法中会使用 hw_get_module() 方法去加载传统 HAL。

绑定模式

而将直通模式中的直通式 HAL，添加上 service 进程，修改 transport 类型为 hwbinder，就成为了绑定模式。service 的注册使用的是 defaultPassthroughServiceImplementation() 方法。

纯绑定式

service 的注册方法都是 registerAsService()，在 manifest.xml 中的 transport 类型为 hwbinder，不再单独编译 *-impl.so，而是全编译进 service 中。以 android.hardware.power@1.1 默认实现为例。android.hardware.power@1.1-service 服务启动时，服务的注册方法是 registerAsService()。在 Android.bp 中将两个源文件编译为 android.hardware.power@1.1-service。有意思的是在 service 的 main 方法中居然会去 hw_get_module(POWER_HARDWARE_MODULE_ID, &hw_module) 加载传统 HAL，那这个默认实现 1.1 版相对于 1.0 版就没有意义了。也因并没有厂商使用这个默认版，谷歌干脆移除了。

小结

在直通模式和绑定模式中，*-impl.so 库文件通过 HIDL_FETCH_I*** 方法来加载传统 HAL，因此厂商也可把所有的实现放入 impl 中，如 health 和 bluetooth 的默认实现，在 HIDL_FETCH_IHealth 返回的是自己的实例。纯绑定式中，厂商的实现就都在 service 当中了。

服务的注册和获取

服务注册或获取服务端实例过程中，都会传递一个布尔值 getStub：

  1. getStub 为 true 时，不会去读 manifest.xml 中指定 transport 类型
  2. getStub 为 false 时，则会读取 manifest.xml 中 transport 类型

服务的注册

上面也提到了，服务的注册方法有两个，defaultPassthroughServiceImplementation() 由绑定模式使用；registerAsService() 由纯绑定模式使用。因直通模式并没有 service deamon，因此系统启动时，并不会进行注册。

绑定模式

绑定模式调用 defaultPassthroughServiceImplementation() 方法，在其调用链中会调用 getService() 方法，并传递 getStub 为 true。getService 会首先获取 hwservicemanager 代理对象，请求 hwservicemanager 进程查询所要注册的 HIDL 服务的 transport 类型(通过读取 /vendor/manifest.xml 文件)。因为传递的 getStub 为 ture，所以这里获取到的 transport 类型在注册时并不起什么作用，将始终通过 getPassthroughServiceManager() 方法获取一个 PassthroughServiceManager 对象，调用其 get(const hidl_string& fqName, const hidl_string& name) 方法来获取所要注册的 HIDL 服务对象(如图所示)，最后调用 registerReference 和 registerAsService 完成服务的注册。

Get HIDL Service

纯绑定模式

纯绑定式，使用不到绑定模式前面的那些，直接 registerAsService，注册到 hwservicemanager。

参考

详见：AndroidO Treble架构下Hal进程启动及HIDL服务注册过程，就不贴代码了。

服务的查询获取

获取服务时的 getService 方法过程中，传递的 getStub 为 false，因此根据指定的 transport 类型来选择接口对象获取方式：

  • 为 passthrough 时，使用 getPassthroughServiceManager() 方法从本进程地址空间中获取
  • 为 hwbinder 时，先使用 defaultServiceManager() 方法获取 hwservicemanager 的代理对象，然后从 hwservicemanager 中查询获取

passthrough

直通模式下客户端去获取服务，和绑定模式注册时服务时对 HIDL 服务的获取过程是一致的。

getPassthroughServiceManager()，返回一个 PassthroughServiceManager 对象，这个 PassthroughServiceManager 类是 system/libhidl/transport/ServiceManagement.cpp 的一个内部类。

直通模式因事先没有被注册到 hwservicemanager 中去，在客户端申请服务时，才会一并注册到 hwservicemanager，若并没有客户端申请该服务，那么 hwservicemanager 中就不会存在该服务，直通模式最后获取到的是同一进程中的实例，不是一个代理对象。

hwbinder

在绑定模式和纯绑定模式下，getService() 时，调用的是 libhidl 库中的 defaultServiceManager()，通过 binder 返回的是 HwServiceManager 实例，最终远程调用 hwservicemanager daemon 中的方法，获取到代理对象

参考

详见：AndroidO Treble 架构下 HIDL 服务查询过程

参考