📚 课程目录第2章 Android Camera基础

2. Android Camera基础

要理解 Camera CTS/VTS 验证，必须先建立一条完整的“成像链路”认知：从镜头与传感器采集光子，到 ISP 处理成帧，再经 HAL 抽象、CameraService 调度，最终由 Camera2 API 或 CameraX 交付给应用。CTS 与 VTS 的测试点，正是沿着这条链路逐层分布的——VTS 关注 HAL 与内核接口，CTS 关注 API 行为与图像质量。本节把这条链路拆成硬件、HAL、系统服务、应用框架四层来讲。

一、Camera 硬件架构：从光子到 YUV 的物理通路

一个典型的 Android 手机 Camera 硬件子系统由以下部件构成：镜头组（Lens）、红外截止滤光片、图像传感器（Sensor，CMOS 为主）、马达（VCM/AF）、闪光灯（Flash/Torch）、以及 SoC 内部的 ISP（Image Signal Processor）与 Camera 控制器。Sensor 负责光电转换，输出 Bayer RAW 数据；ISP 完成黑电平校正、去马赛克、白平衡、色彩校正、伽马、降噪与锐化，最终输出 YUV 或 JPEG。

关键参数决定了 CTS 图像质量测试的判据：

分辨率与像素阵列：决定最大输出尺寸，影响 ITS（Image Test Suite）场景的选型。
帧率（fps）：与曝光时间、读出带宽耦合，是 CTS 帧率一致性测试的核心。
曝光/增益（Exposure/Gain）：由 Sensor 寄存器控制，VTS 会校验 HAL 上报的曝光参数是否与实际生效一致。
卷帘快门（Rolling Shutter）：导致运动畸变，是 ITS 运动模糊测试的诱因。
MIPI CSI-2 通道：Sensor 到 SoC 的高速串行接口，带宽不足会直接掉帧。

下图给出 Camera 从硬件到应用框架的分层数据流与各层对应的验证归属，可帮助建立“哪一层出问题、由哪套测试暴露”的定位直觉。

二、HAL 层：Camera 的“驱动契约”

Android 8.0 之后，Camera HAL 统一为 HAL3 接口，核心是三个结构体：camera_module_t（模块入口）、camera3_device_ops_t（设备操作函数表）、以及 request/result/notify 三套回调。HAL 的职责是把上层下发的 CaptureRequest 翻译成 Sensor/ISP 寄存器操作，并把采集结果与元数据回传。

HAL3 的关键机制是“请求-结果”流水线：应用提交 request，HAL 返回 result 与 metadata，同时通过 notify 上报 shutter、error 等异步事件。VTS 的 VtsHalCameraProviderV2_4TargetTest 等用例，正是直接调用这些 HAL 接口，校验参数合法性、流配置能力与错误处理行为。

// HAL3 关键接口（简化）
camera_module_t {
    common: hw_module_t,
    get_number_of_cameras(),
    get_camera_info(),
    set_callbacks(),
    open(),
}

camera3_device_ops_t {
    initialize(),
    configure_streams(),
    process_capture_request(),
    flush(),
}

// 一次请求的元数据示例
ANDROID_SENSOR_EXPOSURE_TIME = 10000000  // 10ms
ANDROID_SENSOR_SENSITIVITY   = 400       // ISO
ANDROID_CONTROL_AE_MODE      = ON

HAL 版本与 Treble 化：Android 8.0 起 Camera HAL 运行在独立进程（android.hardware.camera.provider@2.4-service），通过 HIDL/AIDL 与 CameraService 通信。VTS 测试的就是这个跨进程接口的稳定性与兼容性。

三、Camera2 API：面向应用的能力模型

Camera2 是 Android 5.0 引入的应用层相机框架，取代了旧的 Camera1。它把相机抽象为“设备 + 会话 + 请求”三层：CameraManager 枚举设备，CameraDevice 打开设备，CameraCaptureSession 建立输出流，CaptureRequest 描述单帧参数。Camera2 的核心价值在于把 3A、曝光、对焦、输出格式等全部暴露为可编程的 metadata 键值。

Camera2 的能力通过 CameraCharacteristics 暴露，例如 REQUEST_AVAILABLE_CAPABILITIES 决定设备是 LEGACY、LIMITED、FULL 还是 LEVEL_3。CTS 的 Camera2Test 会逐项校验这些能力声明与实际行为是否一致——声明了 FULL 却无法输出 RAW，就是典型的 CTS 失败。

四、CameraX 与系统服务：工程化封装与调度中枢

CameraX 是 Jetpack 库，基于 Camera2 封装，提供 Preview、ImageCapture、ImageAnalysis、VideoCapture 四类 UseCase，自动处理生命周期、旋转、分辨率适配与设备兼容性。它降低了应用开发门槛，但底层仍走 Camera2 → CameraService → HAL 的同一链路，因此 CameraX 的兼容性问题往往最终定位到 HAL 或系统服务。

CameraService 是 Native 层的调度中枢，负责设备枚举、权限校验、多应用抢占仲裁、流配置与 buffer 管理。当多个应用同时请求相机时，CameraService 依据优先级与前台状态决定谁获得设备，这正是 CTS 多任务场景测试的重点。

层级	核心对象	主要职责	对应验证
硬件层	Sensor / ISP / MIPI	光电转换、图像处理、数据传输	ITS 图像质量、帧率
HAL 层	camera3_device_ops_t	请求翻译、流配置、元数据回传	VTS HAL 接口测试
系统服务层	CameraService	设备管理、权限、冲突仲裁	CTS 多任务与权限
应用框架层	Camera2 / CameraX	API 暴露、UseCase 封装	CTS Camera2Test

五、典型场景与常见误区

场景：某设备 CTS Camera2Test#testCapabilities 失败，日志显示声明了 MANUAL_SENSOR 但设置曝光时间后帧亮度无变化。定位路径应为：先确认 Camera2 层 request 是否携带 SENSOR_EXPOSURE_TIME，再抓 HAL 层 metadata 看是否透传，最后查 Sensor 驱动是否真正写入寄存器。这条链路正是本节分层图的价值所在。

常见误区：把 CameraX 当作独立于 Camera2 的“另一套相机”。实际上 CameraX 是 Camera2 的上层封装，CameraX 的 bug 常常是 Camera2 或 HAL 问题的表象。排障时应自下而上验证，而不是只在应用层反复改代码。

误区一：认为 HAL 只是“驱动”，忽略其 metadata 契约的严格性。
误区二：混淆 LEGACY 与 LIMITED 能力等级，导致 CTS 能力断言失败。
误区三：忽略 CameraService 的多应用仲裁，误判为 HAL 崩溃。
误区四：只看 API 返回值，不校验实际图像输出，漏掉 ISP 侧问题。