Android10.0 Binder通信原理(一)Binder、HwBinder、VndBinder概要-CSDN博客

[Android取经之路] 的源码都基于Android-Q（10.0）进行分析

[Android取经之路] 系列文章：

《系统启动篇》

Android系统架构
 Android是怎么启动的
 Android 10.0系统启动之init进程
 Android10.0系统启动之Zygote进程
 Android 10.0 系统启动之SystemServer进程
 Android 10.0 系统服务之ActivityMnagerService
Android10.0系统启动之Launcher(桌面)启动流程
 Android10.0应用进程创建过程以及Zygote的fork流程
 Android 10.0 PackageManagerService（一）工作原理及启动流程
 Android 10.0 PackageManagerService（二）权限扫描
 Android 10.0 PackageManagerService（三）APK扫描
 Android 10.0 PackageManagerService（四）APK安装流程
《日志系统篇》

Android10.0 日志系统分析(一)-logd、logcat 指令说明、分类和属性
 Android10.0 日志系统分析(二)-logd、logcat架构分析及日志系统初始化
 Android10.0 日志系统分析(三)-logd、logcat读写日志源码分析
 Android10.0 日志系统分析(四)-selinux、kernel日志在logd中的实现
《Binder通信原理》：

《HwBinder通信原理》

1.概述
在Android的中，我们知道每个应用都是一个独立的进程，有一个独立的虚拟机，应用和应用之间的内存是不能共享数据的，但是我们用到Activity、Service、Context、provider等功能，恰恰做了很多数据传输，这是为什么呢？

这就涉及到了我们了解的进程间通信机制-IPC(Inter-Process Communication)。

在Android中常常使用的进程间通信有共享内存、管道、信号处理、socket、Binder等。每个通信方式都有各自的优缺点，Android通常在合适的地方使用合适的通信方式，比如：内核和用户空间常用的是共享内存机制，一些低数据传输使用socket处理，应用进程之间传输使用Binder机制。

本节开始，我们一起来研究一下Binder的机制原理。

2.Binder的划分
在Android 8.0 之前，Binder机制比较简单，只有一个驱动设备"/dev/binder",一个守护进行"/system/bin/servicemanager"，一个binder库"/system/lib64/libbinder.so".

在Android 8.0开始，Android引入了Treble的机制，为了方便Android系统的快速移植、升级，提升系统稳定性，Binder机制被拓展成了"/dev/binder", "/dev/hwbinder","/dev/vndbinder"。

我们原先使用的"/dev/binder",成为框架进程的专有节点，这意味着供应商进程无法再访问此节点。供应商进程可以访问 /dev/hwbinder，但必须将其 AIDL 接口转为使用 HIDL。

对于想要继续在供应商进程之间使用 AIDL 接口的供应商，需要使用 /dev/vndbinder（而非 /dev/binder）。

Android8.0及之后的Binder域如下图所示：

3.三种Binder介绍以及之间的联系

binder\hwbinder\vndbinder 三者的使用方式可以参考下图，下图只是简单的阐述了逻辑关系，细节部分后面再划分章节进行阐述。

3.1 Binder
在Android 8.0之前，这是我们最熟悉也一直使用的Binder。Java层继承Binder，Native C/C++层继承Bbbinder，然后通过servicemanager进程注册实名Binder，然后通过已经创建好的Binder接口传递匿名Binder对象，拿到BinderProxy或者BpBinder以后，就可以Binder通信了。

在Android 8.0后，这个Binder机制继续保留，/dev/binder 设备节点成为框架进程的专有节点，这意味着供应商进程无法再访问此节点。

如果你是系统厂商，在system分区有进程，/dev/biner机制还是可以继续使用，但是你的进程在vendor分区，那只能使用/dev/hwbinder 或者/dev/vndbinder.

Binder机制需要两个进程都同属于System分区

3.2 VndBinder
Android8.0 支持供供应商服务使用的新 Binder 域，访问此域需要使用 /dev/vndbinder（而非 /dev/binder）。为了显示 /dev/vndbinder，请确保内核配置项 CONFIG_ANDROID_BINDER_DEVICES 设为 "binder,hwbinder,vndbinder"（这是 Android 通用内核树的默认设置）。vndbinder和binder共用libbinder这个系统库，只是在守护进程和内核空间有一些区别，整体代码流程和使用方式基本一致。

