Every Android app is signed, and how it is signed has evolved through several APK signature schemes, each adding security or capability. The original JAR-based scheme signed files individually and had weaknesses; v2 signs the whole APK and detects any tampering; v3 adds key rotation; v4 supports incremental installs. The scheme matters because signature verification is what proves an APK has not been modified since you signed it, which underpins update integrity. Modern build tools handle this for you, but knowing what each scheme does helps you sign correctly. Here is what the APK signature schemes are and why they matter.
Short answer
Android APK signing has progressed through several schemes. Per Android's documentation, v1 is the original JAR-based signing that signs files individually and has known weaknesses; v2, introduced in Android 7.0, signs the whole APK so any modification is detected and verification is faster; v3, added in Android 9, supports signing-key rotation with a proven lineage; and v4, added in Android 11, supports incremental and streaming installs, used alongside v2 or v3. The scheme matters because signature verification proves the APK has not been tampered with since signing, which is the basis of update integrity. Modern build tools sign with v2 and v3 by default, and Play App Signing manages the signing key.
What you should know
- APKs are signed: signature verification proves they are unmodified since signing.
- v1 is legacy: JAR-based, signs files individually, with known weaknesses.
- v2 signs the whole APK: introduced in Android 7.0, detects any modification.
- v3 adds key rotation: introduced in Android 9, with a proven lineage.
- v4 supports incremental installs: introduced in Android 11, used with v2 or v3.
What are the APK signature schemes?
A series of signing formats, each improving on the last. The table summarizes them.
| Scheme | Introduced | What it adds |
|---|---|---|
| v1 (JAR signing) | Original | Signs individual files; legacy, with known weaknesses |
| v2 | Android 7.0 | Whole-APK signing; faster, detects any modification |
| v3 | Android 9 | Signing-key rotation with a proven lineage |
| v4 | Android 11 | Incremental and streaming installs, with v2 or v3 |
The v1 scheme signs each file in the APK separately, which is slower to verify and was susceptible to certain tampering attacks. The v2 scheme signs the entire APK as a unit, so any change to the file after signing is detected, and it verifies faster. The v3 scheme builds on v2 and adds the ability to rotate your signing key while proving the new key is a legitimate successor of the old one. The v4 scheme adds support for incremental installation, working together with v2 or v3 rather than replacing them. Modern Android apps are signed with v2 and v3, which build tools handle automatically.
Why does the signing scheme matter for security?
Because signature verification is how a device confirms an APK is genuine and unmodified. Android accepts an app, and its updates, only if the package is signed with the expected key, and the signature lets the device verify the package has not been altered since you signed it. The scheme determines how robustly that check works: whole-APK signing in v2 and later detects any modification to the package, whereas the older v1 scheme's per-file approach was both slower and more susceptible to tampering. Key rotation in v3 also matters for long-term integrity, letting you move to a new signing key without losing the ability to update your app under the same identity. So the signing scheme is part of what keeps an attacker from distributing a modified version of your app that devices would accept, and using a modern scheme strengthens that guarantee.
How do you sign correctly?
Use modern build tooling and Play App Signing, which handle the schemes for you. Current Android build tools sign apps with v2 and v3 by default, so the practical advice is to use up-to-date tooling and not disable the modern schemes or rely on v1-only signing. With Play App Signing, Google manages your app signing key and signs the delivered APKs, applying the appropriate schemes, while you sign your upload with your upload key. Keep your signing configuration current as the build tools evolve, and if you need to rotate your signing key, v3's lineage support is what makes that possible without breaking updates. You generally do not hand-configure signature schemes; the right move is to use current tooling and Play App Signing rather than legacy settings. The goal is that your shipped APKs are signed with a modern scheme so their integrity is robustly verifiable.
What to watch out for
The first trap is relying on v1-only signing with outdated tooling, which is slower to verify and weaker against tampering; use modern build tools that apply v2 and v3. The second is disabling modern schemes for compatibility you do not actually need. The third is mishandling key rotation, which v3 supports but which still requires care. Signature schemes are about package integrity and distribution rather than the code inside the app, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the binary against OWASP MASVS for the security within the app, addresses a different layer; the signing configuration you manage in your build and Play App Signing.
What to take away
- Android APK signing has evolved through schemes: v1 (legacy JAR signing), v2 (whole-APK, Android 7.0), v3 (key rotation, Android 9), and v4 (incremental installs, Android 11).
- The scheme matters because signature verification proves an APK is unmodified since signing, and whole-APK signing in v2 and later is more robust than the older v1 approach.
- Use modern build tooling, which signs with v2 and v3 by default, and Play App Signing, which manages the signing key and applies the appropriate schemes.
- This is about package integrity, so it sits alongside a pre-submission scan such as PTKD.com that checks the security inside the app.
