2. HAL层基础:概念、架构位置与模块关系

HAL(Hardware Abstraction Layer,硬件抽象层)是Android系统中连接Framework与底层硬件驱动的关键中间层。理解HAL的概念、架构位置以及模块与Stub的关系,是进行VTS HAL层接口协议验证的前提。

2.1 HAL的概念与设计目标

HAL的核心设计目标是解耦:将Android系统框架与具体的硬件实现分离。通过定义一套标准化的接口,HAL使得上层应用和服务无需关心底层硬件的具体型号、厂商或驱动实现细节。

核心价值: 厂商只需按照HAL接口规范实现对应的模块,即可保证硬件在Android系统上的兼容性;Google则通过VTS测试来验证这些接口是否符合规范。
设计目标 说明 对VTS的影响
接口标准化 定义统一的硬件操作API,如open、close、ioctl等 VTS验证接口签名与行为是否一致
厂商无关性 允许不同厂商实现各自的硬件适配代码 VTS确保所有实现满足最低功能要求
版本兼容 通过HAL版本号管理接口演进 VTS检查版本声明与接口匹配
性能隔离 硬件操作不直接影响Framework稳定性 VTS测试异常路径与资源管理

2.2 HAL在Android架构中的位置

HAL位于Android系统架构的中间层,向上承接Framework的硬件服务(如CameraService、AudioFlinger),向下对接Linux内核驱动。其层次关系如下图所示:

Android 系统架构中的 HAL 层位置 应用层 (Applications) Java Framework (CameraService / AudioFlinger / SensorService) HAL 层 (Hardware Abstraction Layer) HAL Module / Stub 实现 Linux 内核 (Kernel Driver) I2C / SPI / UART / DMA 硬件设备 (Camera / Audio Codec / Sensor) VTS 测试 目标
VTS测试焦点: 上图中红色标记的HAL层是VTS测试的核心目标。VTS会通过HAL Client端调用Stub接口,验证其行为是否符合《Android Compatibility Definition Document (CDD)》和HAL接口规范。

2.3 HAL模块与Stub的关系

在Android HAL架构中,HAL Module和HAL Stub是两个紧密关联但职责不同的概念。理解它们的关系是编写和测试HAL实现的基础。

2.3.1 HAL Module(模块)

HAL Module是HAL层的逻辑容器,负责管理同一类硬件设备的所有Stub实例。每个HAL Module对应一个硬件类型(如camera、audio、sensors),并通过唯一的module_id标识。

2.3.2 HAL Stub(存根)

HAL Stub是HAL Module内部的具体实现单元,代表一个具体的硬件设备实例。例如,一个Camera HAL Module可以包含多个Camera Stub,分别对应前置摄像头和后置摄像头。

对比维度 HAL Module HAL Stub
角色 模块管理器 设备实例
标识 module_id(如 camera) device_id(如 0、1)
生命周期 进程启动时加载,常驻内存 按需打开/关闭
核心结构体 hw_module_t hw_device_t
VTS测试对象 验证模块加载、版本号、接口列表 验证open/close/ioctl等具体操作

2.3.3 模块与Stub的协作流程

HAL Module与Stub的协作遵循标准的加载-打开-操作-关闭生命周期:

  1. 模块加载: Framework通过hw_get_module()函数根据module_id加载对应的HAL Module动态库(如camera.xxx.so)。
  2. 设备打开: 调用Module的open()方法,传入device_id,返回对应的Stub实例指针。
  3. 设备操作: 通过Stub提供的接口(如set_parameters()、start_preview())进行硬件操作。
  4. 设备关闭: 调用close()释放Stub资源。
HAL Module 与 Stub 协作流程 Framework hw_get_module() HAL Module 1. 加载模块 返回module module->open() HAL Stub (设备实例) 2. 打开设备 Stub 接口操作 3. 操作硬件 stub->close() 4. 关闭设备 VTS 测试关键点 • 模块加载是否成功 • open/close 配对 • 接口返回值正确性 • 异常路径处理

2.4 关键数据结构

HAL Module和Stub的实现基于两个核心结构体:hw_module_t和hw_device_t。所有HAL模块都必须以这两个结构体为起点进行扩展。

2.4.1 hw_module_t 结构体

typedef struct hw_module_t {
    uint32_t tag;              // 必须初始化为 HARDWARE_MODULE_TAG
    uint16_t module_api_version; // 模块API版本
    uint16_t hal_api_version;    // HAL API版本
    const char *id;            // 模块ID,如 "camera"
    const char *name;          // 模块名称
    const char *author;        // 作者信息
    struct hw_module_methods_t *methods; // 模块方法表
    void *dso;                 // 动态库句柄
    uint32_t reserved[32];     // 保留字段
} hw_module_t;

2.4.2 hw_device_t 结构体

typedef struct hw_device_t {
    uint32_t tag;              // 必须初始化为 HARDWARE_DEVICE_TAG
    uint32_t version;          // 设备版本
    struct hw_module_t *module; // 所属模块指针
    uint32_t reserved[12];     // 保留字段
    int (*close)(struct hw_device_t* device); // 关闭设备
} hw_device_t;
VTS验证要点: 在VTS测试中,会检查hw_module_t的tag字段是否被正确初始化为HARDWARE_MODULE_TAG,以及module_api_version是否与声明的接口版本一致。任何字段的非法值都会导致VTS测试失败。

2.5 模块加载机制

Android系统通过hw_get_module()函数实现HAL模块的动态加载。该函数按照以下优先级搜索HAL实现库:

  • 系统路径: /vendor/lib/hw/ 或 /vendor/lib64/hw/(优先)
  • 兼容路径: /system/lib/hw/ 或 /system/lib64/hw/(备选)
  • 命名规则: <MODULE_ID>.<TARGET_BOARD_PLATFORM>.so,例如 camera.tuna.so
搜索路径 优先级 说明
/vendor/lib/hw/ 高 厂商提供的HAL实现,VTS测试主要目标
/system/lib/hw/ 低 系统默认实现,通常为参考实现
/odm/lib/hw/ 中 ODM定制实现,Android 8.0+引入
VTS测试提示: 在VTS测试中,会模拟hw_get_module()的调用过程,验证模块是否能够被正确加载,以及加载后的模块接口是否完整。如果模块库缺失或命名错误,VTS会直接报告MODULE_NOT_FOUND错误。