HAL测试从用例设计到多Camera兼容性验证 - 第2节

2.1 Android Camera HAL 整体架构

Android Camera HAL(Hardware Abstraction Layer)位于 Android 框架与底层 Camera 硬件驱动之间,是连接应用层与硬件的关键桥梁。其核心目标是为上层提供统一的 Camera 操作接口,屏蔽不同硬件厂商的实现差异。

架构定位:HAL 层向上对接 Android 框架的 CameraService,向下调用内核驱动(V4L2、私有驱动等),实现设备控制、数据流处理与图像格式转换。

2.1.1 分层结构

从系统层级看,Camera HAL 架构可划分为以下四个主要层次:

  1. 应用层(Application):通过 Android SDK 的 Camera2 API 或旧版 Camera API 发起拍照、录像等请求。
  2. 框架层(Framework):CameraService 管理多个 Camera 设备,分发请求并接收结果。
  3. HAL 层(Hardware Abstraction Layer):实现具体的设备操作逻辑,包括打开/关闭设备、配置流、处理请求等。
  4. 内核驱动层(Kernel Driver):通过 V4L2 或厂商私有接口与物理 Camera 传感器交互。
Android Camera HAL 整体分层架构 应用层 (Application) Camera2 API / Camera API 框架层 (Framework) CameraService / CameraProvider HAL 层 (Hardware Abstraction Layer) HAL1 / HAL3 实现 内核驱动层 (Kernel Driver) V4L2 / 私有驱动 HAL 层是上层框架与底层硬件之间的关键适配层,决定了 Camera 的性能与功能支持

2.2 HAL1 与 HAL3 的区别

Android 提供了两代 Camera HAL 接口:HAL1(传统接口)和 HAL3(Camera2 接口)。两者在设计理念、数据流模型、控制粒度上存在显著差异。

2.2.1 核心差异对比

对比维度 HAL1 HAL3
引入版本 Android 4.0 (API 14) Android 5.0 (API 21)
数据流模型 固定流水线,预览/拍照/录像独立 请求-响应模型,灵活配置流
控制粒度 粗粒度,仅支持基本参数 细粒度,支持逐帧控制(曝光、增益、对焦等)
多Camera支持 有限,通常仅支持主摄 原生支持多Camera同时操作
YUV/RAW输出 仅支持 JPEG 和预览 YUV 支持 YUV、RAW、HEIC 等多种格式
性能开销 较低,适合低端设备 较高,但功能更强大

2.2.2 数据流模型对比

HAL1 采用固定流水线模式,数据流路径在初始化时确定,无法动态调整。HAL3 采用请求-响应模型,每个 Capture Request 独立配置输出目标、控制参数和传感器设置。

HAL1 与 HAL3 数据流模型对比 HAL1:固定流水线 预览流 拍照流 录像流 固定参数 各流独立运行,无法动态切换 HAL3:请求-响应模型 Capture Request Capture Result 逐帧控制参数 多输出目标 每个请求独立配置,灵活组合 HAL3 的请求-响应模型支持更精细的控制,是实现高级拍照功能(如 HDR+、夜景模式)的基础
测试提示:在 HAL3 下测试时,需关注 Capture Request 的配置是否正确、Result 回调是否完整、以及多流并发时的资源竞争问题。HAL1 测试则更关注流水线切换的稳定性。

2.3 Camera Provider 进程模型

从 Android 8.0(O)开始,Camera HAL 以 Camera Provider 进程的形式独立运行,与 CameraService 通过 HIDL(Hardware Interface Definition Language)通信。这种架构提升了系统的稳定性和安全性。

2.3.1 进程模型架构

Camera Provider 进程模型包含以下关键组件:

  • CameraService:运行在 system_server 进程中,负责管理 Camera 设备生命周期和权限控制。
  • Camera Provider:独立的 HAL 进程,实现 ICameraProvider 接口,管理多个 Camera 设备。
  • Camera Device:每个物理 Camera 对应一个 ICameraDevice 实例,处理具体的 Capture 请求。
  • HIDL 接口:定义 CameraService 与 Provider 之间的通信协议,支持跨进程调用。
Camera Provider 进程模型架构 CameraService system_server 进程 HIDL 接口 (ICameraProvider / ICameraDevice) Camera Provider 独立 HAL 进程 Camera Device 0 主摄 Camera Device 1 广角 Camera Device 2 长焦 Provider 进程独立运行,即使崩溃也不会影响 system_server,提升了系统稳定性

2.3.2 进程隔离的优势

优势 说明
稳定性提升 HAL 进程崩溃不会导致 system_server 重启,仅影响 Camera 服务
安全性增强 HAL 进程运行在独立沙箱中,权限隔离,减少攻击面
资源管理 Provider 进程可独立管理内存和文件描述符,避免泄漏影响系统
多Camera支持 一个 Provider 可管理多个 Camera Device,支持多摄协同
热插拔支持 Provider 进程可动态检测 Camera 设备的插拔事件
测试注意:在测试多 Camera 兼容性时,需验证 Provider 进程能否正确枚举所有 Camera 设备,以及设备切换时是否会出现资源冲突或进程崩溃。建议使用 dumpsys media.camera 命令查看 Provider 状态。

2.3.3 关键 HIDL 接口

Camera Provider 进程模型依赖以下核心 HIDL 接口:

// ICameraProvider.hal
interface ICameraProvider {
    // 获取 Camera 设备列表
    getCameraIdList() generates (Status status, vec<string> cameraIds);

    // 打开指定 Camera 设备
    open(string cameraId, ICameraDeviceCallback callback)
        generates (Status status, ICameraDevice device);

    // 设置 Provider 回调
    setCallback(ICameraProviderCallback callback) generates (Status status);
};

// ICameraDevice.hal
interface ICameraDevice {
    // 配置输出流
    configureStreams(StreamConfiguration config)
        generates (Status status, HalStreamConfiguration halConfig);

    // 提交 Capture 请求
    processCaptureRequest(vec<CaptureRequest> requests,
                          vec<BufferCache> cachesToRemove)
        generates (Status status, uint32_t numRequestProcessed);

    // 关闭设备
    close() generates (Status status);
};
测试要点:验证 HIDL 接口的返回状态码是否正确,特别是 open() 和 configureStreams() 在异常场景下的错误处理。建议编写自动化测试用例覆盖所有接口的边界条件。