Android Binder通信原理--01：Binder、Hw
本文基于Android 10.0源码分析
1.摘要
本节主要来讲解Android10.0 Binder、HwBinder、VndBinder的关联与各自作用。
2.概述
在Android的中，我们知道每个应用都是一个独立的进程，有一个独立的虚拟机，应用和应用之间的内存是不能共享数据的，但是我们用到Activity、Service、Context、provider等功能，恰恰做了很多数据传输，这是为什么呢？
这就涉及到了我们了解的进程间通信机制-IPC(Inter-Process Communication)。
在Android中常常使用的进程间通信有 共享内存、管道、信号处理、socket、Binder等。每个通信方式都有各自的优缺点，Android通常在合适的地方使用合适的通信方式，比如：内核和用户空间常用的是共享内存机制，一些低数据传输使用socket处理，应用进程之间传输使用Binder机制。
本节开始，我们一起来研究一下Binder的机制原理。
3.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域如下图所示：
Binder1-1.png
4.三种Binder介绍以及之间的联系
binder\hwbinder\vndbinder三者的使用方式可以参考下图，下图只是简单的阐述了逻辑关系，细节部分后面再划分章节进行阐述。
Binder1-2.png
4.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分区：
Binder1-3.png
4.2 VndBinder
Android 8.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分区：
Binder1-4.png
4.2.1 vndservicemanager
以前，Binder 服务通过servicemanager注册，其他进程可从中检索这些服务。在 Android 8.0中，servicemanager现在专供框架使用，而应用进程和供应商进程无法再对其进行访问。
不过，供应商服务现在可以使用vndservicemanager，这是一个使用/dev/vndbinder（作为编译基础的源代码与框架servicemanager的相同）而非/dev/binder的servicemanager的新实例。
供应商进程无需更改即可与vndservicemanager通信；当供应商进程打开/dev/vndbinder 时，服务查询会自动转至vndservicemanager。
vndservicemanager二进制文件包含在Android 的默认设备Android.bp中。
4.3 HwBinder
hwbinder和binder\vndbinder又有所区别，hwbinder是一套全新的流程，有单独的驱动设备"/dev/hwbinder"，独立的守护进程"hwservicemanager"，独立的SDK-"libhwbinder"。
HwBinder机制可以跨System和Vendor分区使用：
Binder1-5.png
4.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之前的通信机制如下图所示：
Binder1-6.png
所以每次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分区当中，而Vendor HAL Implemetation会在一个新定义的分区(vendor.img)当中，这样刷新的system.img才不会影响到Vendor HAL Implemetation。
在Android 8.0及之后，HAL库和framework不在同一个进程，他们之间使用hwbinder进行进程间通信。
Android 8.0引入Treble后，各层的通信机制如下：
Binder1-7.png
5.Binder库的变化
Binder和VndBinder共同使用libbinder， HwBinder使用libhwbinder，代码的目录差异如下：
Binder1-8.png
servicemanager的目录差异如下：
Binder1-9.png
6.总结
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的工作原理。
