Menu
I understand the benefits of signing all your Android apps with the same key - data sharing, etc. - and the fact that this is recommended by Google.
My thought is that there may be one big reason for it to be advantageous to sign each app - at least each app that is unrelated to others and unlikely to need to share data - with a different key. That reason is if you end up wanting or needing to hand your code off to another developer or company to update in the future.
In this case - which could arise if you sold your app, for instance - you would need to provide the key your app was signed with in order for the new owner to update the Play Store with any improvements they make.
Now, if you've signed all your apps with the same key, you can't give the new owners of this one app your key without compromising all your other apps, or re-releasing them under a new package/cert and all the problems that go along with that. If you sign all unrelated apps with their own key, you can send this app's one key along with no worries.
So the question is - Is this the case? Or am I misunderstanding something basic here?
As a second question, if my above thinking is correct, could you use the same keystore, and just have different aliases for all of your keys for your different apps? From my understanding the aliases are the actual key pairs, but can you "pull them out" of the keystore to send them to a new developer, as in the case outlined above? Or should someone planning for this contingency use a new keystore for each app?
Thank you very much!
415
It's always better to use the same keystore file for all the applications you develop. That will help if you want to update or modify the application. At that time you need to sign your application with the same key.
A keystore is a storage mechanism for security certificates. A public key certificate is used to sign an APK before deployment to services like the Google Play Store.
Unfortunately, there is nothing else we can do to assist you further with this matter. Show activity on this post. As blackbelt stated, if you signed it with a different keystore, it will be a new application. So you should tell your users that they have to download the new version of the app.
This type of entry can be used to authenticate other parties. Each entry in a keystore is identified by an "alias" string. In the case of private keys and their associated certificate chains, these strings distinguish among the different ways in which the entity may authenticate itself.
Google's recommendation aside, many think you should sign every app with its own key. In a very real sense, ownership (i.e. knowledge) of an app's key is in essence ownership of that app and any other app with that key. There's no mechanism to ever change an app's key.
Another potential problem with signing unrelated apps with the same key is if/when your company grows. It would be prudent to minimize the damage that a single disgruntled employee/partner could do to your business. A paranoid person might even retain sole responsibility for signing apps with the production keys.
If I understand the premise of your second question correctly, then you are correct. Keystores are just collections of keys and the aliases are just a short-hand way to identify each key. You can make a copy of the keystore file and selectively delete some of the aliases (keys).
Use this command to see the commands that can be used with the keytool command:
keytool -help
Use the following one to see the options that can be used with the delete command. It goes without saying to make a backup before modifying the keystore:
keytool -help -delete
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
