Google Play Internal App Sharing 安装报错 1010，如何排查？

仅凭 status error code 1010 和“无法下载”的提示，无法判断根因，也无法确认使用 production keys 损坏了分发配置。建议先检查同包名旧版本是否存在签名冲突，再通过全新安装和设备日志区分下载失败、安装失败与共享分发链路异常。

已查阅的相关官方文档没有说明这一场景下 1010 的根因。以下步骤用于定位问题，并非已确认的修复方案。

先确认签名机制，避免误判

Google Play 的 Internal App Sharing 允许上传使用不同密钥签名的 APK 或 AAB，随后会使用该应用的 Internal App Sharing 测试密钥重新签名。因此，上传前使用了 production keys，本身不足以解释后续的持续失败。Google Play 官方说明

Firebase App Distribution 分发 AAB 时，会借助 Google Play 的 Internal App Sharing 服务处理 AAB。Google Play 会使用测试密钥对生成的 APK 重新签名。这项说明适用于 AAB 分发流程，不能据此认为 Firebase 会对所有直接上传的 APK 重新签名。Firebase AAB 分发文档

这有助于分析两个现象：

• Firebase 的 AAB 分发与直接使用 Internal App Sharing 都失败，可能涉及共用的处理或安装环节，但还不足以认定 Google Play Store 出现故障。
• 相同 package name 的空项目仍然失败，只能降低原项目业务代码导致问题的可能性。包名对应的已安装应用、签名和分发配置仍可能影响结果。

1. 用没有安装过该包名的设备测试

优先选择一台没有安装过该应用的测试设备，使用新生成的 Internal App Sharing 链接安装。

如果只能使用现有设备，先备份需要保留的数据，再卸载同包名应用，并检查工作资料或其他用户空间是否也安装了它。卸载会删除相应应用的本地数据。

这一步用于区分首次安装失败和覆盖安装失败。Firebase 官方排查文档建议，在测试 APK 无法安装时，检查新版本与已安装版本的签名证书是否匹配。Firebase 安装问题排查

如果全新安装成功、覆盖旧版本失败，优先核对正式版本、直接分发的 APK 和 Internal App Sharing 版本之间的签名差异。如果全新安装仍失败，继续检查账号、链接和安装日志。

2. 检查测试账号与分享链接

在测试设备上逐项确认：

1. Google Play Store 已开启 Internal App Sharing。
2. 当前使用的 Google 账号具有下载权限；设备上有多个账号时，确认实际打开链接的账号。
3. 使用本次重新上传后生成的新链接，排除旧链接过期或达到下载人数上限。

官方文档说明，Internal App Sharing 链接在上传后 60 天过期，每个链接最多允许 100 名用户下载。拥有上传权限也不代表可以省略下载权限的检查。Internal App Sharing 权限与限制

如果此前所有设备使用的是同一账号或同一链接，那么所有设备失败仍可能有共同的账号或链接因素。

3. 获取底层安装错误

既然已经尝试过重启和清缓存，下一步可以记录失败发生的阶段。

电脑安装 Android SDK Platform-Tools，设备开启 USB 调试并授权连接后，在终端执行：

adb logcat -v time > play-install.log

保持命令运行，在设备上打开分享链接并重现故障，然后按 Ctrl+C 停止。检查故障时间附近与 PackageInstaller、PackageManager、Finsky、实际包名及 1010 相关的日志。不同系统和 Play Store 版本的日志内容可能不同，不一定能找到上述所有标记。

也可以在测试设备上，对本地构建的完整 APK 做一次对照安装：

adb install -r app.apk

这里的 app.apk 是示例文件名，需要替换成实际 APK 路径。-r 用于尝试保留数据并覆盖现有应用，不能绕过签名检查。

根据实际输出决定下一步：

• 如果提示签名或更新不兼容，核对已安装版本与待安装版本的证书。
• 如果提示 SDK、ABI 或包解析问题，检查构建产物与设备兼容性。
• 如果本地 APK 可以安装、分享链接仍失败，重点检查分享权限、Google Play 生成的安装产物及下载流程。

本地 APK 安装成功，只能验证该 APK 在当前设备上的安装情况，不能证明 Google Play 生成并重新签名的 APK 也一定正常。

4. 比较实际 APK 的签名证书

如果能够取得待比较的 APK，可以使用 Android SDK Build Tools 中的 apksigner 查看证书：

apksigner verify --verbose --print-certs app.apk

该命令用于验证 APK 签名并输出证书信息，不用于直接验证 AAB。比较时要标清文件来源，尤其要区分本地 APK、设备上已有的版本和 Google Play 处理后的测试 APK。apksigner 官方文档

本地上传文件的证书不能代表 Google Play 重新签名后交付给设备的证书。

5. 用对照结果决定是否提交支持请求

建议保留同一个最小项目，分别记录以下结果：

对照结果可以帮助缩小排查范围。例如，两种 AAB 分发方式都失败而本地 APK 正常，提示应进一步检查共用链路，但不能直接判定是服务端故障。

如果已验证新链接、授权账号和全新安装，仍能稳定复现，可以向 Google Play 开发者支持提交包名、上传时间、分享链接、设备及系统版本、Play Store 版本和失败日志。若故障只出现在 Firebase 流程，再向 Firebase 支持补充项目与分发信息。

目前没有证据表明继续删除 Firebase 项目或更换生产密钥能解决问题。取得安装日志和对照结果后，再判断应修改应用、调整分发配置，还是交由平台支持调查。

备注：内容仅供参考。