Sign a protected Android release the same way as any release, with one rule held firmly: every change to the package is finished before the final signature. Sign an Android App Bundle with jarsigner and your upload key; sign a directly distributed APK with apksigner after zipalign. Then verify the package users actually receive, and test installation and an update from the previous release. Otukan Application Security fits your existing build and release pipeline, and your signing keys stay with you. This guide covers Android only; iOS signing is a separate procedure.
Artefacts, tools and key authority
Record the application ID, version, framework, build tools, protection configuration and distribution channel. Keep an unprotected baseline from the same commit. The question that matters is which signed artefact reaches a device, not whether the build job turned green.
Two signing paths
| Path | Who signs what | Tool | Verify |
|---|---|---|---|
| App Bundle with Play App Signing | You sign the AAB with the upload key; Google signs the APKs it delivers with the app signing key | jarsigner | The upload certificate, then the APKs Play delivers |
| Direct APK distribution | Your release process signs the final APK | zipalign, then apksigner | The exact signed APK and its update behaviour |
An AAB is signed with the JAR scheme, which is why jarsigner is the tool; apksigner is for APKs only. Under Play App Signing the certificate on a user’s device is the app signing key, not your upload key. Play Console’s app signing page shows the SHA-256 fingerprints of both. Record both, and build any certificate check in the app around the app signing key.
Otukan’s integrity checks are bound to the signing identity users install, including Play App Signing, and Otukan’s engineers update those expectations with you when the certificate changes.
Signature schemes
APKs carry one or more signature schemes. v1 is the JAR scheme. v2, from Android 7.0, signs the whole file. v3, from Android 9, adds a proof-of-rotation lineage so an app can move to a new signing key. v4, from Android 11, is a separate .idsig file used for incremental installs.
apksigner chooses schemes from the app’s minSdkVersion. Override that with --min-sdk-version only when signing outside the normal build, and use the same flag with apksigner verify to confirm the APK verifies across the range you support. If minSdkVersion is 24 or higher, v1 is not needed.
Assign an authorised signer and an independent release reviewer. Keep keystore passwords out of shell history, logs and issue trackers, and never attach a keystore to a support request.
Produce and verify the signed artefact
Order of operations
- Build the release from a recorded commit and configuration.
- Complete every change to the package: code shrinking, resource processing and protection. Record what goes in and comes out of each step.
- For an APK, run
zipalign. For an AAB, skip this; Play aligns the APKs it generates. - Sign. Nothing may modify the file afterwards: a change after signing invalidates the signature.
- Verify the signed file and store it with its hash in the release record.
Native libraries and 16 KB page sizes
Android 15 introduced support for devices that use 16 KB memory pages. Since 1 November 2025, Google Play requires new apps and updates that target Android 15 or higher and include native code to support 16 KB page sizes. Two things must be true. The .so files must be linked with 16 KB ELF segment alignment, which recent NDK releases do by default. And uncompressed native libraries inside an APK must sit on 16 KB boundaries, which zipalign -P 16 handles. Check both on the final protected package, not only on the unprotected build.
Direct APK path
A local example with illustrative filenames. Use your approved credential mechanism rather than typing secrets:
zipalign -P 16 -f -v 4 app-protected-unsigned.apk app-protected-aligned.apk
apksigner sign --ks release.jks --out app-protected-signed.apk app-protected-aligned.apk
apksigner verify --verbose --print-certs app-protected-signed.apk
--verbose reports which schemes verified; --print-certs prints the signing certificate digests. Compare them with the approved release identity.
App Bundle path
A local example with illustrative names:
jarsigner -keystore upload.jks app-protected.aab upload
jarsigner -verify -verbose app-protected.aab
Upload through your usual workflow, then test the APKs Google generates. An internal testing track gives you the delivered packages; bundletool build-apks lets you inspect splits locally, signed with a key you choose, which is not the Play signature.
Record the delivery variant and certificate digest alongside the protection configuration, so a signing mismatch can be told apart from a detection.
Installation, updates and release acceptance
Test on physical devices in your agreed Android and manufacturer matrix. Start with a fresh installation, then update from the previous legitimate release through the intended channel. Keep app data where the update should keep it, and check sign-in, session renewal and the sensitive user flow.
Treat key rotation as its own test. On the direct path, apksigner rotate builds the v3 lineage that lets devices accept the new key as the successor to the old one. Under Play App Signing, key upgrade is requested in Play Console. Never replace a key to make a failing lab install pass.
Run an authorised test of the integrity control with a copy re-signed by a different key and record the expected signal. If Android rejects the package before the app starts, record platform signature enforcement, not an app-side detection.
Release record
- Application, protection, tool and configuration versions are recorded.
- Signing authority and expected certificate digests match the channel.
- Signature verification passes for the delivered APKs across the supported SDK range.
- Native libraries meet 16 KB alignment in the final package.
- Fresh installation and updates work across the device matrix.
- Sign-in and the sensitive flow pass legitimate-use regressions.
- Release recovery has an owner and a tested procedure.
Stop promotion if signature verification, update continuity or a required flow fails, and find the failing stage before changing protection or signing policy.
Broader platform scope is covered on Android app security. More guides on signing, attestation and runtime signals are in the mobile security knowledge base.
Further reading
- Sign your app — Android Developers
- apksigner — Android Developers
- zipalign — Android Developers
- Support 16 KB page sizes — Android Developers
- APK signature scheme v3 — Android Open Source Project