CTS测试camera特性枚举与HAL功能验证 - 第2节

2.1 Android Camera HAL3 架构总览

Android Camera HAL3 是 Android 系统相机子系统的核心硬件抽象层,自 Android 5.0(Lollipop)起成为标准架构。它取代了 HAL1 的固定管线模型,采用 请求-响应(Request-Response) 模型,允许应用层精细控制每一帧的捕获参数(曝光、增益、对焦、白平衡等),并支持多路并发流(预览、拍照、视频、YUV/RAW 回传)。

核心设计目标: 将 ISP(图像信号处理器)的硬件能力以标准化的 Capabilities 和 Metadata 暴露给上层,使 CTS 测试能够枚举特性边界,验证 HAL 实现的完整性与正确性。

2.1.1 HAL3 分层架构

HAL3 架构从底层到上层分为三个关键层次:

层次 组件 职责 CTS 关注点
HAL 接口层 camera3_device_t / camera3_ops_t 定义设备打开、关闭、配置流、提交请求、获取结果等标准函数指针 验证所有必须的 ops 是否非空,函数签名是否匹配
Camera Provider 服务层 ICameraProvider / ICameraDevice (HIDL/AIDL) 进程间通信(IPC)桥接,将 HAL 接口封装为系统服务 枚举 Provider 暴露的 Camera ID,验证服务存活与版本
Camera Service 框架层 CameraService / CameraDeviceClient 管理权限、策略、多客户端并发,调用 HAL 接口 验证特性枚举结果与 HAL 实际能力一致
CTS 测试要点: 在 android.hardware.camera2.cts.CameraCharacteristicsTest 中,测试用例会遍历所有 REQUEST_AVAILABLE_CAPABILITIES 枚举值,并逐一调用 HAL 的 get_metadata_vendor_tag_ops 和 construct_default_request_settings 验证返回值是否符合规范。

2.1.2 HAL3 请求-响应数据流

下图展示了从应用层提交 CaptureRequest 到 HAL 返回 CaptureResult 的完整数据流:

HAL3 请求-响应数据流 应用层 CameraService CameraProvider HAL 实现 CaptureRequest HIDL/AIDL process_capture_request CaptureResult (Metadata + Buffer) HAL 内部处理管线 Sensor 配置 ISP 处理 3A 统计 输出 Buffer CTS 验证点:检查每一帧的 Metadata 是否包含预期的 Tag 和有效值

2.2 HAL 接口定义详解

2.2.1 camera3_device_ops_t 核心接口

HAL3 的核心接口定义在 hardware/libhardware/include/hardware/camera3.h 中。以下是最关键的 5 个函数指针,CTS 测试会逐一验证其行为:

函数指针 调用时机 CTS 验证项
initialize 设备打开后立即调用 检查返回的 camera3_callback_ops_t 是否非空
configure_streams 配置输出流(预览/拍照/录像) 验证支持的流组合、分辨率、格式是否与静态信息一致
construct_default_request_settings 构建默认请求模板 检查返回的 Metadata 是否包含所有必须的 Tag
process_capture_request 提交捕获请求 验证请求的 input_buffer 和 output_buffers 处理逻辑
flush 清空所有待处理请求 验证是否在 1000ms 内返回所有未完成的 Buffer
常见 CTS 失败原因: construct_default_request_settings 返回的 Metadata 中缺少 ANDROID_CONTROL_AE_MODE、ANDROID_SENSOR_EXPOSURE_TIME 等强制 Tag,或者返回了超出 ANDROID_SENSOR_INFO_SENSITIVITY_RANGE 范围的增益值。

2.2.2 Metadata 标准 Tag 分类

