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)

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

The Android system provides signature-based permissions enforcement, so that an application can expose functionality to another application that is signed with a specified certificate. By signing multiple applications with the same certificate and using signature-based permissions checks, your applications can share code and data in a secure manner.

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