使用 Binder IPC

本页介绍了 Android O 中对 Binder 驱动程序进行的更改、提供了有关使用 Binder IPC 的详细信息,并列出了必需的 SELinux 政策。

对 Binder 驱动程序进行的更改

从 Android O 开始,Android 框架和 HAL 现在使用 Binder 互相通信。由于这种通信方式极大地增加了 Binder 流量,因此 Android O 包含了几项改进,旨在确保 Binder IPC 的速度。集成最新版 Binder 驱动程序的 SoC 供应商和原始设备制造商 (OEM) 应该查看这些改进的列表、用于 3.18、4.4 和 4.9 版内核的相关 SHA,以及所需的用户空间更改。

多个 Binder 域(上下文)

在通用 3.10、3.18、4.4、4.9 版内核和上游中

为了明确地拆分框架(与设备无关)和供应商(与具体设备相关)代码之间的 Binder 流量,Android O 引入了“Binder 上下文”这一概念。每个 Binder 上下文都有自己的设备节点和上下文(服务)管理器。您只能通过上下文管理器所属的设备节点对其进行访问,并且在通过特定上下文传递 Binder 节点时,只能由另一个进程从相同的上下文访问上下文管理器,从而确保这些域完全互相隔离。如需使用方法的详细信息,请参阅 vndbindervndservicemanager

分散-集中

在通用 3.10、3.18、4.4、4.9 版内核和上游中

在之前的 Android 版本中,Binder 调用中的每条数据都会被复制 3 次:

  • 一次是在调用进程中将数据序列化为 Parcel
  • 一次是在内核驱动程序中将 Parcel 复制到目标进程
  • 一次是在目标进程中对 Parcel 进行反序列化

Android O 使用分散-集中优化机制将复制次数从 3 次减少到了 1 次。数据保留在其原始结构和内存布局中且 Binder 驱动程序会立即将数据复制到目标进程中,而不是先在 Parcel 中对数据进行序列化。在目标进程中,这些数据的结构和内存布局保持不变,并且,在无需再次复制的情况下即可读取这些数据。

精细锁定

在通用 3.18、4.4、4.9 版内核和上游中

在之前的 Android 版本中,Binder 驱动程序使用全局锁来防范对重要数据结构的并发访问。虽然采用全局锁时出现争用的可能性极低,但主要的问题是,如果低优先级线程获得该锁,然后实现了抢占,则会导致同样需要获得该锁的优先级较高的线程出现严重的延迟。这会导致平台卡顿。

原先尝试解决此问题的方法是在保留全局锁的同时禁止抢占。但是,这更像是一种临时应对手段而非真正的解决方案,最终被上游拒绝并舍弃。后来尝试的解决方法侧重于提升锁定的精细程度,自 2017 年 1 月以来,Pixel 设备上一直采用的是更加精细的锁定。虽然这些更改大部分已公开,但未来版本中还会有一些重大的改进。

在确定了精细锁定实现中的一些小问题后,我们使用不同的锁定架构设计了一种改进的解决方案,并在 3.18、4.4, 和 4.9 版通用分支中提交了相关更改。我们会继续在大量不同的设备上测试这种实现方式;由于目前看来这个方案不存在什么问题,因此建议搭载 Android O 的设备都使用这种实现方式。

注意:我们强烈建议针对精细锁定安排充足的测试时间。

实时优先级继承

在通用 3.18、4.4、4.9 版内核中(即将针对上游推出)

Binder 驱动程序一直支持 nice 优先级继承。随着 Android 中以实时优先级运行的进程日益增加,现在出现以下这种情形也属正常:如果实时线程进行 Binder 调用,则处理该调用的进程中的线程同样会以实时优先级运行。为了支持这些使用情景,Android O 现在在 Binder 驱动程序中实现了实时优先级继承。

除了事务级优先级继承之外,“节点优先级继承”允许节点(Binder 服务对象)指定对该节点执行调用操作所需的最低优先级。之前版本的 Android 已经通过 nice 值支持节点优先级继承,但 Android O 增加了对实时调度政策节点继承的支持。

注意:Android 性能团队发现,实时优先级继承会对框架 Binder 域 (/dev/binder) 造成不必要的负面影响,因此已对该域停用实时优先级继承。

用户空间更改

Android O 纳入了在通用内核中使用现有 Binder 驱动程序所需的所有用户空间更改,但有一个例外:针对 /dev/binder 停用实时优先级继承的原始实现使用的是 ioctl。由于后续开发将优先级继承的控制方法改为了更加精细的方法(根据 Binder 模式,而非上下文),因此,ioctl 不存于 Android 通用分支中,而是提交到了我们的通用内核中

此项更改的影响是,所有节点均默认停用实时优先级继承。Android 性能团队发现,为 hwbinder 域中的所有节点启用实时优先级继承会有一定好处。要达到同样的效果,请在用户空间中择优实施此更改

通用内核的 SHA

要获取对 Binder 驱动程序所做的必要更改,请同步到下列 SHA(或更高版本):

  • 通用 3.18 版
    cc8b90c121de ANDROID: Binder:请勿在还原时检查优先级权限。
  • 通用 4.4 版
    76b376eac7a2 ANDROID: Binder:请勿在还原时检查优先级权限。
  • 通用 4.9 版
    ecd972d4f9b5 ANDROID: Binder:请勿在还原时检查优先级权限。

