Android “应用程序签名证书”和“上载证书”的SHA1分别属于两个不同的密钥库。这怎么可能？

几天来，我一直在尝试上传现有应用程序的aab。我们以前从未尝试过aab，所以这是一次新的尝试。我遇到一个错误，说您的android应用程序包使用了错误的密钥签名，这表明SHA1不匹配。所以我清理了项目，重建了缓存，并使其失效，因为为什么不呢？然后再试一次——错误依然存在。尽管如此，上载常规APK可以很好地使用此密钥库

出于好奇，我尝试用项目目录中的另一个密钥库构建签名的aab，一个没有人使用的密钥库，令我惊讶的是，这个新签名的aab被接受了。这似乎不可能，我发现应用程序签名证书的SHA1属于一个密钥库，而上载证书属于另一个密钥库

---

我不明白这怎么可能。我们有多人访问dev控制台。即使是人为错误，如何接受来自错误密钥库的上载证书？如何修复此问题，以便上载带有实际密钥库的aab？

当您或团队中的某个人在应用程序按播放签名中注册您的应用程序时，您必须创建第二个密钥库来创建上载密钥，并按照给定的说明将证书上载到Google Play

upload密钥应用于签署未来的APK和应用程序捆绑包

创建此上载密钥后，您的APK仍然可以使用原始应用程序签名密钥上载，原因是Play希望允许您在某个测试轨道上测试应用程序包，但不希望您当前的APK发布过程同时受到影响，因此，他们仍然接受使用应用程序签名密钥上载的APK

理想情况下，您现在应该将包含您的应用程序签名密钥的密钥存储库放在具有受限ACL的安全位置，因为它被泄露可能会产生灾难性后果，即必须将您的所有用户迁移到新应用程序，并且只使用包含您的上载密钥的密钥存储库，如果泄露，可以重置该密钥

有关上载密钥和应用程序签名密钥的一些说明，我建议阅读以下文档：

---

这意味着，用于注册应用程序按播放签名的新密钥库现在是我们在未来aab版本中应该关注的新密钥库。对于APK，我们必须使用旧密钥库。我理解正确了吗？新的密钥库应该同时用于APK和AAB。如果对您来说更方便的话，您可以选择使用旧的密钥库来上传APK，但正如我所说的，我建议您完全停止使用它，并将其保持在安全的位置。