JasonWang's Blog

HAL binder工作流程-以RILJ/RILD通信为例

Telephony(RIL Java,以下简称RILJ)与RILD(RIL Daemon)的通信在Android OO8.0以前都是基于socket通信,而Android 8.0则是基于HAL binder进行IPC的数据交换。有关RILJ与RILD的工作原理可以参考之前的两篇文章:Android RIL概述以及RILD详解。这篇文章主要分析RILJ与RILD是如何通过HAL Binder进行通信。

RILJ与RILD的通信,服务端是RILD,客户端是RILJ。对于RILD而言,其对应的HAL接口是/android/hardware/interfaces/radio/1.0/IRadio.hal:

深入Android HAL binder

HAL binder是Android O(8.0)专门用于HAL(Hardware Abstract Layer)层(native)进程与其clients之间的通信机制(clients可以是native进程,也可以是Java Framework进程)。 HAL binder替代了早先使用的socket通信,其kernel层实际是基于原有的binder驱动,但为了配合Client与Server之间的数据传输,需要使用特定的中间层HIDL来进行接口与数据的转换。那么,相对之前的HAL通信方式(socket),基于HIDL的HAL通信有什么优势了?从系统架构的角度,HIDL为客户端与服务端提供了清晰的接口;从效率的角度,binder IPC实际在传输数据上只有一次拷贝,而socket实际传输需要两次数据拷贝。

目前Android有两种类型的HAL:

  • binder化的HAL: 利用HIDL(HAL interface Definition Language)来描述HAL接口,Framework层与HAL层通过binder IPC的方式进行通信;如下的HAL模块都是利用binder IPC来进行通信的:

    • android.hardware.biometrics.fingerprint@2.1
    • android.hardware.configstore@1.0
    • android.hardware.dumpstate@1.0
    • android.hardware.graphics.allocator@2.0
    • android.hardware.radio@1.0
    • android.hardware.usb@1.0
    • android.hardware.wifi@1.0
    • android.hardware.wifi.supplicant@1.0
  • 直通式HAL: 基于HIDL或者传统HAL方式来实现,在这种模式下,Framework层与HAL层的通信可以通过IPC的方式进行,也可以使用共享内存的方式在同一个进程内进行(passthrough,直通)。目前有如下两个HAL模块使用直通式方式进行通信:

    • android.hardware.graphics.mapper@1.0
    • android.hardware.renderscript@1.0