Project Treble和HAL架构
一. 传统的 Android 架构（Treble 之前）
在深入 Treble 之前，我们先看看传统的 Android 架构，这有助于理解 Treble 要解决的问题
传统的 Android 系统更新流程非常缓慢，其核心原因在于高度耦合的架构：
- Android 操作系统框架 (Android OS Framework)： 由 Google 开发，包含 App Runtime、系统服务等
- 硬件抽象层 (HAL)： 一系列由芯片制造商（如 Qualcomm, Mediatek）或设备制造商（OEM）实现的库（
.so文件）。这些库为 Android 框架提供标准接口来访问设备特定的硬件驱动，例如camera.hal.so,audio.hal.so - Linux 内核 (Linux Kernel)： 包含硬件驱动程序，由芯片制造商提供
问题所在：
在传统架构中，Android 框架 和 HAL 是紧密耦合的。框架直接调用 HAL 的特定版本（通过dlopen、dlsym动态加载 HAL 库）。这意味着：
- 当 Google 发布新版本的 Android（例如从 Android 8.0 升级到 9.0）时，它可能包含对 HAL 接口的修改
- 芯片制造商（SoC vendors）必须修改他们的 HAL 实现来适配新的框架
- 然后设备制造商（OEMs）需要整合这个新的 SoC 方案和新的 Android 版本
- 最后，运营商（Carriers）再进行各自的认证测试。
这个过程漫长而繁琐，导致绝大多数设备无法及时获得系统更新
二. Project Treble 的引入
为了解决上述问题，Android 8.0 (Oreo) 引入了 Project Treble。它的核心目标是 将 Android 系统框架与设备专用的底层软件（Vendor Implementation）分离开来，从而实现框架可以独立于供应商实现进行更新
Treble 的核心变革：引入 Vendor Interface (VINTF)
Treble 在 Android 框架和 HAL 之间定义了一个稳定的、版本化的接口契约，称为 Vendor Interface (VINTF)
这个接口就像一份“合同”，它规定：
- Android 框架： 承诺只通过 VINTF 中定义的标准方法来请求硬件服务
- 供应商实现（Vendor Implementation）： 承诺按照 VINTF 的规范来提供硬件服务，并且只要满足接口规范，其内部实现可以任意修改
这样，只要供应商提供的 HAL 符合 VINTF 规范，新版 Android 框架就可以直接在其上运行，而无需供应商为每个 Android 版本重新编写或修改 HAL
三. Treble 下的 HAL 架构
Project Treble 不仅定义了一个接口，还重新架构了 HAL 的实现和通信方式。主要有以下几种 HAL 类型：
1）直通式 HAL (Passthrough HAL) - 过渡方案
- 为了向后兼容旧的 HAL（用 C/C++ 实现），Treble 初期支持这种模式
- 工作原理： 一个包装器 HAL（符合新 HIDL 接口）通过
dlopen动态加载旧的传统 HAL 库。它只是将调用“直通”给旧 HAL - 现状： 现已不推荐使用，仅用于从旧架构过渡
2）绑定式 HAL (Binderized HAL) - Treble 的未来
这是 Treble 的现代标准模式
- 工作原理：
① HAL 被实现为一个独立的进程（Vendor Process），在设备启动时运行
② Android 框架进程（Framework Process）通过 HIDL 或 AIDL 接口定义语言描述的 RPC（远程过程调用）机制与 HAL 进程进行 IPC（进程间通信） - 优势：
○ 稳定性： HAL 进程崩溃不会导致整个系统崩溃
○ 安全性： 每个 HAL 进程都在自己的沙盒（SELinux 域）中运行，权限受到严格控制
○ 解耦： 框架和 HAL 完全分离，实现了 Treble 的核心目标
HAL 接口定义语言：HIDL 和 AIDL
- HIDL (HAL Interface Definition Language): Treble 初期引入的专用接口语言，用于描述框架和 Vendor 之间的接口。有
@1.0,@1.1,@1.2等版本，支持向后兼容 - AIDL (Android Interface Definition Language): 原本用于应用和框架之间的通信。从 Android 11 开始，AIDL for HAL 被引入，旨在逐步取代 HIDL。它提供了更好的版本管理、更简单的编程模型，并统一了 Android 的 IPC 生态
四. Treble 的实现组件
- Vendor Partition： Treble 要求系统必须有一个独立的 /vendor 分区。所有供应商提供的软件（HAL、内核模块、 firmware）都放在这里。这样，/system 分区（包含 Android 框架）可以独立于 /vendor 分区进行更新（例如通过 OTA）
- Vendor Test Suite (VTS)： 类似于 CTS（兼容性测试套件），但用于测试 Vendor Implementation 是否正确地实现了 VINTF 接口。这确保了任何符合 VTS 的 Vendor 实现都能与 Android 框架正确交互，是快速更新的质量保证
总结与对比
| 特性 | 传统架构 (Pre-Treble) | Project Treble 架构 |
|---|---|---|
| 核心问题 | 框架与 HAL 紧密耦合，更新缓慢 | 解决了耦合问题，实现快速更新 |
| 接口 | 无明确定义，直接链接 | Vendor Interface (VINTF)，稳定且版本化 |
| HAL 形态 | 作为库被框架进程加载 | 作为独立进程运行（绑定式） |
| 通信方式 | 进程内函数调用 | IPC（进程间通信），如 HIDL/AIDL |
| 分区 | 无独立 Vendor 分区 | 独立的 /vendor 分区 |
| 更新流程 | 需要 SoC 厂商、OEM 等多方协作 | Google 可单独更新 /system 分区 |
简单比喻：
- 传统架构： 就像电源线直接焊死在主板上，要换电源就得动主板
- Project Treble： 就像定义了一个标准的电源插座（VINTF）。只要插头符合规范，你可以随意更换电源（Vendor Implementation）或主板（Android Framework），它们都能正常工作
最终目标：
Project Treble 通过架构解耦、接口标准化和强制测试，极大地降低了设备制造商为旧设备提供新 Android 版本的难度和成本，从而让更多用户能更快地用上最新的 Android 系统。这也是为什么近年来 Android 手机的系统更新速度和支持周期得到了显著提升的根本原因