介绍
在前面的教程中，我们学习了Treble是如何解决Android碎片化的大致原理，使得Android可以快速更新。
借助Treble，谷歌还推出一系列测试，即VTS [记住CTS是测试Android API兼容性的]，以测试Vendor Interface的兼容性。
在本教程中，我们尝试分析Treble之前和之后两个Android版本之间的主要差异，以了解发生了哪些改变。这也让我们更好的理解需要做哪些结构上的更改才能符合Treble标准。
主要差异
在开始之前，让我们重温一下Android组件/系统架构。我们可以看到HAL[硬件抽象层]是访问系统下硬件的中间层。它们通常被相应的Service调用，间接操作相应的硬件[如CameraService使用CameraHAL开始预览或拍照]。
硬件抽象层（HAL）
HAL定义了硬件厂商实现的标准接口，使得底层驱动实现对于Android是透明不可知的。使用HAL作为中间层来实现功能，不会影响或者修改上层系统。HAL实现会被打包到模块so库中，并且在恰当的时候由Android系统动态加载使用。
在Android O系统架构中，Android Framework和Android HAL[ 硬件抽象层 ]被打包到system.img中。核心Android Framework和HAL紧密耦合。使用链接或者dlopen调用将硬件相关库直接加载到进程上下文中[通常这些HAL库位于/system/lib/hw中]。
在旧版android系统框架中，framework和HAL之间的框架结构如下图所示：
由上图可知，Framework和HAL之间没有明确的界限，因此这里可能存在两个问题。
1.HAL中的任何崩溃和错误行为都容易导致进程崩溃。
2.Framework层中的任何更新都要重新编译、打包HAL层。
通过Treble，Android引入了一种新的方式来加载和使用这些HAL，他与主进程上下文分离，并且不需要单独更新[甚至不需要重新编译]来更新核心Android Framework。
下图更详细的说明了这一点：
从上图可知，使用名为hwbinder的新binder接口来调用厂商HAL[ 这保证即使HAL崩溃，对应的服务进程也不会崩溃 ]。
由于这种解耦方式让厂商HAL独立于核心Framework[ service ]，因此可以不改变HAL的情况下更新Framework。
分区
通过这种加载和使用供应商HAL的新方式，Android划分出了核心框架代码【system.img】和供应商HAL的【vendor.img】。
众所周知，vendor.img的概念早已存在，但是，它现在被强制生成用来解耦Framework和HAL。
- system.img。主要包含Android framework。
- boot.img。包含Linux内核+Android补丁。
- vendor.img。包含特定于SoC的代码和配置。
- odm.img。包含特定于设备的代码和配置。
- oem.img。包含OEM/运营商相关配置和自定义。
- bootloader。引导内核。
- radio。Modem(调制解调器)。
在Android 8.0之前，vendor、odm和oem镜像是可选的。当这些可选镜像不存在时，属于这些镜像的文件放在boot.img或者system.img中，并且带有相应的符号链接。
Android 8.0中vendor分区是必需的
目标是通过定义Android平台（在system.img上）和供应商代码之间的核心标准接口来模块化Android分区。此标准接口可以在不影响SoC和ODM分区的情况下更新Android平台。
例如，可以将设备system.img从Android O升级到Android P，而其他镜像（例如vendor.img，odm.img等）仍保持在Android O。
这种模块化可以及时的实现Android平台升级（例如每月的安全更新），而无需更改Soc/ODM等其他镜像。
Android Framework将驻留在system分区中。Vendor HAL Implementation将位于新定义的分区(vendor.img)中。
上图以简化的方式解释了这种新结构如何解耦并在Android设备上快速更新。
