1. CTS 与 Treble 概述

本章是《Treble 框架中 CTS 兼容性测试的故障排查》的起点。理解 CTS（Compatibility Test Suite）的测试目的、Treble 架构的设计理念以及 HAL（Hardware Abstraction Layer）与 Treble 的关系，是后续进行故障排查的基础。本节将系统梳理这三个核心概念，并建立它们之间的逻辑关联。

1.1 CTS 测试目的

CTS（兼容性测试套件）是 Google 为确保 Android 设备在不同厂商、不同硬件平台上能够一致地运行 Android 应用而设计的一套自动化测试工具。其核心目的包括：

• 保证应用兼容性：确保所有通过 CTS 认证的设备都能正确运行 Google Play 商店中的标准应用。
• 维护生态一致性：防止厂商对 Android 框架进行不兼容的修改，从而破坏开发者与用户的使用体验。
• 验证 API 实现：测试设备对 Android 公开 API 的实现是否完整、正确，包括系统服务、权限管理、硬件抽象等。
• 驱动系统稳定性：通过大量压力测试与边界条件测试，暴露系统底层（如 HAL、内核驱动）的潜在缺陷。

1.2 Treble 架构简介

Project Treble 是 Android 8.0（API 级别 26）引入的重大架构重构，旨在将 Android 框架与厂商实现的底层硬件代码解耦。其核心思想是：将 HAL 接口标准化、稳定化，并作为框架与厂商实现之间的契约。

Treble 架构的关键组件与层级关系如下表所示：

以下 SVG 图展示了 Treble 架构的核心分层与组件间的关系：

1.3 HAL 与 Treble 的关系

HAL（硬件抽象层）是 Android 系统中连接框架与硬件的关键桥梁。在 Treble 引入之前，HAL 以共享库（.so）的形式直接链接到框架进程，导致框架与厂商代码高度耦合。Treble 通过以下方式重塑了 HAL 与框架的关系：

• 接口标准化：使用 HIDL（HAL Interface Definition Language）或 AIDL 定义 HAL 接口，取代传统的直接函数调用。
• 进程隔离：HAL 实现运行在独立的 vendor 进程（如 hwservicemanager 管理的服务）中，框架通过 Binder 或 HwBinder 进行跨进程通信。
• 版本化契约：每个 HAL 接口都有明确的版本号（如 1.0、1.1、2.0），框架与厂商实现必须匹配版本，否则 CTS 测试将失败。
• VNDK 机制：Vendor Native Development Kit（VNDK）为厂商提供一组稳定的系统库，确保厂商代码不依赖框架内部私有 API。

以下 SVG 图展示了传统架构与 Treble 架构中 HAL 与框架关系的对比：

1.4 CTS 与 Treble 的关联

CTS 测试与 Treble 架构之间存在紧密的依赖关系。Treble 的引入直接影响了 CTS 的测试范围与测试方式：