使用 Binder IPC

转载：https://source.android.com/devices/architecture/hidl/binder-ipc?hl=zh-cn

本页介绍了 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 节点时，只能由另一个进程从相同的上下文访问上下文管理器，从而确保这些域完全互相隔离。如需使用方法的详细信息，请参阅 vndbinder 和 vndservicemanager。

分散-集中

在通用 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/binder 的 servicemanager 的新实例。供应商进程无需更改即可与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/sepolicy 的 service_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 ;