Migrating keystore of Android app versions (by signing twice?)

Question

If I have access to the original keystore used to sign an Android apk is there a way to migrate future versions of the app to use a different keystore, preferably maintaining the ability to develop with ADT as though the second keystore had always been used?

From what I have been able to find out, it looks like we should be able to use jarsigner to sign the first update to the apk file twice with two different keystores. Then in the future any updates can be done with either key, letting the client take over app maintenance completely.

Version         Keystore
1.0             A
2.0             A & B
3.0                 B
4.0                 B
...              ...

I would like the client to be able to use ADT to export Version 2.0 apk file signed with Keystore B. When we try that their apk file contains CERT.SF mapped to Keystore B, whereas the Version 1.0 CERT.SF is mapped to Keystore A.

When I try this I still get the error:

An existing package by the same name with a conflicting signature is already installed.

I notice that when an apk is exported, it contains CERT.SF in its META-INF directory. When I sign a second time using jarsigner like this...

jarsigner -keystore /path/to/keystore_b -storepass STOREPASS -keypass KEYPASS ./AndroidApp.apk ALIAS

...the META-INF now also contains ALIAS.SF.

Is this Android upgrade is complaining because of the .SF files? CERT.SF is mapped to two different keys even though ALIAS.SF does contain the key it's looking for.

(Lesson learned: create new keystores for clients as early as possible)

Answer 1

If I have access to the original keystore used to sign an Android apk is there a way to migrate future versions of the app to use a different keystore, preferably maintaining the ability to develop with ADT as though the second keystore had always been used?

Alas, no. It would require modification to Android itself to support this. I did a bit of poking around on this issue last year, in conjunction of one of the researchers who wrote this paper on the subject.

From what I have been able to find out, it looks like we should be able to use jarsigner to sign the first update to the apk file twice with two different keystores

True, but all signatures need to match.

Then in the future any updates can be done with either key, letting the client take over app maintenance completely.

No, because all signatures need to match. This is the change that would be needed in Android. In your example, Version 2.0 will fail because the original app is not signed with B, even though it is signed with A.

Lesson learned: create new keystores for clients as early as possible

Consultants, or anyone else creating apps for others, probably should consider a keystore-per-app approach, or at least keystore-per-client, as you suggest.