What an app signing certificate proves — and what it doesn't

Android's signing system is the strongest guarantee in the whole ecosystem, and it is routinely described as something it is not. It is worth being precise about, because the gap between what it actually proves and what people assume it proves is exactly where repackaged apps live.

Every Android app is signed

Android will not install an unsigned app. Before a build reaches a device it is signed with a private key that only the developer holds, and the APK carries the matching public certificate inside it. At install time the device checks the file against that signature and refuses anything that does not verify.

There have been four signing schemes. The original, v1, is inherited from Java's JAR signing and covers individual files inside the archive. v2 arrived in Android 7.0 and signs the whole archive as a block, which closed a family of attacks that exploited the gap between what v1 covered and what it did not. v3, in Android 9, added a key rotation lineage. v4, in Android 11, supports incremental installation. Modern builds are typically signed with several schemes at once so they install on old and new devices alike.

The one claim a certificate makes

When an app is installed, Android records the certificate it was signed with. From then on, every update to that package must be signed with the same certificate, or the install is rejected. There is no override, no setting, no root-free workaround.

That mechanism supports exactly one claim: this build came from whoever produced the build you already have. Continuity of authorship. It is a narrow claim, and it is worth reading twice, because it does not say the developer is honest, or competent, or that the app is safe, or that anyone has reviewed the code. It says the author has not changed.

Narrow as it is, it happens to be the claim that matters most in practice, because the most common way a familiar-looking APK turns hostile is repackaging — and repackaging always breaks it.

Read it yourself

The certificate is not a secret. apksigner, which ships with the Android SDK build-tools, will print it for any APK you have on disk:

apksigner verify --print-certs --verbose app.apk

Signer #1 certificate DN: CN=Example Dev, O=Example
Signer #1 certificate SHA-256 digest: 3f2b...c91a
Verified using v2 scheme (APK Signature Scheme v2): true

The line that matters is the SHA-256 digest. Everything else is decoration.

What it does not prove

It does not tell you who the developer is in any real-world sense. Android signing certificates are self-signed: no certificate authority checks them, and nothing stops anyone from generating a key whose certificate says CN=Google Inc. The name field is free text typed by whoever made the key. A certificate claiming to be from a company you have heard of is worth precisely nothing unless the fingerprint matches the fingerprint that company actually uses.

The fingerprint is the identity. The name is a label.

Two complications worth knowing

The first is Play App Signing. For a large share of apps on Google Play, Google holds the app signing key and signs the build that gets delivered to devices. The developer signs their upload with a separate upload key, which never reaches your phone. The practical consequence surprises people: a build downloaded from the developer's own website and signed with their own key can legitimately carry a different certificate than the Play build of the same package. Same app, same developer, two certificates — and the two are not interchangeable on a device. Whichever you install first is the one you are stuck with until you uninstall.

The second is key rotation. Since v3, a developer can rotate to a new signing key and include a lineage proving the new key was authorised by the old one. Devices running Android 9 and later accept the rotation; older devices continue to rely on the original key. So a certificate that changes between versions is not automatically sinister. But the lineage is the proof, not the developer's assurance in a changelog. A rotation without a lineage is indistinguishable from someone else signing the app.

How APKBrowse uses it

We record the SHA-256 fingerprint of the signing certificate for every build we hold, and we compare each new submission against the earlier releases of the same package. A mismatch blocks approval outright. When a listing says the signature was verified, that is the entire claim being made: same certificate, same author as the previous release, no repackaging in between.

We are deliberately not claiming more. We do not scan for malware, and a verified certificate is not a statement that the code is safe — only that its author has not silently changed.

Using this in practice

Before you install an APK for an app you already have on your device, print the certificate and compare its digest with the one on the copy you are running. If they differ, do not uninstall the working app to force the new one through. That error was the system protecting you, and uninstalling is how you switch the protection off.