Type paths and options. We print keytool, zipalign, apksigner, and legacy jarsigner blocks. We do not create a keystore, we do not sign bytes, and Play App Signing will still change the APK testers install.
Adjust the form to generate commands.
Use it to produce a repeatable script: keytool (new upload key), zipalign, apksigner sign, apksigner verify.
Use it when you are documenting a machine that already has JDK + SDK build-tools on PATH.
Do not paste production keystore passwords into this form on a shared screen. Do not expect the SHA-256 from the APK Analyzer on your unsigned or upload-signed file to match the Play-delivered APK. Play App Signing re-signs what users install.
Fields become quoted path arguments. POSIX vs Windows CMD changes quoting only. Primary signer apksigner vs jarsigner
switches the sign/verify block. We never read an APK and we never call keytool.
Typical order: align the unsigned APK, sign with v2/v3 via apksigner, verify. jarsigner is v1-era; keep it only for a documented legacy pipeline.
Unsigned app-release-unsigned.apk, aligned output, then:
zipalign -p -f -v 4 app-release-unsigned.apk app-release-aligned.apk apksigner sign --ks upload.jks --out app-release-signed.apk app-release-aligned.apk apksigner verify --verbose app-release-signed.apk
Compare the signed file’s hash in the analyzer to CI. After Play processing, compare testers’ install against Play’s app-signing certificate, not your upload key. Full write-up: Why desk SHA-256 ≠ testers’ SHA-256.
.jks because “it is only the upload key.”Play App Signing hashes · APK Analyzer · Publishing checklist
No. Command text only. You run it locally.
Android SDK build-tools/<version>/.
No. Strings stay in the tab. Prefer env vars when you run the script.