在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的工作原理。

参考：

《binder，hwbinder，vndbinder之间的关系》

https://linus.blog.csdn.net/article/details/104289913

《Android O 前期预研之一：Android Treble 计划》

https://blog.csdn.net/ljp1205/article/details/77684550

《使用 Binder IPC》

https://source.android.google.cn/devices/architecture/hidl/binder-ipc

继续滑动看下一个