Ect*_*ion 5 android certificate google-play
目前,Google Play上的三个应用程序在过去几天尝试上传新版本时出现了类似的签名错误:
上传失败您将使用其他证书签名的APK上传到之前的APK.您必须使用相同的证书.您现有的APK使用带有指纹的证书进行签名:
[SHA1:87:17:A3:71:CD:CF:D6:73:71:56:B1:59:DE:89:6D:5A:E0:EE:31:8A,SHA1:4C:45:1E :30:2D:04:F4:DC:36:0E:EF:29:1B:1E:E1:02:C0:E8:E9:85]
用于签署您上传的APK的证书有指纹:
[SHA1:87:17:A3:71:CD:CF:D6:73:71:56:B1:59:DE:89:6D:5A:E0:EE:31:8A]
我仔细检查了密钥库,这是我一直使用的密钥库.事实上,有些应用程序有一个使用相同密钥库的专业版,并且更新工作正常.引人注目的IMO是旧的,现有的APK的奇怪指纹,在上面的例子中有第二个带有"SHA1:"的条目,其中一个未通过旧指纹的应用被列为"[]" ,即空的.与此同时,我还更新了其他应用程序,在大多数情况下,一切正常.唯一的(我注意到),我遇到问题的三个应用程序有一个共同点,那就是这些应用程序已经很老了,第一个APK版本可以追溯到2009年甚至是2008年.但专业版本 - 工作正常 - 稍后介绍.
在Google Play上有一个类似的问题上传失败的新版本apk,但浏览器缓存解决方案不起作用,我也非常有信心我使用了正确的密钥.
任何人都知道这里可能有什么解决方案？我开始认为,对于一些较旧的应用程序,指纹不正确地从Google侧面的APK中提取(因此一个空的,另一个IMO对于旧版本有点奇怪的指纹).但通常问题来自于自己的耳朵......
谢谢
可以使用多个密钥对 APK 进行签名。这从来都不是一个真正得到良好支持的行为，并且处理键的顺序是未定义的。但是，如果您的早期 APK 使用两个密钥进行签名（如消息所示），那么您的更新将需要使用所有相同的密钥（可能以相同的顺序）进行签名。
看起来第一个密钥与您使用的密钥相同，因此您需要找到第二个密钥的密钥库。也许您的构建过程的某些部分是在上传之前重新签署 APK。可能的嫌疑可能是 ~/.android 中的调试密钥库。