密钥库和别名 - 是否有使用多个别名？
使用 Eclipse 导出签名的 Android 应用程序时，使用多个别名是否有目的？
根据关于签名的官方指南，建议您对所有应用程序进行签名具有相同的证书，允许您的应用程序共享数据、代码并以模块化方式更新。
假设“别名”、“密钥”和“证书”在这种情况下本质上是可以互换的，那么为什么有人会想要为其所有应用程序使用不同的别名？我能想到的唯一原因是它为您的应用程序增加了更多的安全性，从某种意义上说，受损的密钥/密码不会危及一切。还有其他原因吗？
另外，生成的密钥是否取决于别名的名称？换句话说，如果更改别名但不更改密码，生成的证书会有所不同吗？
When exporting a signed Android application using Eclipse, is there a purpose to using multiple aliases?
According to the official guide about signing, it's recommended that you sign all applications with the same certificate to allow your applications to share data, code and be updated in modular fashion.
Assuming that "alias", "key" and "certificate" are essentially interchangeable in this context, is there a reason why someone would want to use different aliases for all their applications? The only reason I can think of is that it adds more security to your applications, in the sense that a compromised key/password doesn't compromise everything. Are there other reasons?
Also, is the generated key dependent on the name of the alias? In other words, if you change the name of the alias but not the password, would the generated certificate be different?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果我错了，请纠正我，但如果您会看到这个答案 对于类似的问题，您会发现证书确实取决于您选择用于签名的特定“别名”（在您的密钥库中）。
仔细阅读答案，您会发现“密钥库”包含“别名”（实际上是私钥+公钥对）。当您对 apk 进行签名时，“公钥”就是嵌入的实际证书。
因此，在更新应用程序时，您应该始终使用相同的“别名”，而不仅仅是相同的“密钥库”。至于为什么开发人员会在他们的密钥库中拥有多个“别名”，我不确定除了您和其他人所说的之外还有什么好处。
使用不同别名进行签名的唯一方法是克隆前一个别名，正如答案所建议的那样。
我还确认使用不同别名（来自同一密钥库）签署 APK 将生成不同的 APK 签署签名，这应该证明不同的“别名”=不同的证书。 如何获取您的签名（<- 注意：我不知道他们指的Trace.i方法是什么，我用Log.i代替）
Correct me if I'm wrong but if you'll see this answer to a similar question you see that the certificate does indeed depend on the particular "alias" (within your keystore) that you choose to sign with.
Read the answer carefully and you see that the "keystore" contains "alias"s (which are actually private+public key pairs). When you sign your apk it is the "public key" that is the actual certificate being embedded.
Therefore when updating your app you should always use the same "alias", not just the same "keystore". As for why devs would have multiple "alias"s in their keystore, I'm uncertain of the benefit other than what you and others have stated.
And the only way you can sign with a different alias would be to clone the previous one as the answer also suggests.
I have also confirmed that signing an APK with different alias's (from the same Keystore) will generate different APK signing signatures which should be proof that different "alias"s = different certificate. How to get your signing sig (<- note: I don't know what the Trace.i method they refer to is, I used Log.i instead)
请注意，通过使用不同的密钥对应用程序进行签名，您会牺牲应用程序之间的“基于签名的权限”互操作性。
摘自 Android - 签署您的应用程序 - 签名策略
Do be aware that by signing the apps with different keys you are sacrificing "signature-based permissions" interoperability between your apps.
Excerpt from Android - Signing Your Applications - Signing Strategies
我正在做一些测试，虽然在密钥库中使用哪个密钥似乎很重要，但更改密钥上的别名和密钥库文件的名称似乎对手机来说并不重要。如果您好奇，我使用从这里获得的 keytool-iui 更改了别名：http: //code.google.com/p/keytool-iui/
为了回答OP，我想说，如果您在一家有多个部门编写自己的应用程序的大公司工作，那么它会很有用。因此，Wilson 的 Widgets 可能有一个 wilsonwidgets.keystore 密钥库，并且可能有一个具有“widgetmakers”密钥的内部部门，一个具有“widgetdelivery”密钥的部门，以及另一个具有“hrdepartment”密钥的部门。每个部门都可以阻止其他部门更新其应用程序，但公司本身将所有密钥存储在一个密钥库中，并且可以备份到一个位置。
就我个人而言，我使用不同的密钥对每个应用程序进行签名，并将它们全部存储在同一个密钥库中。我这样做是为了，如果谷歌决定从我这里购买我的一款应用程序，我可以断开该密钥并将其交给他们，而不必向他们出售整个应用程序或为其他应用程序重新生成密钥。实际上...我只是在浪费时间和精力...叹气
I was doing some testing, and although it seems to matter which key you use in the keystore, changing the alias on the key and the name of the keystore file doesn't really seem to matter to the handset. If you're curious, I changed the alias with keytool-iui that I got from here: http://code.google.com/p/keytool-iui/
To answer the OP, I would say that it is useful if you work in a large company with multiple divisions writing their own apps. So Wilson's Widgets could have a keystore of wilsonwidgets.keystore, and there could be an internal department with a "widgetmakers" key, and a department with a "widgetdelivery" key, and another department with an "hrdepartment" key. Each department could prevent the other department from updating their app, but the company itself has all of the keys stored in one keystore that can be backed up to one location.
Personally, I sign each app with a different key store them all in the same keystore. I do that so if Google decides to buy one of my apps from me I can break off that one key and give it to them without having to sell them the whole lot or regenerate keys for the other apps. Realistically... I'm just wasting time and effort... sigh