2. HAL层基础:概念、架构位置与模块关系
HAL(Hardware Abstraction Layer,硬件抽象层)是Android系统中连接Framework与底层硬件驱动的关键中间层。理解HAL的概念、架构位置以及模块与Stub的关系,是进行VTS HAL层接口协议验证的前提。
2.1 HAL的概念与设计目标
HAL的核心设计目标是解耦:将Android系统框架与具体的硬件实现分离。通过定义一套标准化的接口,HAL使得上层应用和服务无需关心底层硬件的具体型号、厂商或驱动实现细节。
| 设计目标 | 说明 | 对VTS的影响 |
|---|---|---|
| 接口标准化 | 定义统一的硬件操作API,如open、close、ioctl等 | VTS验证接口签名与行为是否一致 |
| 厂商无关性 | 允许不同厂商实现各自的硬件适配代码 | VTS确保所有实现满足最低功能要求 |
| 版本兼容 | 通过HAL版本号管理接口演进 | VTS检查版本声明与接口匹配 |
| 性能隔离 | 硬件操作不直接影响Framework稳定性 | VTS测试异常路径与资源管理 |
2.2 HAL在Android架构中的位置
HAL位于Android系统架构的中间层,向上承接Framework的硬件服务(如CameraService、AudioFlinger),向下对接Linux内核驱动。其层次关系如下图所示:
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的协作遵循标准的加载-打开-操作-关闭生命周期:
- 模块加载: Framework通过
hw_get_module()函数根据module_id加载对应的HAL Module动态库(如camera.xxx.so)。 - 设备打开: 调用Module的
open()方法,传入device_id,返回对应的Stub实例指针。 - 设备操作: 通过Stub提供的接口(如
set_parameters()、start_preview())进行硬件操作。 - 设备关闭: 调用
close()释放Stub资源。
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;
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+引入 |
hw_get_module()的调用过程,验证模块是否能够被正确加载,以及加载后的模块接口是否完整。如果模块库缺失或命名错误,VTS会直接报告MODULE_NOT_FOUND错误。