查看原文
其他

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

IngresGe IngresGe 2021-11-05

阅读本文大约需要花费10分钟。

《Android取经之路》系列文章:

《系统启动篇》

Android取经之路——启动篇

Android系统架构

Android是怎么启动的

Android系统启动之init进程(一)

Android系统启动之init进程(二)

Android 10.0系统启动之init进程(三)

Android 10.0系统启动之init进程(四)

Android 10.0系统启动之Zygote进程(一)

Android 10.0系统启动之Zygote进程(二)

Android 10.0系统启动之Zygote进程(三)

Android 10.0系统启动之Zygote进程(四)

Android 10.0系统启动之SystemServer进程(一)

Android 10.0系统启动之SystemServer进程(二)

Android 10.0系统服务之AMS启动流程

Android 10.0系统启动之Launcher(桌面)启动流程

Android 10.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中的实现



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




参考:

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


: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存