APK Signature Scheme v1, v2, v3: What Each One Does

APK signature scheme v1, v2 and v3 are three generations of the signature Android checks before it installs or updates an app. v1 is the original JAR-based signature, v2 (Android 7.0) signs the whole APK file, and v3 (Android 9) keeps the v2 format but adds supported SDK ranges and a proof of key rotation. Which ones you need depends on the oldest Android version your app supports.

What a signature scheme decides

A signature scheme is the format of the signature inside your APK and the rules Android uses to check it. Every scheme proves the same thing: the file came from the holder of your key and wasn’t changed afterwards. They differ in how much of the file they protect and what extra data they carry.

The Android Open Source Project page on application signing says APK signing has been part of Android from the beginning. Newer schemes were added on top rather than replacing the old one, so one APK can carry several signatures at once.

If you’re new to signing in general, start with the difference between a signed and an unsigned APK. Here I assume you already have a key.

APK signature scheme v1, v2 and v3 compared

The v1, v2 and v3 schemes differ in coverage, the first Android version that reads them, and whether they support a key change.

	v1 (JAR signing)	v2	v3
First Android version that checks it	From the beginning	Android 7.0	Android 9
What it covers	Individual JAR entries, not ZIP metadata	Whole file except the signing block	Whole file, same as v2
Key rotation	No	No	Yes, via proof-of-rotation
Where it lives	`META-INF/` files	APK Signing Block	APK Signing Block

v1: JAR signing

v1 signing is the old Java JAR signature applied to the entries of the APK. Its weakness is coverage: the AOSP page notes that v1 signatures don’t protect some parts of the APK, such as ZIP metadata.

That gap was exploited. The December 2017 Android Security Bulletin lists CVE-2017-13156 as a High-severity elevation of privilege bug in the System component. XDA’s coverage of v3 describes it as Janus, which let attackers modify APKs without affecting their signatures, and says using v1 only is heavily discouraged.

v2: whole-file signing

APK Signature Scheme v2 signs the APK as one file. The v2 specification says it protects the ZIP entry contents, the ZIP Central Directory and the ZIP End of Central Directory. The signature sits in an APK Signing Block placed immediately before the Central Directory.

Because the whole file is covered, any change after signing breaks the signature. That’s why you run zipalign before signing, never after. The spec also calls v2 a whole-file scheme that increases verification speed.

v2 also guards against downgrade tricks. An APK signed with both v1 and v2 carries an X-Android-APK-Signed attribute in its META-INF/*.SF file. Stripping the v2 block to force a weaker v1 check then fails.

v3: key rotation

APK Signature Scheme v3 uses the same block layout as v2. According to the v3 specification, it adds information about the supported SDK versions and a proof-of-rotation struct. That struct is a chain of certificates where each old key vouches for the next one, so you can move to a new signing key and still update existing installs.

There’s a catch. The same page says APK key rotation is not recommended for Android 12 (API level 31) and earlier. The apksigner docs say rotated keys are supported on Android 13 (API level 33) or higher and go in a v3.1 signing block by default, while the original key keeps signing for older versions.

How Android picks which signature to check

Android checks the newest scheme it understands and falls back from there. Per the v3 spec, Android 9 and later look for a v3 signature first and fall back to v2. Older platforms ignore v3 and try v2, then v1.

Android 7.0 and 8.x verify v2 or v1 and ignore v3. Anything older than Android 7.0 ignores v2 and v3 completely and only checks v1.

Which schemes should you enable?

Enable the schemes that every device in your supported range can read, and add v3 if you might rotate keys. Google’s own advice on the AOSP page is to sign with all schemes for maximum compatibility, first v1, then v2, then v3.

In practice your minSdkVersion decides it:

Your app’s oldest supported Android	Needed	Optional
Older than Android 7.0	v1 + v2	v3
Android 7.0 to 8.x	v2	v1, v3
Android 9 or newer	v2 or v3	the other one

You rarely set this by hand. The apksigner docs say that, by default, the tool uses --min-sdk-version and --max-sdk-version to decide which schemes to apply, and --min-sdk-version defaults to the minSdkVersion in your manifest. If you sign in Android Studio, the Sign your app guide says you choose the Signature Versions in the Generate Signed Bundle or APK dialog.

A concrete case: an app built with WebToAPK Free requires Android 8.0 or newer (minimum SDK 26). Every device that can install it understands v2, so the v1 signature adds nothing for compatibility there. A v1-only file would be the risky choice, not a v2-only one.

Where v4 fits

APK Signature Scheme v4 is not a replacement for the others. The v4 specification says Android 11 stores it in a separate <apk name>.apk.idsig file, which adb install --incremental expects next to the APK. A v4 signature requires a complementary v2 or v3 signature, so you add it on top, mostly for faster installs during development.

How to check which schemes an APK has

Run apksigner verify on the file to see whether its signatures will be accepted. The docs list -v / --verbose for detailed output and --print-certs to show the signing certificates:

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

You can also test a specific range. The docs’ example, apksigner verify --min-sdk-version 15 app.apk, checks whether the signature will be valid on Android 4.0.3 (API level 15) and up. If a file you edited after signing now fails, re-sign it; the full flow is in how to sign an APK from the command line. Signature trouble is also one of the causes behind the “App not installed” error.

Do app bundles and Google Play change this?

App bundles move the APK signing step to Google. The Sign your app guide says that with Android App Bundles you sign the bundle with an upload key, and Play App Signing uses your app signing key to sign the APKs it delivers.

So for a Play release, scheme choice for the delivered APKs is Google’s job, not yours. It matters again when you sideload, share a test APK, or publish to another store. The same guide notes Google Play supports v3 for APKs that aren’t already published with an existing signing certificate lineage.

How WebToAPK Free handles signing

WebToAPK Free signs the output in your browser, and the private key is not uploaded to a build server. You get a signed APK to install and test, plus an AAB for a separate store submission.

The limitation: it can’t import an existing JKS or P12 keystore, only its own encrypted key backups. If an app is already published with a key from Android Studio, you can’t sign its updates here. The signing and updates guide covers backing up the key. For the wider question of trusting a web tool with a key, see whether online website-to-APK converters are safe.

My take

Schemes aren’t really a choice. They follow from minSdkVersion. Set that honestly, let apksigner or Android Studio pick, and check the result with apksigner verify. The only decision that deserves thought is v3 rotation, and only if you expect to need a new key. Even then it helps users on Android 13 and newer, nobody else.

FAQ

Do I still need v1 signing?

Only if your app supports devices older than Android 7.0. Those versions ignore v2 and v3 signatures and only check the v1 (JAR) signature.

Is v2 enough for a modern app?

Android 7.0 and later can verify a v2 signature, so v2 alone installs there. Add v3 if you want the option of rotating your signing key later.

What is the v4 signature and the .idsig file?

APK Signature Scheme v4 arrived in Android 11. It stores the signature in a separate .apk.idsig file used for incremental installs, and it needs a v2 or v3 signature alongside it.

Which scheme does Android check first?

Android 9 and later look for a v3 signature first, then fall back to v2. Older versions ignore v3 and try v2, then v1.

What are APK signature schemes v1, v2 and v3?