这个问题其实网络上答案比较多,属于android想要让厂商快速升级解耦制定的,即把原来系统framework和厂商耦合的hal在同一个个system.img进行剥离开,把厂商相关的放到vendor.img,aosp系统公共部分framework相关的放到system.img.
官方解释:
Android O的一项新元素是 Project Treble。这是 Android 操作系统框架在架构方面的一项重大改变,旨在让制造商以更低的成本更轻松、更快速地将设备更新到新版 Android 系统。
在Android O之前,HAL是一个个的.so库,通过dlopen来进行打开,库和framework位于同一个进程。
新的架构之下,framework和hal运行于不同的进程,所有的HAL采用新的HIDL技术来完成。作为此变化的一部分,运行 Android 8.0 的设备必须支持绑定式或直通式 HAL:
绑定式 HAL
以 HAL 接口定义语言 (HIDL) 表示的 HAL。这些 HAL 取代了早期 Android 版本中使用的传统 HAL 和旧版 HAL。在绑定式 HAL 中,Android 框架和 HAL 之间通过 Binder 进程间通信 (IPC) 调用进行通信。所有在推出时即搭载了 Android 8.0 或后续版本的设备都必须只支持绑定式 HAL。
直通式 HAL
以 HIDL 封装的传统 HAL 或旧版 HAL。这些 HAL 封装了现有的 HAL,可在绑定模式和
Same-Process(直通)模式下使用。升级到 Android 8.0 的设备可以使用直通式 HAL。
一看就知道绑定式HAL是主推方法了,后面的HAL也将用绑定式HAL方式编写。
第一种就没啥可以分析的,在8.0以前都是这种方式,即直接应用进程包含一个hw的so,针对以上的其他几个情况分析:
这里其实采用就是直通式,目前系统中使用这种方式的较少,最经典就是android.hardware.graphics.mapper@2.0::IMapper/default这个库还是采用这种直通式。
什么是直通式?
最重要区分直通式域绑定式在于调用端客户进程是否和服务端提供hal功能实现的,是否在一个进程执行。
这里也是使用了hidl,但是明显这个地方他只是做了一下接口包装,所有hal的执行依然在客户端进程。
这种方式就是采用是绑定式,这样对system的应用或者框架,就可以通过hidl或aidl接口来通讯,但是绑定服务的具体实现其实还是调用了以前的老hal so方式来实现服务的。
这种方式实现的代表就有audio部分 android.hardware.audio@6.0::IDevicesFactory/default,
他的实现方式就是有一个单独的服务android.hardware.audio.service:
audioserver 968 1 49636 17696 0 0 S android.hardware.audio.service
这个服务与audioserver这种客户端进行跨进程通讯,audioserver就通过hidl相关接口调用到android.hardware.audio.service,android.hardware.audio.service具体实现是调用的原来的hal那一套hw库,相当于所有相关的业务其实还在老款的hal库里面
这个和上面其实绑定式理解没啥区别,只是在服务端实现有区别,这种实现是直接自己服务端实现hal,而上面实现却是调用了老版本的hal库,这种方式要求新加入的hal库都是这种实现方式,完全所有的实现在服务端进程里面,即不需要在额外包裹hw库方式,厂商编译时候可以考虑直接提供相关的可执行文件既可以
如下图就是直接提供了相关的hal的可执行文件:
这里就直接提供了相关指纹的bin文件进行集成
更多framework干货课程优惠获取相关可以+V(androidframework007)
视频:https://www.bilibili.com/video/BV1ah411d7Y3