AndroidO Treble架构下的变化（转载）

转载： https://blog.csdn.net/yangwen123/article/details/79836109

AndroidO引入Treble架构后，有那些变化呢？

 

1. 增加了多个服务管家，AndroidO之前版本有且只有一个servicemanager，现在增加到3个，他们分管不同的服务。

2.增加了binder通信库，这是为了适配binder域的扩展。

3.增加了binder域，系统定义了3个binder设备节点，binder驱动分别处理这3个binder设备节点上的binder通信事件。

 

Binder通信域变化

Treble架构的引入足以说明Binder通信的重要性，之前APP和Framework之间通过binder实现跨进程调用，当然这个调用对开发者来说是透明的，相当于函数本地调用。Treble引入后，Framework和HAL又实现了进程分离，Framework和HAL之间依然使用binder通信，通过HIDL来定义通信接口。那binder通信有什么变化呢？ 在Treble中，引入了多个binder域，主要是增加了多个binder设备，binder驱动实现原理基本没变，变化了一些细节。增加binder设备应该是为了实现更换的权限控制，使用不同binder设备的主体和客体之间的selinux权限有所不同，同时，Android 框架和 HAL 现在使用 Binder 互相通信。由于这种通信方式极大地增加了 Binder 流量。

为了明确地拆分框架（与设备无关）和供应商（与具体设备相关）代码之间的 Binder 流量，Android O 引入了“Binder 上下文”这一概念。每个 Binder 上下文都有自己的设备节点和上下文（服务）管理器。您只能通过上下文管理器所属的设备节点对其进行访问，并且在通过特定上下文传递 Binder 节点时，只能由另一个进程从相同的上下文访问上下文管理器，从而确保这些域完全互相隔离。为了显示 /dev/vndbinder，请确保内核配置项 CONFIG_ANDROID_BINDER_DEVICES 设为"binder,hwbinder,vndbinder"

这样在驱动中就创建了binder、vndbinder、hwbinder三个驱动设备，并保存在binder设备列表binder_devices中。/dev/binder 设备节点成为了框架进程的专属节点，这意味着oem进程将无法再访问该节点。oem进程可以访问 /dev/hwbinder，但必须将其 AIDL 接口转为使用 HIDL

binder驱动设备

hwbinder驱动设备

vndbinder驱动设备

由于vndbinder和binder使用的都是libbinder.so库，因此在打开binder设备时，需要调用：

ProcessState::initWithDriver("/dev/vndbinder");

来指定打开那个binder设备。

 

服务管家变化

AndroidO将服务管家从servicemanager扩展到以下3个：

 

 

Binder通信框架变化

 

1.在普通Java Binder框架中，Client端Proxy类完成数据打包，然后交给mRemotebinder代理来完成数据传输。Server端Stub类完成数据解析，然后交给其子类实现。

2.在普通Native Binder框架中，Client端BpXXX类完成数据打包，然后交给mRemoteBpBinder来完成数据传输。Server端BnXXX类完成数据解析，然后交个其子类实现。

3.  在HwBinder框架中，Client端的BpHwXXX类完成数据打包，然后交给mRemoteBpHwBinder来完成数据传输。Server端的BnHwXXX类完成数据解析，然后交给_hidl_mImpl来实现。
 

框架层Binder对象变化