Diagnosing and Resolving APK Signature Scheme Verification Failures in Android 15 and 16: Complete apksigner Guide

Introduction: Why Modern Android Rejects Recompiled and Resigned APKs

As Android security deepens with Android 15 and 16, package installation rules have become significantly more stringent. Security researchers and engineers recompiling decompiled APKs frequently encounter frustrating installation failures such as INSTALL_PARSE_FAILED_NO_CERTIFICATES, INSTALL_FAILED_INVALID_APK, or runtime verification rejections. While older Android versions allowed relaxed signature configurations and simple JAR signing (Scheme v1), contemporary Android runtimes enforce multi-scheme verification, strict cryptographic digest requirements, and alignment guarantees.

Understanding how the Android OS verifies application authenticity across APK Signature Schemes v1, v2, v3, and v3.1 is critical when modifying or analyzing binaries. In this guide, we dive deep into the internals of the APK Signing Block, examine how Android 15+ 16KB page alignment affects signature integrity, identify common recompilation pitfalls, and demonstrate how to diagnose and resolve signing errors using modern tooling, including CLI utilities and APKTool Studio.

The Evolution of APK Signature Schemes

To diagnose signature rejections, you must understand where each signature layer resides and what it validates within the ZIP archive:

• Scheme v1 (JAR Signing): The legacy signature format. It verifies individual files stored inside the ZIP archive by computing SHA digests for each entry and recording them in META-INF/MANIFEST.MF and META-INF/CERT.SF. It does not protect ZIP metadata or file ordering, making it susceptible to certain metadata modifications.
• Scheme v2 (APK Signature Scheme v2): Introduced in Android 7.0 (Nougat). Rather than parsing individual ZIP entries, Scheme v2 protects the entire binary by embedding an APK Signing Block immediately before the Central Directory. It hashes contiguous chunks of the file, providing faster verification and tamper detection.
• Scheme v3 (Key Rotation Support): Introduced in Android 9.0 (Pie). Scheme v3 operates identically to Scheme v2 in terms of block layout and whole-file hashing, but introduces a signing lineage attribute that allows apps to rotate their cryptographic signing keys across releases.
• Scheme v3.1 (Targeted SDK Key Rotation): Introduced in Android 13. Enables developers to maintain key rotation for newer OS levels while targeting legacy keys for older Android versions, avoiding compatibility fragmentation.

Top Causes of Signature Failures During APK Recompilation

When you decompile an APK using tools like Apktool or online suites, modify Smali bytecode, and recompile it, the original signature is invalidated. Here are the primary reasons subsequent installations fail on modern Android builds:

1. The Critical Order: Running zipalign After apksigner

The single most frequent mistake in manual reverse-engineering workflows is running zipalign after signing with apksigner. Because Schemes v2 and v3 calculate cryptographic hashes over the entire file structure (including the Central Directory and uncompressed payload offsets), running zipalign post-signing mutates byte offsets, immediately invalidating the whole-file digest.

The required sequence must always be:

apktool b (Recompile) → zipalign (Align Bytes) → apksigner (Cryptographic Signature)

2. Android 15+ 16KB Page Alignment Incompatibilities

Starting with Android 15, devices supporting 16KB memory pages enforce strict 16KB alignment (16384 bytes) on uncompressed native shared libraries (.so files) inside the APK. If uncompressed native binaries are not aligned properly prior to signing, the package manager rejects the installation immediately.

# Incorrect legacy alignment for 16KB-ready runtimes:
zipalign -v 4 app-unsigned.apk app-aligned.apk

# Modern 16KB page alignment required for Android 15+:
zipalign -v -p 16384 app-unsigned.apk app-aligned.apk

3. Deprecated Cryptographic Algorithms and Small Keys

Android 14+ and 16 refuse to install packages signed exclusively with weak digests such as MD5 or SHA-1, or RSA keys shorter than 2048 bits. When generating ad-hoc debugging Keystores, configuring a 2048-bit RSA key or a 256-bit ECDSA key using SHA-256 is mandatory.

Diagnosing APK Signatures Using apksigner

The Android SDK provides the authoritative diagnostic tool: apksigner. Never rely solely on jarsigner, as jarsigner is completely blind to Schemes v2, v3, and v4.

To inspect why a target APK is failing verification on a test device, execute the following diagnostic command:

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

A typical error output for a misaligned or corrupted signature looks like this:

DOES NOT VERIFY
ERROR: APK Signature Scheme v2 signer #1: APK integrity check failed. Signature did not verify.
ERROR: Verification failed against API level 34
Signer #1 certificate DN: CN=Android Debug, O=Android, C=US
Signer #1 certificate SHA-256 digest: a1b2c3d4e5f6...

If you see APK integrity check failed, the ZIP archive layout was modified after the v2 block was generated (such as running zipalign or modifying a resource inside the archive via standard ZIP utilities).

