Understand what alignment changes
zipalign adjusts the positions of uncompressed data inside the ZIP container so Android can access it efficiently. Native libraries can require page alignment appropriate to the supported environment. This is a packaging concern, not Java bytecode optimization. zipalign documentation.
A smaller APK is not the purpose of this operation. Do not describe alignment as a general compressor or a fix for incompatible native code.
Use the correct order
A local illustrative sequence is:
zipalign -P 16 -f -v 4 unsigned.apk aligned.apk
apksigner sign --ks release.jks --out signed.apk aligned.apk
apksigner verify --verbose --print-certs signed.apk
zipalign -c -P 16 -v 4 signed.apk
Enter signing credentials securely. Check every command's exit status. The final -c operation verifies alignment without modifying the signed output. apksigner.
Let the standard build pipeline do its job
Normal Android Gradle release builds coordinate packaging, alignment and signing. Manual commands are useful for controlled diagnostics or specialized pipelines, but should not be added randomly after every Gradle build.
If a post-processing tool changes the APK, understand exactly where it sits in the pipeline. A valid signature report from before post-processing does not apply to the modified file.
Separate 16 KB packaging from native compatibility
Using -P 16 does not recompile a native library or fix its ELF load-segment alignment. Android's 16 KB page-size guidance also covers toolchain and runtime requirements. Check the actual .so files and execute relevant native paths on the intended environment.
This distinction matters for games and SDK-heavy apps: a neatly aligned archive can still contain an incompatible vendor binary.
Keep final-artifact evidence
Archive only the intended signed output as the release artifact, along with its hash, version and verification logs. Clearly label intermediate unsigned or aligned files so they cannot be accidentally uploaded or distributed.
APKLint's signing metadata view can help identify the output certificate, but it does not replace alignment or cryptographic verification. A production release should be traced to the exact final file, not merely to a successful earlier build step.
Make intermediate and final files unambiguous
Use distinct output paths for the unsigned input, aligned intermediate and signed release. If a pipeline reuses one filename for every stage, an artifact-upload step can accidentally collect the unsigned or stale copy. Record the hash only after the intended final transformation, and attach both the signing-verification result and the read-only alignment check to that hash.
For a controlled local experiment, compare the unsigned and aligned files to observe that alignment can change container bytes without changing the application feature you intended to build. After signing, do not repeat a modifying alignment operation on the final file. Use the check mode shown above when examining it. The zipalign documentation distinguishes these operations and their relationship to signing tools.
Trace a failed check back to the build stage
If the signed candidate fails the required alignment check, identify whether the input was never aligned or whether another step repackaged it afterward. Inspect the order of compression, resource processing, signing and artifact copying. Repair that order in the reproducible build pipeline, then generate and verify a fresh candidate. Renaming the failed file or rerunning only the verifier cannot change its layout.
For native libraries, keep the archive-placement result distinct from the library's ELF compatibility. A check on the ZIP container cannot rewrite a library's compiled segment assumptions. If packaging passes but a feature crashes in a 16 KB environment, collect the native error and follow the native compatibility investigation rather than repeatedly aligning the same archive.
Review your build system's existing behavior before adding manual steps. A standard release task may already perform the required packaging and signing, so an extra post-build rewrite can introduce the very defect you are trying to prevent. The useful release evidence is the final artifact, the relevant check outputs and the recorded pipeline order, all referring to the same bytes.
Sources and further reading
- Android Developers: zipalign
- Android Developers: apksigner
- Android Developers: Support 16 KB page sizes
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
