Camera CTS 实战：从新手到主力的排查心法与典型问题解析

1. 初识Camera CTS：从慌张到入门的心路历程

第一次接到领导安排的Camera CTS测试任务时，我整个人都是懵的。作为刚接触这个领域的新人，面对两周内必须解决的deadline，那种压力至今记忆犹新。Camera CTS（Compatibility Test Suite）是Google为确保Android设备兼容性设计的测试套件，对于Camera模块而言，它验证的是设备是否符合Android相机API规范。刚开始接触时，最困扰我的是不知道从何处入手——测试环境怎么搭建？失败项如何定位？修改方案去哪里找？这些问题在初期就像一团乱麻。

记得第一次跑测试时，设备直接死机。当时手忙脚乱地抓取logcat和kernel log，花了整整一天才定位到是某个分辨率配置导致底层驱动崩溃。这个经历让我明白：CTS测试本质上是一个系统工程，需要同时了解Android框架层、HAL层甚至驱动层的交互逻辑。新手最容易犯的错误就是只盯着测试失败的表象，而忽视底层真正的root cause。比如有次遇到"Videosize xxx must be one of the camera device supported video size"报错，表面看是配置问题，实际根源是sensor输出能力与配置不匹配。

2. 典型问题排查框架：从log分析到解决方案

2.1 测试环境搭建与基础检查

在开始CTS测试前，确保环境正确配置能省去50%的麻烦。我总结的检查清单包括：

• 确认测试设备已解锁bootloader并开启USB调试
• 安装最新版CTS测试包（建议使用与项目基线匹配的版本）
• 检查设备存储空间（至少预留10GB）
• 配置正确的adb环境变量

常见的环境问题如测试过程中adb断开连接，可以通过adb reconnect命令快速恢复。更隐蔽的问题如GSI（Generic System Image）兼容性，需要特别注意vendor.img与system.img的版本匹配。有次测试MultiViewTest失败，最后发现是因为刷了GSI后某些vendor特性被覆盖导致的。

2.2 高频错误类型与解决策略

2.2.1 配置类问题

这类问题通常表现为AssertionFailedError，解决方案往往涉及修改配置文件。例如：

xml复制<!-- 示例：解决SystemFeatureTest失败 -->
<feature name="android.hardware.camera"/> <!-- 注释掉这行 -->

关键是要知道去哪里修改这些配置。Android 10之后，相机相关配置主要分布在：

• /vendor/etc/camera/：厂商自定义配置
• /system/etc/permissions/：系统特性声明
• /vendor/build.prop：设备特性参数

2.2.2 算法干扰问题

当测试项突然在某个版本开始失败，很可能是新引入的算法导致的。例如ZoomCaptureTest失败，最终定位是某个降噪算法影响了原始数据流。快速验证方法是：

bash复制adb shell setprop vendor.camera.xxx.disable 1 # 临时关闭特定算法

确认问题后，需要在HAL层永久修改算法开关逻辑，或者通过tuning参数调整算法行为。

2.2.3 分辨率与性能问题

媒体性能类测试（如CtsMediaPerformanceClassTestCases）对相机分辨率有硬性要求。曾遇到前置摄像头分辨率不达标的问题，解决方案是修改init脚本：

rc复制# 在init.qti.qcv.rc中移除media_performance_class设置
# setprop ro.odm.build.media_performance_class ${ro.vendor.media_performance_class}

这类问题需要特别注意：修改后必须重启设备才能生效。

3. 进阶调试技巧：从表象到本质的深度分析

3.1 源码级问题定位

当标准解决方案无效时，就需要深入分析测试用例和框架源码。以RobustnessTest为例，通过阅读SessionConfigurationUtils.cpp发现：

cpp复制// 关键代码段：查找支持的size列表
if (!maxSize) {
    maxSize = getMaxSize(configs); // 缺少参数导致错误匹配
}

这种问题需要同时修改framework和HAL层代码，并考虑GSI场景下的兼容性。我的经验是：CTS问题越复杂，越需要建立完整的分析链路——从测试日志到CTS源码，再到HAL实现，最后到驱动行为。

3.2 传感器与光学问题

AeCompensation这类测试项直接涉及传感器物理特性。通过分析camxcaecstatsprocessor.cpp，我理清了曝光补偿的计算逻辑：

code复制linearGain = Again * Dgain
sensitivity = (sensorgain/ISO100Gain)*100

这类问题需要联调算法、驱动和tuning团队。关键技巧是：

1. 使用camxoverridesettings.txt强制参数
2. 通过adb shell dumpsys media.camera验证参数生效
3. 在HAL层添加调试日志输出原始传感器数据

3.3 多模块协同问题

MultiViewTest这类涉及多个pipeline的测试项，最容易出现各模块数据不一致的情况。解决方案通常是：

xml复制<!-- 修改pipeline配置使不同port使用相同数据源 -->
<Port name="Display" srcPort="Video"/>

实际操作中还需要考虑内存带宽限制，有时需要降低中间buffer的分辨率来避免性能瓶颈。

4. 团队协作与经验沉淀

4.1 问题跟踪与知识管理

建立CTS问题知识库能极大提升团队效率。我创建的模板包含：

• 问题现象（测试项、错误日志）
• 根因分析（调用栈、数据流图）
• 解决方案（代码修改、配置变更）
• 验证方法（测试命令、预期结果）
• 关联案例（类似问题的参考链接）

4.2 GSI/GTS专项处理

面对GSI测试的特殊性，我总结出以下模式：

cpp复制// HAL层检测是否运行在GSI环境
bool isGSI = !property_get_bool("ro.vendor.qti.va_aosp.support", false);

对于GTS问题，高通通常会提供补丁文件，应用方法如：

bash复制cd /path/to/qssi
git apply /path/to/gts_patch.patch

4.3 性能优化技巧

长期运行CTS测试时，这些技巧可以节省时间：

• 使用--shard-count参数并行执行测试
• 通过--skip-preconditions跳过重复的环境检查
• 修改cts-tradefed脚本增加日志详细级别
• 编写自动化脚本批量分析日志文件

从新手到主力的成长过程中，最深的体会是：CTS问题没有标准答案，但存在通用方法论——建立完整的分析链路，保持对细节的敏感，养成系统化思考的习惯。每次解决问题的过程，都是对Android相机架构理解加深的机会。