How actually is verified signature on APK update?

Question

I have an Android app. I released this app as APK on Google Play. The app was signed by a signing key that I possess:

private key: let's name it A - RSA 4096
certificate: let's name it C1 - made some years ago using SHA1

And now: my goal is to create a new certificate (let's name it C2) based on key A, but with a changed digest algorithm from SHA1 to SHA256. And I want to release new versions of the app by signing them with A+C2. I'm even able to set on C2 all fields and validity time the same as in C1. Only the digest will be changed.

And the question is - will I have problems with app updates released and signed by using A+C2?

AFAIK to verify the unchanged source of an app, it's enough to verify the public key that was used for the signature. And in my case - C2 has the same public key as C1.

So how actually is verified signature on APK udate? Which of these is checked:

private/public key? (You can get public key, if you have the private key)
certificate?
certificate fields?
anything else?

Some sources say that the same certificate is important:

"If the package name and signing certificate do not match those of the existing version, Market will consider it a new application and will not offer it to users as an update." (refs: https://stackoverflow.com/a/4843261/1961303 )
"App upgrade: When the system is installing an update to an app, it compares the certificate(s) in the new version with those in the existing version. The system allows the update if the certificates match." (refs: https://developer.android.com/studio/publish/app-signing#considerations )

Some seem to say that maybe only the private key needs to be the same:

"However, because users can only update your app if the update is signed with the same signing key, it's difficult to change the signing key for an app that's already published." (refs: https://developer.android.com/studio/publish/app-signing#upgrade_key )

I'm pretty sure that C2 will be considered as a new key, and that it won't be possible to upgrade the C1 key to C2. So you will either have to inform your users that a "new app with the same name" will be published and they'd have to download that one, and stop using the current one. Or, just make the current one launch to the new app's googleplay page, and release the same app with the new key, and just work on updating the new app signed with the C2 key. tl;dr - push an update to current app to open page of new app, release same app signed with C2 key, and thats it. — Shark, Dec 23 '22 at 14:13

score 0 · Answer 1 · answered Dec 23 '22 at 19:36

The Android platform compares the certificate byte-for-byte between the APK already installed and the one to be installed.

So you can't create a new certificate from the same key and expect updates to be seamless.

One option you have would be using key rotation, which has been introduced in Android 9: https://developer.android.com/about/versions/pie/android-9.0#apk-key-rotation

score 0 · Accepted Answer · answered Dec 27 '22 at 15:24

Thx for all your comments/answers. I hoped to find a precise answer in Android source code, to be sure. But it wasn't possible.

So finally I did a test - I created C2 and I signed the same app with C2. And unfortunately, when I tried to install the new version signed with C2, then Android refused saying that the app comes from another developer..

So now we know it for sure:

It's not enough to use the same private/public key.
Android wants the publisher's whole certificate to be exactly the same.

So now I will focus on APK key rotation mentioned earlier by others https://stackoverflow.com/a/74903402/1961303

How actually is verified signature on APK update?

2 Answers2

Linked