使用 Binder IPC

一直以来,供应商进程都使用 Binder 进程间通信 (IPC) 技术进行通信。在 Android O 中,/dev/binder 设备节点成为了框架进程的专属节点,这意味着供应商进程将无法再访问该节点。供应商进程可以访问 /dev/hwbinder,但必须将其 AIDL 接口转为使用 HIDL。对于想要继续在供应商进程之间使用 AIDL 接口的供应商,Android 会按以下方式支持 Binder IPC。

vndbinder

Android O 支持供应商服务使用新的 Binder 域,这可通过使用 /dev/vndbinder(而非 /dev/binder)进行访问。添加 /dev/vndbinder 后,Android 现在拥有以下 3 个 IPC 域:

IPC 域 说明
/dev/binder 框架/应用进程之间的 IPC,使用 AIDL 接口
/dev/hwbinder 框架/供应商进程之间的 IPC,使用 HIDL 接口
供应商进程之间的 IPC,使用 HIDL 接口
/dev/vndbinder 供应商/供应商进程之间的 IPC,使用 AIDL 接口

为了显示 /dev/vndbinder,请确保内核配置项 CONFIG_ANDROID_BINDER_DEVICES 设为 "binder,hwbinder,vndbinder"(这是 Android 通用内核树的默认设置)。

通常,供应商进程不直接打开 Binder 驱动程序,而是链接到打开 Binder 驱动程序的 libbinder 用户空间库。为 ::android::ProcessState() 添加方法可为 libbinder 选择 Binder 驱动程序。供应商进程应该在调用 ProcessState,IPCThreadState 或(在一般情况下)发出任何 Binder 调用之前调用此方法。要使用该方法,请在供应商进程(客户端和服务器)的 main() 后放置以下调用:

ProcessState::initWithDriver("/dev/vndbinder");

vndservicemanager

以前,Binder 服务通过 servicemanager 注册,其他进程可从中检索这些服务。在 Android O 中,servicemanager 现在专用于框架和应用进程,供应商进程无法再对其进行访问。

不过,供应商服务现在可以使用 vndservicemanager,这是一个使用 /dev/vndbinder(作为构建基础的源代码与框架 servicemanager 相同)而非 /dev/binderservicemanager 的新实例。供应商进程无需更改即可与 vndservicemanager 通信;当供应商进程打开 /dev/vndbinder 时,服务查询会自动转至 vndservicemanager

vndservicemanager 二进制文件包含在 Android 的默认设备 Makefile 中。

SELinux 政策

想要使用 Binder 功能来相互通信的供应商进程需要满足以下要求:

  1. 能够访问 /dev/vndbinder
  2. 将 Binder {transfer, call} 接入 vndservicemanager
  3. 针对想要通过供应商 Binder 接口调用供应商域 B 的任何供应商域 A 执行 binder_call(A, B) 操作。
  4. 有权在 vndservicemanager 中对服务执行 {add, find} 操作。

要满足要求 1 和 2,请使用 vndbinder_use() 宏:

vndbinder_use(some_vendor_process_domain);

要满足要求 3,需要通过 Binder 通信的供应商进程 A 和 B 的 binder_call(A, B) 可以保持不变,且不需要重命名。

要满足要求 4,您必须按照处理服务名称、服务标签和规则的方式进行更改。

有关 SELinux 的详细信息,请参阅 Android 中的安全增强型 Linux。有关 Android 8.0 中 SELinux 的详细信息,请参阅 SELinux for Android 8.0

服务名称

以前,供应商进程在 service_contexts 文件中注册服务名称并添加用于访问该文件的相应规则。来自 device/google/marlin/sepolicyservice_contexts 文件示例:

AtCmdFwd                              u:object_r:atfwd_service:s0
cneservice                            u:object_r:cne_service:s0
qti.ims.connectionmanagerservice      u:object_r:imscm_service:s0
rcs                                   u:object_r:radio_service:s0
uce                                   u:object_r:uce_service:s0
vendor.qcom.PeripheralManager         u:object_r:per_mgr_service:s0

而在 Android O 中,vndservicemanager 会加载 vndservice_contexts 文件。迁移到 vndservicemanager 供应商服务(且已经在旧的 service_contexts 文件中)的供应商服务应该添加到新的 vndservice_contexts 文件中。

服务标签

以前,服务标签(例如 u:object_r:atfwd_service:s0)在 service.te 文件中定义。例如:

type atfwd_service,      service_manager_type;

在 Android O 中,您必须将类型更改为 vndservice_manager_type 并将规则移动到 vndservice.te 文件中。例如:

type atfwd_service,      vndservice_manager_type;

Servicemanager 规则

以前,规则会授予域访问权限,以向 servicemanager 添加服务或在其中查找服务。例如:

allow atfwd atfwd_service:service_manager find;
allow some_vendor_app atfwd_service:service_manager add;

在 Android O 中,这样的规则可继续存在并使用相同的类。例如:

allow atfwd atfwd_service:service_manager find;
allow some_vendor_app atfwd_service:service_manager add;