Play Store及自发布通用APK签名密钥升级方案确认与疑问

方案理解验证 #

你的三个方案理解基本准确，补充细节如下：

• 方案1（自行管理密钥）：生成新密钥后创建新旧密钥的旋转谱系，发布时同时用旧密钥做v1/v2签名、新密钥结合谱系做v3签名，这样单APK既能被Play Store接受，也能作为通用APK分发，满足所有用户的升级兼容需求——Android 9+设备会识别v3签名的旋转信息，接受新密钥的验证；旧设备则通过v1/v2签名的旧密钥完成验证。
• 方案2（App Signing+新安装密钥升级）：上传旧密钥启用App Signing后，申请针对新安装的密钥升级，审批通过后Play Store会为新安装用户分发新密钥签名的APK，现有用户更新仍用旧密钥签名的版本。但自发布APK必须添加v3旋转谱系签名，否则现有用户无法通过自发布APK升级，且该申请的审批结果确实存在不确定性。
• 方案3（App Signing+Android 13+密钥升级）：启用App Signing后申请针对Android 13+的密钥升级，Play Store会自动为Android 13+设备分发新密钥签名的APK，其他设备仍用旧密钥版本。自发布APK需要加入v3.1的SDK定向签名信息，才能让单APK同时兼容新旧设备的验证逻辑。

自行管理密钥+v3旋转的潜在问题 #

继续自行管理密钥并使用v3方案旋转不存在功能层面的障碍，但需注意两点风险：

• 密钥安全风险：新旧密钥的存储、备份完全由团队自行负责，一旦密钥泄露或丢失，无法借助Google Play的恢复机制补救，会直接导致应用无法发布更新，甚至失去应用的控制权。
• 签名配置复杂度：需要确保签名流程同时保留旧密钥的v1/v2签名、新密钥的v3签名，任何配置失误都可能导致部分设备无法验证APK，引发升级失败问题。

v3.1与Play Console文档的矛盾说明 #

你提到的Android 13发布说明中v3.1支持单APK多签名者及SDK定向，与Play Console文档的差异，本质是两者的作用层面不同：

• v3.1的SDK定向是APK自身的签名特性，允许单APK包含多个签名者，并指定每个签名者对应的最低系统版本，从而实现单APK兼容不同密钥的验证；
• Play Console的密钥升级方案是谷歌分发层面的逻辑，谷歌会根据设备系统版本分发不同签名的APK包，而非直接支持单APK通过v3.1特性实现全版本兼容。目前Google Play App Signing尚未支持通过v3/v3.1旋转谱系实现全版本单APK的密钥升级，因此你理想中的“启用App Signing后单APK兼容所有版本升级”暂时无法实现。

内容的提问来源于stack exchange，提问作者Hélène Martin