Step-by-Step Guide: Generating Keys, Aligning, and Signing

Step 1: Generate a Robust Signing Keystore

Create a dedicated debug keystore using RSA 2048 or EC with standard SHA-256 signing parameters:

keytool -genkeypair -v \
  -keystore custom_debug.keystore \
  -alias security_alias \
  -keyalg RSA \
  -keysize 2048 \
  -validity 10000 \
  -storepass password123 \
  -keypass password123 \
  -dname 'CN=SecurityResearch, OU=Auditing, O=APKToolStudio, C=US'

Step 2: Align the Recompiled APK

Run zipalign on the recompiled package produced by Apktool. Pass the -p flag to ensure page-alignment of shared libraries for modern Android versions:

zipalign -v -p 16384 app_recompiled_unsigned.apk app_aligned.apk

Verify that the alignment succeeded:

zipalign -c -v -p 16384 app_aligned.apk

Step 3: Sign with apksigner (Enforcing Schemes v2 & v3)

Explicitly instruct apksigner to enable Scheme v2 and Scheme v3 while targeting the required minimum SDK:

apksigner sign \
  --ks custom_debug.keystore \
  --ks-key-alias security_alias \
  --ks-pass pass:password123 \
  --key-pass pass:password123 \
  --v1-signing-enabled true \
  --v2-signing-enabled true \
  --v3-signing-enabled true \
  --out app_final_signed.apk \
  app_aligned.apk

Step 4: Verify the Final Package

apksigner verify --verbose app_final_signed.apk

The terminal should confirm that all desired schemes are active:

Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): true
Verified using v4 scheme: false
Number of signers: 1

Eliminating CLI Headaches with APKTool Studio

Maintaining exact Java runtime paths, Android SDK build-tools versions, and memory-alignment parameters across local machines can be cumbersome when performing dynamic analysis or reverse engineering. For engineers seeking a fast, zero-configuration workflow, APKTool Studio provides an online, browser-based suite that automates the entire decompilation, Smali editing, and signing pipeline.

When you decompile an APK in APKTool Studio, modify manifest permissions or injected Smali bytecode, and trigger rebuild, the platform automatically:

• Rebuilds the DEX and resource tables with proper public.xml indexing.
• Executes 16KB-aware zipalign formatting suitable for Android 15 and 16 emulators and physical hardware.
• Applies modern v2/v3 signatures with high-entropy cryptographic keys, eliminating INSTALL_PARSE_FAILED_NO_CERTIFICATES errors out of the box.

Auditing In-App Signature Checks in Smali Bytecode

When analyzing protected applications, apps frequently implement self-integrity checks by inspecting their own signing certificate at runtime. If the application detects a mismatch between the developer's original certificate digest and your test keystore, it may trigger an intentional crash or exit.

In modern Android apps using PackageManager.GET_SIGNING_CERTIFICATES (API 28+), the verification logic commonly appears in Smali bytecode as follows:

# Invoking PackageManager to retrieve SigningInfo
const/high16 v1, 0x8000000 # GET_SIGNING_CERTIFICATES flag
invoke-virtual {v0, p1, v1}, Landroid/content/pm/PackageManager;->getPackageInfo(Ljava/lang/String;I)Landroid/content/pm/PackageInfo;
move-result-object p2

# Accessing the signingInfo field
iget-object p2, p2, Landroid/content/pm/PackageInfo;->signingInfo:Landroid/content/pm/SigningInfo;
invoke-virtual {p2}, Landroid/content/pm/SigningInfo;->getApkContentsSigners()[Landroid/content/pm/Signature;
move-result-object p2

# Calculating SHA-256 digest of Certificate bytes
const/4 v1, 0x0
aget-object p2, p2, v1
invoke-virtual {p2}, Landroid/content/pm/Signature;->toByteArray()[B
move-result-object p2

# ... Integrity comparison branch
if-eqz v2, :cond_tampered

When auditing such implementations for defensive resilience, verify that your applications validate the entire certificate lineage via SigningInfo.hasMultipleSigners() and SigningInfo.getSigningCertificateHistory() rather than naive single-element array indices, ensuring complete resilience against rogue downgrade techniques.

Conclusion and Best Practices for 2026

Ensuring that an APK complies with Android's strict cryptographic verification rules is no longer optional. When analyzing, auditing, or maintaining decompiled Android applications in 2026, adhere to these three core rules:

• Never skip zipalign, and never run it last: Ensure 16KB alignment runs strictly prior to apksigner.
• Target both v2 and v3 schemes: Keep v1 enabled only if backward compatibility with Android 6.0 and below is mandatory.
• Audit signature pipelines using official tooling: Run apksigner verify --verbose in CI/CD or leverage automated cloud environments like APKTool Studio to guarantee compliant, ready-to-test packages.