APK Signature Inspector — inspecteur de signatures APK

Four schemes, one app

Every Android app is signed, and Android identifies an app by its signing certificate — there is no certificate authority: an update installs only if it is signed with the same certificate, or with a key the app has formally rotated to. Over the years Android has gained four APK signature schemes, and an APK usually carries several so that old and new devices can all verify it:

• v1 is plain JAR signing: META-INF/MANIFEST.MF digests every entry, a .SF file digests the manifest, and a PKCS #7 block signs the .SF. It does not protect the ZIP structure itself.
• v2 (Android 7.0, API 24) signs the whole file. It lives in the APK Signing Block, inserted between the ZIP entries and the central directory; each signer signs digests computed over the entries, the central directory and the end-of-central-directory record, in 1 MiB chunks.
• v3 (Android 9, API 28) adds SDK ranges and key rotation: a proof-of-rotation lineage where each certificate is signed by the previous key. v3.1 (Android 13) lets the rotated key apply only from a given API level, while the v3 block keeps the original key for older devices.
• v4 (Android 11) is a separate .idsig file with a SHA-256 Merkle tree over 4 KiB blocks of the APK, for incremental installation; its signature is bound to the APK's v2 or v3 signature.

What is verified

The inspector finds the APK Signing Block, lists its blocks — signature schemes, verity padding, source stamps, Play metadata — and verifies every v2, v3 and v3.1 signer as apksigner verify does. Each supported signature must verify over the signed data; the signed digests must name exactly the signature algorithms; every content digest — chunked SHA-256, chunked SHA-512 or the verity digest — is recomputed over the archive; the public key must be the one in the certificate; the SDK range in the signed data must equal the one outside it. A rotation lineage is followed link by link, and its newest certificate must be the signer's.

Then the schemes are compared. Removing a newer signature to fall back to an older, weaker one is called stripping, and both v2 and v1 carry protection: a v2 attribute names v3 when the APK was also signed with it, and the v1 manifest's X-Android-APK-Signed header names the schemes it was signed with. A missing scheme that one of them announces is reported. All schemes must name the same signer — the original key for v1, v2 and v3, the lineage's root key after rotation. A v4 .idsig is checked against the APK: its Merkle root hash, the stored tree, its signatures and its binding to the v2/v3 digests. The v1 JAR signature is verified entry by entry with the same code as the JAR signature inspector.

The examples are APKs written for the test suite and signed with apksigner from this site's published test keys — RSA-2048 for the original key, P-256 for the rotated one — and verified with apksigner verify when they were generated. The SHA-256 fingerprint the inspector shows for the signer is the one Google Play, apksigner verify --print-certs and keytool -printcert print; the certificate itself is decoded in detail by the certificate decoder.