1.概述
移动统一认证一键免密登录 api 被调用时会检测应用的 MD5 应用签名以确认应用的合法性。出现103102 包签名错误那么就是应用的 MD5 签名与用户在中国移动开发者社区上填写的 MD5 包签名的不一致导致的。
![](https://i-blog.csdnimg.cn/blog_migrate/6ff2770a0db47cb077005f48714d1a54.png)
2.开发者打包时使用的keystore文件变更
开发者打包时使用的 keystore 文件变更的情况一般是开发者在配置一键免密登录能力时使用的release的应用并通过移动提供的获取应用 MD5 签名工具获取的 release 包的小写 MD5 应用签名,但是在实际调试中大多数是 debug 版本。
一般情况下开发者调试过程中 AS 都默认使用一个 debug.keystore 文件打包 debug 版本的应用,那么这时 sdk 获取到的应用的小写 MD5 应用签名是 debug.keystore 文件的,为了保证 debug 模式下的小写 MD5 签名和开发者社区的一致我们需要修改 debug 模式下使用的的 keystore 文件。
首先在应用的 build.gradle 文件中对 Release 版本的 keystore 文件进行配置。
android {
compileSdkVersion 28
buildToolsVersion "28.0.2"
signingConfigs {
config {
keyAlias 'release keystore 的 alias'
keyPassword 'password'
storeFile file('keystore文件的绝对路径')
storePassword 'password'
}
}
... ...
}
然后将这个配置设置到自己的 BuildType中
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
//配置release版本使用的keystore
signingConfig signingConfigs.config
}
debug {
minifyEnabled false
//配置debug版本使用的keystore
signingConfig signingConfigs.config
debuggable true
}
}
配置好之后 release 和 debug 或者其他的 buildType 使用的 keystore 文件就一致了,运行后再次调用一键免密登录的 api 就能通过应用合法性校验。
3.开发者 appid 使用错误
这种情况一般是由于开发者疏忽导致,比如开发者在中国移动开发者社区申请了两个应用分别是 A 和 B,配置能力的时候分别配置了两套包名、MD5 应用签名,但是在代码中调用中国移动一键免密登录时传入的 APPID 和 APPKEY 用错,A 应用使用了 B 应用的 APPID 与 APPKEY,B 应用使用了 A 应用的 APPID 与 APPKEY。
4.应用被重新签名
部分应用在集成某些业务或者上传至某些应用商城时,对应的业务或者应用商城有可能会对应用重新签名,此时就需要用户协商好之后再在开发者社区上配置统一认证一键免密登录的包名和 MD5 应用签名。
比如:
应用自己的 md5 应用签名是: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
被重新签名后的 md5 应用签名是: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
如遇这种情况可以在开发者社区上申请两个应用,配置一键免密登录时 MD5 应用签名分别配置重新签名前和被第三方平台重新签名后的,然后在调试时使用自己的 MD5 应用签名对应的 appid 和 appkey ,上线应用商城或者其他业务时将 appid 和 appkey 修改成重新签名后的,这样应用被重新签名后也能继续使用统一认证一键免密登录功能。