4. Camera CTS测试套件
Camera CTS（Compatibility Test Suite）是 Android 兼容性验证体系中最贴近“成像质量与相机行为一致性”的部分。它并不只验证相机能否打开，而是从 API 行为、图像数据格式、帧率、曝光、对焦、闪光灯、多摄切换、权限与生命周期等维度，确认设备在 Android 兼容性定义文档（CDD）约束下具备可预测的相机能力。理解 CTS Camera 模块的组织方式、用例分类与执行流程，是搭建稳定验证环境的前提。
一、CTS Camera 测试模块的组成
CTS 中的 Camera 相关测试主要分布在 android.hardware.camera2.cts、android.hardware.camera2.cts.helpers、android.hardware.camera.cts 以及 android.hardware.camera2.params.cts 等包中。它们共享一套底层辅助类，例如 CameraTestUtils、Camera2TestUtils、ImageReaderListener 与 CameraIterationRule，用于枚举相机、打开设备、配置会话、抓帧并校验元数据。
从测试对象看，Camera CTS 模块可归纳为四层：
- API 契约层：验证 CameraManager、CameraDevice、CameraCaptureSession、CaptureRequest 等公开 API 的返回值、异常与状态机行为。
- 能力声明层：通过 CameraCharacteristics 校验设备声明的能力是否与 CDD 要求一致，例如支持的硬件级别、输出格式、帧率范围、镜头朝向。
- 数据通路层：验证 ImageReader、Surface、MediaCodec 等输出路径中图像格式、时间戳、行距、色彩空间是否正确。
- 场景行为层：覆盖自动曝光、自动对焦、闪光灯、变焦、多摄逻辑相机等真实拍摄场景下的行为一致性。
二、测试用例分类与典型断言
Camera CTS 用例数量庞大，按验证目标可分为以下几类。下表给出分类、代表用例与核心断言，便于在失败时快速定位问题域。
| 用例分类 | 代表测试 | 核心断言 |
|---|---|---|
| 设备枚举与打开 | CameraManagerTest、CameraDeviceTest | 相机 ID 列表非空、打开回调在超时内返回、重复打开被拒绝 |
| 能力与元数据 | CameraCharacteristicsTest | 硬件级别、可用格式、帧率范围与 CDD 声明一致 |
| 会话与请求 | CameraCaptureSessionTest | 会话配置成功、请求序列按序回调、abort 后状态正确 |
| 图像数据 | ImageReaderTest、ImageFormatTest | YUV/RGB 数据尺寸、行距、时间戳单调递增 |
| 3A 与场景 | AutoExposureTest、AutoFocusTest、FlashTest | AE 收敛、AF 锁定、闪光灯触发与预闪时序正确 |
| 多摄与逻辑相机 | LogicalCameraTest、MultiCameraTest | 物理相机映射、切换延迟、同步帧时间戳对齐 |
这些用例大多依赖真实传感器或可注入的虚拟相机。若设备没有对应硬件，测试会通过 Assume 机制跳过，而不是直接失败。因此，阅读 CTS 结果时必须区分 pass、fail 与 assumption failure，后者通常表示设备未声明该能力，属于预期跳过。
三、测试环境搭建
Camera CTS 对环境的稳定性要求高于普通 API 测试。推荐使用一台经过 CTS 认证的 host 机、一台被测设备（DUT）以及稳定的 USB 连接。DUT 需刷入与 CTS 版本匹配的 userdebug 或 user 构建，并关闭屏幕锁、保持常亮、关闭自动旋转与省电模式。
# 1. 下载并解压 CTS 包
unzip android-cts-14_r1.zip -d ~/cts
# 2. 进入 CTS 根目录
cd ~/cts/android-cts
# 3. 确认设备连接
adb devices
# 输出应包含 DUT 序列号且状态为 device
# 4. 运行 Camera 模块
./tools/cts-tradefed
run cts -m CtsCameraTestCases --abi arm64-v8a
执行前建议完成以下准备：
- 使用
adb shell settings put system screen_off_timeout 2147483647保持屏幕常亮。 - 关闭
Stay awake之外的省电策略，避免相机被系统限频。 - 确保设备存储空间充足，Camera CTS 会产生大量临时图像文件。
- 若测试多摄，需确认所有物理相机均未被其他应用占用。
四、执行流程与结果分析
一次完整的 Camera CTS 执行可抽象为“准备—枚举—执行—收集—判定”五个阶段。下图展示从 host 到 DUT 的测试信号与数据流，帮助理解各阶段中测试框架、相机服务与传感器之间的交互关系。
执行时，cts-tradefed 会先通过 adb 将测试 APK 推送到 DUT，再按模块启动 instrumentation。每个测试用例在独立进程中运行，避免相机资源残留影响后续用例。若某个用例失败，框架会保存 logcat、dmesg 与截图，路径通常位于 ~/cts/android-cts/results/<时间戳>/。
# 查看失败用例详情
list results
# 查看某次会话的失败项
run cts -m CtsCameraTestCases --retry 3
# 导出结果
./tools/cts-tradefed
> list results
> exit
五、常见误区与复盘要点
复盘时建议按以下顺序排查：
- 确认失败用例属于哪个分类，是 API 契约、能力声明、数据通路还是场景行为。
- 检查
CameraCharacteristics中相关键值是否与硬件规格书一致。 - 查看 logcat 中 CameraService 与 HAL 的报错，定位是配置失败、超时还是数据校验失败。
- 若为 assumption failure，确认设备是否真的未声明该能力，避免误判为缺陷。
- 在稳定光源与固定机位下复测，排除环境波动导致的偶发失败。
掌握 Camera CTS 的模块划分、用例分类与执行链路后，就能把“跑不过”转化为“定位到具体能力或数据通路问题”。下一阶段可结合 VTS 中的 Camera HAL 测试，进一步验证 vendor 实现与 AIDL/HIDL 接口的一致性。