一直以来，供应商进程都使用 Binder 进程间通信 (IPC) 技术进行通信。在 Android 8 中，/dev/binder 设备节点成为框架进程的专有节点，这意味着供应商进程无法再访问此节点。供应商进程可以访问 /dev/hwbinder，但必须将其 AIDL 接口转为 HIDL接口。对于想要继续在供应商进程之间使用 AIDL 接口的供应商，Android 会按以下方式支持 Binder IPC。
Android 8 支持供 供应商服务使用的新 Binder 域，访问此域需要使用 /dev/vndbinder（而非 /dev/binder）。添加 /dev/vndbinder 后，Android 现在拥有以下 3 个 IPC 域：
dev/binder
这个是我们最熟悉的Binder，App开发中，ActivityManagerService用的都是这个，Java继承Binder，C++中继承Bbbinder，然后通过servicemanager进程注册实名Binder，然后通过已经创建好的Binder接口传递匿名Binder对象，拿到BinderProxy或者BpBinder以后，就可以Binder通信了。
dev/vndbinder
其实dev/vndbinde和dev/binder使用方式基本一样而且是共用一套Binder SDK，也是Java继承Binder，C++中继承Bbbinder，通过vndservicemanager进程注册实名Binder，然后通过已经创建好的Binder接口传递匿名Binder对象，拿到BinderProxy或者BpBinder以后，就可以Binder通信了。如何在使用同一套Binder SDK的代码，最后访问的设备节点变成dev/vndbinder，servicemanager变成vndservicemanager。
其实只要在你这个进程初始化的时候执行下面这个代码即可
ProcessState::initWithDriver("/dev/vndbinder");
dev/binder和dev/vndbinder无法在一个进程中同时使用
dev/hwbinder
硬件接口binder
为什么会引入 HwBinder？
HwBinder 引入的本质还是 Treble 机制的使用，这使得 system 和 vendor 分区相互隔离。在 Android 8.0 之前，Android HAL 与系统框架是紧耦合的，它们打包在一个镜像里。HAL只是一个个的so库，framework 通过打开动态库来调用 HAL。 为了适配 HwBinder，Android 8.0 同时引入了 HIDL，用于建立 framework 和 HAL 间的通信。
经过这个改变后，HAL 可以同时服务于 system 和 vendor。而 HAL 的实现位于 vendor 分区，通过 HwBinder 可以确保 system 和 vendor 独立升级，而不会影响 HAL 的调用。
HIDL是什么
假如Android官方定义了一个ILight.hal的HAL层接口
Interface ILight { void turnOn(); void turnOff(); }
通过编译会自动生成如下两个类LightServer和LightClient的java对象和c++对象。
供应商只需要简单的继承LightServer，并实现turnOn和turnOff的抽象方法，就可以完成Light接口的实现，以及Light服务注册到hwservicemanager。
需要使用ILight接口的进程，只需要调用LightClient的turnOn和turnOff接口，就可以完成从hwservicemanager获得Light服务的Proxy对象，以及ILight的接口调用。
