26、Camera兼容性：CDD要求、厂商定制、CTS兼容性问题、常见兼容性Bug、解决方案
说到Android相机的兼容性，这其实是个挺让人头疼的话题。我这些年经手过的项目里，至少有三分之一的时间都在跟各种兼容性问题死磕。你想想看，全球那么多厂商，每家都有自己的传感器、ISP、算法，还要保证同一个App在所有设备上表现一致——这本身就是个巨大的挑战。
今天我就把这块的内容掰开揉碎了讲清楚。咱们从CDD要求说起，再到厂商定制、CTS测试，最后聊聊那些常见的坑和怎么填坑。
CDD到底在要求什么？
CDD，全称是Compatibility Definition Document。说白了，它就是Google给所有Android设备厂商定的一套规矩。你如果不遵守，就别想用Google的GMS服务。
我印象很深，有一次我们团队为了赶项目进度，在Camera HAL层偷了个懒，没实现某个强制要求的功能。结果CTS一跑，直接挂了十几个case。嗯，从那以后我再也不敢小看CDD了。
CDD对相机的要求，主要集中在几个方面：
- 摄像头数量与类型：至少有一个后置摄像头，分辨率不低于某个阈值。我记得Android 13开始，对前置摄像头也有了更严格的要求。
- 图像质量：包括色彩还原、动态范围、噪点控制等。这些指标不是随便写的，Google有专门的测试工具来验证。
- 功能支持：比如自动对焦、闪光灯、视频录制等。有些功能是强制性的，有些是可选的。
- 性能要求：比如拍照延迟、连拍速度、视频帧率等。这些直接影响用户体验。
核心要点：CDD不是建议，是强制要求。厂商如果违反，轻则CTS不过，重则被取消GMS授权。我见过有厂商因为相机兼容性问题，导致产品延迟上市好几个月。
厂商定制：为什么总要改？
你可能会问，既然CDD已经规定得这么细了，厂商为什么还要做定制？原因其实很简单——差异化竞争。
每家厂商都想让自己的拍照效果看起来更牛。比如华为的徕卡色彩、小米的AI美颜、OPPO的超级夜景。这些功能都是基于Android Camera框架做的上层定制。
但问题来了，定制改得越多，出问题的概率就越大。我见过最夸张的一个案例，某厂商在Camera HAL里加了一个自定义的HDR算法，结果导致第三方App调用时直接闪退。为什么？因为HAL层没有处理好并发访问的问题。
厂商定制通常集中在以下几个层面：
- Camera HAL层：修改底层驱动、ISP调优、添加自定义算法
- Camera Service层：增加自定义的拍照模式、滤镜效果
- App层：开发自己的相机应用，替换系统默认相机
我个人习惯的做法是，尽量在App层做定制，少动HAL层。因为HAL层一旦改出问题，影响面太大了，所有依赖相机的App都会遭殃。
CTS兼容性问题：那些年我们踩过的坑
CTS，全称Compatibility Test Suite。它是Google用来验证设备是否符合CDD要求的测试套件。相机相关的CTS测试，可以说是整个CTS里最复杂的部分之一。
我随便列几个常见的CTS兼容性问题：
| 问题类型 | 具体表现 | 常见原因 |
|---|---|---|
| 分辨率不匹配 | CTS测试发现支持的尺寸与CDD要求不符 | HAL层上报的尺寸列表有遗漏 |
| 帧率不稳定 | 视频录制时帧率波动超过允许范围 | ISP驱动或HAL层性能问题 |
| 闪光灯同步问题 | 拍照时闪光灯与曝光不同步 | HAL层时序控制有bug |
| 3A算法异常 | 自动对焦、自动曝光、自动白平衡表现异常 | 算法参数调优不当 |
| 多摄像头切换失败 | 从主摄切换到广角时卡顿或黑屏 | HAL层流切换逻辑有缺陷 |
我记得有一次，我们遇到一个特别诡异的问题：CTS测试中有一个case要求连续拍照100次，每次都要成功。结果跑到第87次的时候，相机就挂了，再也打不开。查了三天才发现，是HAL层里有一个内存泄漏，每次拍照都泄漏一点点，累积到一定程度就崩了。
我的建议：CTS测试一定要早跑、勤跑。不要等到项目快结束了才跑，那时候发现问题就晚了。最好每次提交代码都跑一遍相机相关的CTS case，确保没有引入新的问题。
常见兼容性Bug及解决方案
下面我列几个我实际项目中遇到过的典型Bug，以及对应的解决方案。
Bug 1：第三方App拍照黑屏
现象：用户用微信或支付宝扫码时，相机画面黑屏，但系统相机正常。
原因：HAL层在处理CameraService的请求时，对某些参数组合处理不当。比如第三方App可能请求了一个不常见的预览尺寸，HAL层没有做fallback处理。
解决方案：在HAL层增加参数校验和fallback逻辑。如果请求的尺寸不支持，自动切换到最接近的可用尺寸。
// 伪代码示例
status_t CameraHAL::configureStreams(...) {
// 检查请求的尺寸是否支持
if (!isSizeSupported(requestedWidth, requestedHeight)) {
// 自动fallback到最接近的尺寸
findClosestSize(requestedWidth, requestedHeight, &actualWidth, &actualHeight);
// 更新配置
updateStreamConfig(actualWidth, actualHeight);
}
// 继续正常流程
return OK;
}
Bug 2：视频录制时音画不同步
现象：录制的视频播放时，声音和画面对不上，延迟越来越严重。
原因：音频和视频的时间戳没有对齐。音频走的是AudioFlinger，视频走的是Camera HAL，两个模块的时钟源不一致。
解决方案：统一使用同一个时钟源，或者在MediaCodec层面做时间戳校正。
注意：这个问题在低端芯片上特别常见。因为低端芯片的ISP和音频DSP可能没有共享同一个时钟域。我曾经在一个MTK平台上折腾了整整两周才搞定这个问题。
Bug 3：多摄像头切换时闪退
现象：从主摄切换到长焦或广角时，App直接崩溃。
原因：HAL层在切换摄像头时，没有正确处理流的销毁和重建。旧的流还没释放干净，新的流就开始创建了，导致资源冲突。
解决方案：在HAL层增加状态机管理，确保切换过程是原子操作。先销毁旧流，再创建新流，中间加一个锁保护。
// 伪代码示例
status_t CameraHAL::switchCamera(int newCameraId) {
Mutex::Autolock lock(mLock);
// 1. 停止所有正在进行的操作
stopAllStreams();
// 2. 销毁旧流
destroyStreams();
// 3. 释放旧摄像头资源
closeCameraDevice();
// 4. 打开新摄像头
openCameraDevice(newCameraId);
// 5. 创建新流
createStreams();
// 6. 启动流
startAllStreams();
return OK;
}
兼容性测试的最佳实践
说了这么多问题，最后聊聊怎么避免。我个人总结了几条经验：
- 尽早引入CTS测试：不要等到项目快结束了才跑CTS。最好在HAL层开发阶段就开始跑。
- 建立自动化测试流水线：每次代码提交都自动触发相机相关的CTS case。我习惯用Jenkins搭一套，跑完自动发报告。
- 关注Google的兼容性更新：每个Android版本都会更新CDD和CTS。比如Android 14对Ultra HDR有了新要求，如果你不做适配，CTS肯定过不了。
- 保留调试接口：在HAL层保留足够的log和调试接口。出了问题能快速定位，不用重新编译整个系统。
- 与芯片厂商保持沟通：很多兼容性问题其实是芯片厂商的BSP有bug。及时反馈给他们，能省不少事。
最后说一句：相机兼容性这件事，没有捷径可走。老老实实按照CDD来，认认真真跑CTS，遇到问题耐心排查。我见过太多项目因为赶进度而忽视兼容性，最后在认证阶段翻车的案例了。
这张图把整个Camera兼容性的知识体系串起来了。从顶层的CDD要求开始，到厂商定制、CTS测试，再到常见的Bug和解决方案，每一步都有对应的内容。你可以把它当作一个思维导图来用，遇到问题的时候，顺着这个脉络去排查，思路会清晰很多。