HAL3 使用 camera_metadata_t 传递所有控制参数和结果信息。CTS 测试通过 CameraMetadataNative 解析 Tag,并验证其类型、计数和取值范围。以下为关键 Tag 分类:

  • 控制类(android.control.*): AE/AWB/AF 模式、目标帧率、场景模式、效果模式。
  • 传感器类(android.sensor.*): 曝光时间、灵敏度(ISO)、帧持续时间、温度。
  • 镜头类(android.lens.*): 光圈、焦距、光学防抖模式、对焦距离。
  • 统计类(android.statistics.*): 人脸检测结果、3A 统计数据、镜头阴影校正。
  • 输出类(android.jpeg.* / android.tonemap.*): JPEG 质量、色调映射曲线、锐度。

2.3 CameraProvider 服务

2.3.1 服务架构与版本

CameraProvider 是 Android Treble 架构引入的 HAL 封装层,将 Camera HAL 实现从 cameraserver 进程中解耦,运行在独立的 vendor 分区进程中。它通过 HIDL(Android 8~10)或 AIDL(Android 11+)接口与 CameraService 通信。

CameraProvider 服务架构 系统分区 (System) CameraService CameraDeviceClient HIDL / AIDL IPC 供应商分区 (Vendor) CameraProvider HAL 实现 CameraDevice

2.3.2 ICameraProvider 接口定义

CameraProvider 的核心接口定义在 android/hardware/camera/provider/2.4/ICameraProvider.hal(HIDL 版本)或 ICameraProvider.aidl(AIDL 版本)中。关键方法如下:

// HIDL 接口示例 (provider/2.4)
interface ICameraProvider {
    // 返回该 Provider 管理的所有 Camera 设备 ID 列表
    getCameraIdList() generates (Status status, vec<string> cameraIds);

    // 根据 ID 创建 CameraDevice 接口
    getCameraDeviceInterface(
        string cameraId
    ) generates (Status status, ICameraDevice device);

    // 设置回调,用于通知 CameraService 设备状态变化
    setCallback(ICameraProviderCallback callback) generates (Status status);

    // 查询 Provider 支持的版本信息
    getProviderVersion() generates (uint32_t major, uint32_t minor);
};
CTS 测试验证点: TestCameraProvider 测试用例会调用 getCameraIdList() 获取所有 Camera ID,然后对每个 ID 调用 getCameraDeviceInterface(),验证返回的 ICameraDevice 接口是否能够成功 open() 并返回有效的 camera3_device_t。

2.3.3 CameraProvider 注册与发现

CameraProvider 通过 LazyServiceRegistrar 或 hwservicemanager 注册到系统服务管理器中。CameraService 启动时,通过 waitForService() 发现所有已注册的 Provider 实例。CTS 测试通过 ServiceManager::listServices() 枚举所有 android.hardware.camera.provider 服务,验证其版本号是否符合设备预期。

Provider 版本 接口类型 Android 版本 CTS 测试类
2.4 HIDL 8.0 ~ 10 CameraProviderTest_2_4
2.5 HIDL 10 ~ 12 CameraProviderTest_2_5
2.6 HIDL 11 ~ 12 CameraProviderTest_2_6
AIDL AIDL 12+ CameraProviderAidlTest

2.4 特性枚举与 HAL 功能验证的关联

CTS 测试中,特性枚举 和 HAL 功能验证 是前后衔接的两个阶段:

  1. 枚举阶段: 通过 CameraCharacteristics 读取 REQUEST_AVAILABLE_CAPABILITIES、SCALER_AVAILABLE_STREAM_CONFIGURATIONS 等静态信息,建立设备能力清单。
  2. 验证阶段: 针对枚举出的每一项能力,构造对应的 CaptureRequest 提交给 HAL,检查返回的 CaptureResult 是否满足规范要求。
示例: 如果枚举阶段发现 ANDROID_REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE 为 true,则验证阶段必须测试 android.control.aeMode 从 ON 切换到 OFF 时,HAL 是否能够正确返回手动曝光时间。

这种“枚举-验证”闭环机制确保了 CTS 测试的全面性:任何 HAL 实现声称支持的特性,都必须通过对应的功能测试用例。如果枚举阶段漏报某项能力,对应的测试用例会被跳过;如果虚报能力但验证失败,则直接导致 CTS 失败。