本文转载自:https://blog.csdn.net/yangwen123/article/details/79835965
从AndroidO开始，google引入了Treble架构，目的是为了方便系统升级，将oem定制的东西和Framework分离。
AndroidO之前的版本：
在此之前的Android系统架构当中，Android Framework与Android HAL是打包成一个system.img的，而且Framework与HAL之间是紧耦合的，通过链接的方式使用相应的硬件相关so库。老版本的android 的系统框架当中framework与HAL之间的一般架构框架是：
所以每次Android framework的升级需要对应的Android HAL升级。
AndroidO以及以后的版本
在Android O以及以后的版本当中，Android 更新了新的框架设计在新的框架设计当中，引入了一套叫HIDL的语言来定义Freamework与HAL之间的接口，新的架构如下图：
跟以往的Android 版本相比较，Android O里使用HIDL来解耦Android Framework 与Vendor HAL Implemetation之间的关系，从而简化降低Android系统升级的影响与难度。
Android Framework会在system分区当中，而Vendor HAL Implemetation会在一个新定义的分区(Vendor.img)当中，这样刷新的system.img 才不会影响到Vendor HAL Implemetation，所以在Android O中的升级方式变成以下方式：
google的目的很理想，但现实很残酷，大部分oem厂商是没有google的研发实力的，无法跟上google的节奏，因此很多厂商还停留在android老版本，为了给oem厂商学习时间，同时保持Android向前兼容，google为HAL定义了3种类型：
1，BinderizedHALs，从名字上应该是指Binder化的HAL，也就是说HAL都被写成了binder service了，Android FW都是binder client。
2，PassthroughHALs，从google的官方介绍来说，这个是对原先HAL的包装，但是最终的binder service 跟binder client都是活在同一个进程当中。这个应该是对老版本HAL的兼容。
3，Same-ProcessHALs,由于某些性能的因素，这些HALs必须运行在Android Framework 所在的进程当中，比如surfaceflinger中的gralloc hal，如果进行进程分离，那么对系统性能影响较大。