如何测试Google Play File-by-File patching逐文件更新功能

1. 如何测试、复现File-by-File patching的运行效果 #

• 先做本地前置校验：用Google开源的archive-patcher工具，对本地两个同签名的正式打包APK做离线补丁生成测试。如果本地生成的补丁体积和完整APK差不多，先调整打包配置：比如固定每次构建的Build ID、关闭不必要的全量资源/DEX重排规则，这类每次构建全量修改文件的配置会直接导致补丁失效。
• 线上复现操作：
  • 测试用的旧版本、新版本必须都是通过Google Play商店分发的版本，不要用本地adb安装的自行打包版本——Google会对上传的包做zipalign对齐、重签名处理，本地原始包和服务端处理后的包结构存在差异，不可能触发补丁。
  • 在测试机上先装好Play分发的旧版本，打开Play商店进入应用详情页，看页面标注的更新包大小，如果数值远小于完整APK体积，触发更新后下载的就是补丁包。
  • 注意只有覆盖更新场景才会触发补丁，首次安装应用永远下发全量包。

2. Google为应用启用该技术的具体条件 #

• 逐文件补丁、增量补丁是Google Play默认给所有应用开启的基础能力，和应用下载量、测试账号数量、上线时长没有任何关联，不存在小体量应用、测试阶段应用不给开通的规则。
• 补丁不生成、不下发的常见原因：
  • 新旧版本应用签名不一致，或开启Play App Signing后，本地测试用的包签名和Google托管的应用签名不匹配
  • 服务端计算后发现补丁包体积超过全量包体积的60%，出于分发效率考虑会直接放弃补丁，下发全量包
  • 新旧版本的分包规则差异过大：比如调整了ABI拆分、屏幕密度拆分规则，或新增/移除了大量动态功能模块，导致逐文件匹配的收益过低
  • 新版本刚上传不久，服务端还没完成补丁计算，会临时下发全量包过渡。

3. 测试阶段是否可以观测到该功能的实际生效状态 #

• 内部测试、封闭测试轨道均完整支持补丁能力，完全可以在测试阶段观测生效状态，常用观测方式：
  • 客户端侧：测试机安装Play分发的旧版本后，打开Play商店进入应用详情页，页面展示的更新下载大小如果远小于Play Console上标注的该版本完整APK大小，说明补丁已经生效
  • 控制台侧：进入Play Console的「应用大小」统计板块，选定对应测试轨道、对应版本，查看「覆盖更新平均下载大小」指标，如果该数值远小于完整APK体积，说明补丁已经生成并正常分发
  • 抓包侧：抓取测试机上Play商店的更新请求，如果请求的资源类型为patch而非完整apk，说明补丁正在下发
• 注意：新版本上传到测试轨道后，服务端一般需要12-24小时完成所有历史版本对应的补丁计算，上传后几小时内触发更新默认下发全量包，不属于功能异常，等计算完成后会自动切换为补丁分发。

内容的提问来源于stack exchange，提问作者SmirnovDV