同包名不同签名场景下Google应用登录返回错误码10的问题咨询

• 已上架Google Play的Android应用，此前已完成Firebase邮箱认证接入，存量用户基于该认证体系正常运行；本次迭代新增Google账号登录能力
• Debug构建模式下，Google Sign-In全流程测试功能完全正常
• 使用自有密钥生成签名Release包上传为新版本，从Google Play渠道下载正式版验证时，Google登录返回Google SignIn Fails提示，对应错误码10；现有公开排查资料均指向SHA1配置异常
• 卸载Play渠道正式版后，从Android Studio直接运行Debug版本，首次启动弹出应用安装失败提示
  
• 确认接受系统弹出的提示授权后，Debug包的Google SignIn功能恢复正常
• 尝试将Play App Signing环节的SHA1值（05:FE:xx:xx:...:xx）添加到Firebase配置时，系统弹出报错：「该包名与SHA-1值的组合，已在其他项目中存在对应的OAuth2客户端」

疑问1：Firebase设置页配置的SHA证书与Android Studio signinReport中获取的SHA-1值一致，但与Google Play App Signing页面展示的SHA-1值不同，两组值是否需要保持一致？ #

• 两组值不需要强制完全相同，但必须全部纳入对应服务的信任列表
• Android Studio signinReport中查询到的SHA1，对应两类签名：本地Debug构建签名、应用上传到Play渠道时使用的上传密钥签名。该值目前已完成Firebase侧配置
• Google Play App Signing页面展示的独立SHA1，对应Play官方托管的、用于最终分发版本签名的应用签名密钥——用户从Play下载的正式安装包，都是使用该密钥重签名的版本，而非你本地生成的上传密钥直接签名的安装包
• Google Sign-In返回错误码10的本质原因，就是Google服务校验到当前安装包的签名SHA1不在OAuth客户端的信任列表中，直接拦截授权请求

疑问2：如何调整配置，在不破坏现有Firebase连接、不丢失存量用户的前提下修复问题？（可接受暂时停用Google SignIn的方案） #

• 以下操作全程不会影响现有Firebase连接、存量用户数据，所有调整仅针对Google登录的OAuth配置环节，不会触碰已有的邮箱认证用户体系：
  1. 完整保留Firebase中已有的、对应你本地/上传密钥的SHA1记录。该部分配置可保障开发环境、旧渠道安装包的Firebase能力正常，不会影响存量用户的邮箱认证登录
  2. 针对「SHA1已在其他项目存在OAuth2客户端」的报错，不要尝试在当前Firebase项目重复添加该SHA1。该报错本质是当前包名与Play应用签名SHA1的组合，在应用首次上传开启Play App Signing时，已自动在Google Cloud侧生成过OAuth2客户端条目
  3. 配置调整流程：
     • 定位与当前Firebase项目绑定的Google Cloud项目
     • 在凭据板块的OAuth2客户端列表中，查找匹配当前包名+Play应用签名SHA1的条目，确认其关联权限归属当前Firebase项目
     • 若无法快速定位权限归属，可暂时注释代码中所有Google SignIn的调用逻辑，先上架不含Google登录的版本，保障存量用户体验不受任何影响，后续再逐步排查OAuth权限问题
• 所有操作不会修改Firebase中已有的用户表、邮箱认证规则、云存储/数据库配置，存量用户的登录状态、数据关联关系不会发生任何变化

疑问3：目前持有新旧两个keystore文件，切回使用旧keystore是否能解决当前问题？ #

• 切回旧keystore无法从根本上解决当前问题
• 只要应用开启了Google Play App Signing机制，用户最终下载的分发版本，始终会被Play用官方托管的应用签名密钥重签名。你本地使用任何keystore生成的上传包，仅会作为校验上传合法性的上传密钥，不会成为最终分发给用户的安装包的签名
• 切回旧keystore仅在一种场景下生效：即应用从未开启Play App Signing机制，此时你本地签名的keystore就是最终分发版本的签名密钥，匹配Firebase配置的SHA1即可正常运行。但从你可在Play后台查看独立的App Signing SHA1值判断，你的应用已开启该机制，因此切换keystore无实际作用

内容的提问来源于stack exchange，提问作者Stucked so I came here