Android端Fitness API接入时Google登录失效，加载卡住无回调

核心配置校验项 #

• 首先核对后台OAuth 2.0客户端的匹配信息：
  • 对应客户端的SHA1值必须和当前运行应用的实际签名指纹完全一致：使用debug签名运行时，要填入本地debug keystore的SHA1值，不要错填release签名的SHA1，也不要直接照搬示例项目自带的SHA1配置。谷歌对Android应用的OAuth校验是同时比对包名和签名SHA1的，只要有一项不匹配，授权链路就会静默终止，不返回任何错误，直接卡在加载界面，和遇到的表现完全吻合。获取本地debug SHA1可直接运行Android Studio的signingReport Gradle任务，输出结果里的SHA1值就是当前构建的真实签名，填入后台配置后需等待数分钟生效。
  • 客户端绑定的包名，要和运行应用的applicationId完全一致，不能有大小写、后缀的偏差。
  • 测试用户必须添加到当前OAuth客户端所属的谷歌云项目下，跨项目添加的测试用户不会生效，也不会触发报错。

授权流程异常常见原因 #

• 不要混用新旧SDK的授权逻辑：如果引入了新版本的Google Play Services Fitness SDK，还沿用老版GoogleApiClient在onActivityResult接收回调的写法，会出现选完账号后流程无响应的问题，因为新版SDK的回调机制已经做了调整。
• 检查应用manifest中授权相关组件的配置，确认没有将必要的Google服务组件的exported属性设为不可导出，导致回调被系统拦截。

无日志输出场景的排查方法 #

• 不要只依赖系统Logcat的输出：授权身份校验类的失败，SDK通常不会主动打印错误日志。可以在GoogleApiClient的连接失败回调、授权结果监听方法里手动加日志，捕获静默返回的错误码。
• 先清除本地账号对当前应用的所有授权缓存，重新走授权流程，排除旧授权数据导致的流程卡死。

最小化验证方案 #

• 不要一开始就跑完整的官方示例项目，先新建最小Demo：只集成必要的Fitness SDK依赖，对齐所有后台配置项，只实现授权打通的逻辑，确认授权回调能正常触发后，再补充历史数据拉取的业务代码，逐步定位问题节点。

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