Understand the roles
| Scheme | Main distinction |
|---|---|
| v1 | JAR-style signing associated with individual archive entries and legacy compatibility |
| v2 | APK-level integrity protection using the APK signing block |
| v3 | Extends the signing model with support for signing-key rotation metadata |
| v4 | Supports incremental installation through a separate signature file and relies on complementary APK signing |
Consult the v2, v3 and v4 specifications for precise verification behavior. This table is a conceptual map, not a complete compatibility matrix for every newer platform extension.
Do not infer schemes from META-INF alone
A modern signature block is not just another ordinary ZIP entry. An archive browser that sees no familiar v1 certificate file cannot conclude that the APK is unsigned. Conversely, a certificate file being present does not prove the package's current bytes verify.
Use a signing-aware tool:
apksigner verify --verbose --print-certs app.apk
Read the verification result for the relevant schemes and the tool's warnings. apksigner.
Match signing settings to supported devices
A release supporting older Android versions may need compatibility behavior different from a modern-only application. Let the supported Android build/signing tooling apply the appropriate configuration, and test the actual minimum-supported platform.
Do not disable a scheme simply to make a scanner show fewer entries or to imitate a screenshot from another app. The right configuration depends on the release's platform support and distribution arrangement.
Account for rotation and newer platform changes
Signing lineage can allow documented transitions between keys on supported platforms. Google Play's key-upgrade arrangements can also vary by platform version. A checker that displays only one certificate without explaining lineage may give an incomplete view.
When a release uses a newer signing feature, verify that the analysis tool understands it. “Not reported” and “cryptographically absent” are not interchangeable results.
Use the output as evidence, not a badge
Record the verifier version, artifact identifier, supported Android range and certificate comparison. Keep cryptographic verification separate from a malware or vulnerability assessment.
APKLint's signature viewer is designed for signing metadata and structural information. It should not be used to assert that every scheme was fully cryptographically verified, that a publisher is trustworthy or that a package will install on every device.
Interpret a scheme report in its platform context
Suppose a verifier reports a valid modern APK signing scheme but no v1 signature. The useful next question is which Android versions the release is intended to support and whether its signing configuration matches that support. Do not add or remove schemes merely to make the report contain the largest possible number of green rows. A compatibility conclusion requires the actual release configuration and relevant verifier behavior.
Keep the verifier version and the artifact's minimum-platform declaration in the report. If a scanner cannot recognize a newer scheme or signing feature, label the result as unsupported or unknown rather than reporting cryptographic absence. Conversely, a recognized signing-block structure is not by itself evidence that the protected content passed verification.
Keep key rotation evidence with update tests
For an application using a documented key transition, retain the old and new signing identities, the relevant lineage information and the platform coverage of the transition. Test an update from a supported old release on the intended platform versions using synthetic data. A fresh install of the new build does not exercise continuity with the previous signer.
The AOSP signing overview links to the individual scheme specifications. Consult the specification for a precise protocol question and the distribution provider's documentation for account-specific key-management behavior. A short scheme table is a navigation aid, not a replacement for either source.
If your workflow emits a separate v4 signature file, preserve its association with the corresponding APK and understand which installation path consumes it. Do not assume that finding a sidecar file makes an otherwise invalid APK acceptable. The release record should still identify the final APK and its verification result, with any complementary artifacts listed explicitly. This avoids confusing an incremental-installation mechanism with an independent publisher-trust guarantee.
Sources and further reading
- Android Open Source Project: APK signature scheme v2
- Android Open Source Project: APK signature scheme v3
- Android Open Source Project: APK signature scheme v4
- Android Developers: apksigner
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