Java层继承Binder，Native C/C++层继承Bbbinder，通过vndservicemanager进程注册实名Binder，然后通过已经创建好的Binder接口传递匿名Binder对象，拿到BinderProxy或者BpBinder以后，就可以Binder通信了。

和Binder的区别，就是device变成了"/dev/vndbinder", 守护进程变成了"vndservicemanager"

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

dev/binder和dev/vndbinder无法在一个进程中同时使用

binder和vndbiner 的机制共用一套libbinder，因此两者使用时，每次只能指定一个设备节点，不能同时使用。

VndBinder机制需要两个进程都同属于Vendor分区

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

不过，供应商服务现在可以使用 vndservicemanager，这是一个使用 /dev/vndbinder（作为编译基础的源代码与框架 servicemanager 的相同）而非 /dev/binder 的 servicemanager 的新实例。

供应商进程无需更改即可与 vndservicemanager 通信；当供应商进程打开 /dev/vndbinder 时，服务查询会自动转至 vndservicemanager。

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

3.3 HwBinder
hwbinder和 binder\vndbinder又有所区别，hwbinder是一套全新的流程，有单独的驱动设备"/dev/hwbinder",独立的守护进程"hwservicemanager"，独立的SDK-"libhwbinder"

HwBinder机制可以跨System和Vendor分区使用

3.3.1 为什么要引入hwbinder
Android 8.0中引入了Treble机制，Treble 项目通过将底层供应商实现从 Android 内核框架中剥离出来，使Android更新变得更简单。这种模块化的设计允许分别独立更新平台和供应商提供的组件。让更新变得更轻松、更快速已经很棒，然而，Treble 加强模块化设计还有一个目的：提高安全性。

Treble引入后，新增了一个vendor.img, 即原先的system分区，被拆分为了system分区和vendor分区，soc及供应商的功能实现都需要放到vendor分区，这样将system和vendor相关的镜像分开，便于能方便地更新和升级system，并且不依赖vendor等底层。

在Android 8.0之前，HAL是一个个的.so库，通过dlopen来进行打开，库和framework位于同一个进程，在此之前的Android 系统架构当中，Android Framework 与Android HAL是打包成一个system.img的，而且Framework 与HAL之间是紧耦合的，通过链接的方式使用相应的硬件相关so库。

Android 8.0之前的通信机制如下图所示：

所以每次Android framework的升级需要对应的Android HAL升级，这需要供应商花费很多的人力去升级相应的 Vendor HAL Implemetation，这也就是导致Android版本升级很缓慢，很多用户几年之后，Android都不能得到及时更新。

在Android8.0及以后的版本中，Android设计了一套新的机制来隔离HAL层，引入了一个HIDL的语言来定义Framework和HAL之间的接口

在Android 8.0以及以后的版本当中，Android 更新了新的框架设计在新的框架设计当中，引入了一套叫HIDL的语言来定义Freamework与HAL之间的接口，Android Framework会在system分区当中，而VendorHAL Implemetation会在一个新定义的分区(Vendor.img)当中，这样刷新的system.img 才不会影响到Vendor HAL Implemetation。

在Android 8.0及之后，HAL库和framework不在同一个进程，他们之间使用hwbinder进行进程间通信。

Android 8.0引入Treble后，各层的通信机制如下：

4. Binder库的变化

Binder和VndBinder共同使用libbinder， HwBinder使用libhwbinder，代码的目录差异如下：

servicemanager的目录差异如下：

5.总结
Android引入Treble机制后，扩展了一个vendor分区，为了能够快速的进行升级，做了隔离HAL层的机制，为了System/System、System/Vendor、Vendor/Vendor 之间进行不同的进程间通信，把原有的Binder机制拆分成了Binder、HwBinder、VndBinder。

Binder和VndBinder 共用一套libbinder、servicemanager的代码，使用AIDL接口，两者不能共存。

HwBinder采用了单独的libhwbinder、hwservicemanager的代码，单独管理，使用HIDL接口。

三者之间互不干扰，在方便系统升级的同时，又提升了系统的安全和稳定性。

接下来，我会单独拆分不同的小节，来单独分享Binder、HwBinder、VndBinder的工作原理。