26、兼容性定义文档（CDD）：CDD条款解读，如何根据CDD制定升级计划

做Android系统升级，最怕什么？

我最怕的是：升级完了，结果某个核心功能在用户手机上跑不起来。不是技术没做到，而是压根没注意到Google在CDD里埋的那个「小细节」。

CDD，全称是Compatibility Definition Document。说白了，它就是Google给所有Android设备厂商定的一套「及格线」。你达不到，就别想用Google的GMS服务。我见过不少团队，一上来就闷头改代码，结果改到一半发现某个API行为不符合CDD要求，只能推倒重来。嗯，这种坑，踩一次就够了。

CDD到底是什么？

CDD是一份文档，它定义了Android设备必须满足的软硬件要求。每个Android版本都有对应的CDD。比如Android 14的CDD，就规定了设备必须支持哪些传感器、屏幕分辨率下限是多少、多窗口模式该怎么实现等等。

我个人习惯把CDD分成三大块：

• 硬件兼容性：屏幕、摄像头、GPS、NFC这些硬件的规格要求
• 软件兼容性：API行为、权限模型、后台限制这些系统层面的约束
• 多媒体兼容性：编解码器、DRM、音频延迟这些跟媒体相关的条款

如何解读CDD条款？

CDD文档很长，动辄上百页。你不可能逐字逐句读完。我一般只看三类条款：

1. MUST条款

这是硬性要求。比如「设备必须支持A2DP蓝牙音频协议」。没得商量，必须实现。

我在项目中遇到过，某个低端平板为了省成本，砍掉了A2DP的硬件支持。结果CTS测试直接挂掉，最后不得不加回这颗芯片。嗯，省了小钱，赔了大时间。

2. SHOULD条款

这是推荐要求。比如「设备应该支持Wi-Fi Direct」。你可以不做，但做了会加分。不过要注意，有些SHOULD条款在CTS里其实是必测项。我建议你把它当MUST处理，省得后面补坑。

3. MAY条款

这是可选要求。比如「设备可以支持指纹识别」。这个就真的看产品定位了。

根据CDD制定升级计划

升级计划不是拍脑袋定的。你得先搞清楚：当前设备离CDD要求还差多远。

我一般分四步走：

1. 差距分析：把当前设备的硬件参数、软件版本、驱动版本列出来，跟CDD逐条比对。这一步最枯燥，但也最重要。
2. 风险分级：把差距项分成高、中、低三档。高风险的是那些必须改硬件才能解决的，比如缺少某个传感器。中风险的是需要改驱动或HAL层的。低风险的是改改配置就能过的。
3. 制定里程碑：高风险项优先处理，放在第一个里程碑。中风险项放在第二个。低风险项穿插进行。
4. 预留缓冲期：我建议至少留出2周的CTS回归测试时间。因为CTS跑一轮就要好几个小时，挂了还得修，修完再跑。这个循环很耗时间。

一个真实的CDD升级案例

我记得有一次，我们要把一款老设备从Android 11升级到Android 13。Android 13的CDD新增了一条：所有设备必须支持AV1视频解码。

我们当时用的SoC是几年前的老芯片，硬件上根本不支持AV1。怎么办？

方案有两个：

• 换SoC，成本太高，周期太长
• 用软件解码，但性能堪忧

最后我们跟Google沟通，确认了这款设备属于「低性能设备」类别，可以豁免AV1硬件解码要求，但必须用软件解码兜底。嗯，这个细节在CDD的脚注里其实有写，只是很多人没注意到。

所以你看，CDD不是死板的。它有一些例外条款和豁免条件。关键是你得读得够细。

CDD升级计划模板

下面是我自己常用的一个计划模板，你可以参考：

阶段	任务	预计耗时	输出物
第1周	CDD差距分析	5天	差距分析报告
第2-3周	高风险项修复	10天	修复后的系统镜像
第4-5周	中风险项修复	10天	修复后的系统镜像
第6周	CTS初步测试	5天	CTS测试报告
第7-8周	问题修复+回归测试	10天	最终通过CTS

CDD升级的核心逻辑图

下面这张图，是我自己总结的CDD升级决策流程。你照着走，基本不会漏掉关键步骤。

这张图的核心逻辑是：先分析差距，再分级风险，然后决定是改硬件还是改软件，最后用CTS验证。如果CTS没过，就回到修复阶段继续改。这个循环可能会跑好几轮，别急，正常。

最后说几句

CDD这个东西，说白了就是Google给你划的「跑道」。你可以在跑道内自由发挥，但别越界。越界了，GMS就没了，用户就跑了。

我见过太多团队，把CDD当成「参考文档」，随便翻翻就扔一边了。结果呢？CTS跑不过，项目延期，老板骂人。何必呢？

我的建议是：把CDD当成你的「圣经」。每次升级前，先读一遍。读不懂的地方，去查CTS的测试用例。还搞不懂，就去AOSP的邮件列表问。别自己瞎猜。

嗯，今天就聊到这儿。记住一句话：CDD不是束缚，是保护。它保护你的设备不会变成「Android碎片」的一部分。

---