When Google Play Console reports that app signing failed, it usually means the artifact you uploaded is not validly signed for Play, and the most common reason is a signing toolchain that ran in the wrong order or used the wrong tool. For an APK, you must run zipalign before apksigner, because any change to the APK after signing, including aligning it, invalidates the signature. Sign with apksigner rather than jarsigner so a modern v2 or v3 signature scheme is applied, since a v1-only signature is not enough for current apps. For an app bundle, you do not zipalign or apksigner the final file at all; you sign the bundle and let Play App Signing produce the delivered APKs. If the error is instead an upload key mismatch, that is an identity problem, not a toolchain one.
Short answer
A signing failure on upload is almost always about how the file was signed, not about your key being wrong. Per Android's apksigner docs, if you sign an APK and then change it, the signature is invalidated, and if you use zipalign you must run it before signing, so the correct order is zipalign, then apksigner. apksigner also applies the v2, v3, and v4 schemes that Play expects, which jarsigner cannot, so use apksigner. For an app bundle, per Android's app signing docs, Play App Signing generates and signs the delivered APKs, so you sign the bundle and skip the APK alignment and signing steps entirely.
What app signing failed means in Play Console
When Play Console says signing failed, it is telling you that the uploaded artifact did not pass its signature validation, which is a gate every upload goes through. Play checks that the file is signed with a valid scheme, that the signature actually verifies against the contents, and that it matches the key Play expects for your app. A failure means one of those checks did not pass, and the message is your prompt to work out which.
There are two broad families behind the same wording. One is a toolchain problem, where the artifact is not correctly signed, because it was aligned after signing, signed with the wrong tool, signed only with the old scheme, or built with a debug key. The other is an identity problem, where the file is validly signed but with a key that does not match your app's expected upload key. The focus here is the toolchain family, since that is what most build-side signing failures are; the key-mismatch case is a separate fix about which key you used.
ZipAlign or apksigner: which, and in what order
These are two different tools that both touch the APK, and confusing their order is a leading cause of signing failure. zipalign aligns the APK's data for efficient loading, and apksigner signs it. The order is not interchangeable: per Android's documentation, if you use zipalign you must use it before signing the APK, because signing with apksigner and then making any further change, alignment included, invalidates the signature. So the pipeline is build, then zipalign, then apksigner, and nothing that alters the file after that.
The classic failure is running zipalign after apksigner, which produces an APK whose v2 or v3 signature no longer matches the now-modified file, so Play rejects it as improperly signed. If your build script or CI does its own alignment step at the end, that is very likely the cause. The fix is to reorder so alignment happens before signing, or, more simply, to let the Gradle signing config handle both, since Gradle aligns and signs in the correct sequence for you.
Use apksigner, not jarsigner: V1 versus V2
The other toolchain cause is the signing tool itself, which is where the V1 versus V2 question comes in. jarsigner is the old JAR signing tool and it can only produce a v1 signature, the original scheme that signs individual files inside the archive. apksigner, from the Android build tools, produces the v2, v3, and v4 schemes, which sign the whole APK and are what modern Android and Google Play rely on. A v1-only artifact, or one signed with jarsigner, is a common reason a build is treated as not properly signed.
So the tool you sign with determines which schemes are present, and you want apksigner. By default apksigner uses your minSdkVersion and maxSdkVersion to decide which schemes to apply, so it adds the right ones automatically for your app's range. If you sign manually, replace any jarsigner step with apksigner; if you build with Gradle, the release signing config already uses the correct signing internally. Either way, ensuring a v2 or higher signature is present is what clears this class of failure.
App bundles are signed differently
If you upload an Android App Bundle rather than an APK, applying APK signing steps to it is itself a mistake, because the bundle is not the file users install. With Play App Signing, you sign the bundle with your upload key, and Google generates and signs the actual delivered APKs with the app signing key it holds. So there is no zipalign step and no apksigner step on a final APK in this flow; those tools operate on APKs, not on the AAB.
This trips people who move from building APKs to building bundles and carry their old signing commands along. The result is either a signing error or wasted effort aligning and signing something Play is going to re-sign anyway. For a bundle, let Gradle sign it with your upload key and let Play App Signing take it from there, and reserve zipalign and apksigner for the case where you are genuinely producing a standalone APK.
Common causes and fixes at a glance
Matching the failure to its cause points you at the fix. The table below maps the common ones.
| Cause | Why signing fails | Fix |
|---|---|---|
| Aligned after signing | Change after apksigner invalidates the signature | zipalign before apksigner |
| Signed with jarsigner | Only a v1 signature is produced | Sign with apksigner for v2 or higher |
| v1-only signature | Missing the whole-file scheme Play expects | Enable v2 and v3 signing |
| Built with a debug key | Debug-signed artifacts are rejected | Sign with your release or upload key |
| Modified the AAB with APK tools | Bundle is not an installable APK | Sign the bundle; let Play App Signing sign APKs |
Read the first two rows first, since aligning after signing and using jarsigner are the two most common build-side signing failures.
Verify your signature before uploading
You can catch a signing failure on your own machine before Play does by verifying the artifact after your build. For an APK, run apksigner verify with the print-certificates option, which confirms the signature verifies and shows which schemes are present and which certificate signed it, so you can see at a glance whether v2 is there and whether the key is your release key rather than a debug key. A file that fails apksigner verify will also fail in Play.
Confirm the identity as well as the validity. Check that the certificate fingerprint matches the upload key Play expects for your app, so you catch a wrong-key situation locally instead of after a rejected upload. For an app bundle, verify through your Gradle build output and the Play Console upload feedback rather than APK tools. Verifying before uploading turns a slow round trip through Play into a fast local check.
Fix checklist
Working through these steps clears most signing failures. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Fix the order | Run zipalign before apksigner, never after | [ ] |
| Use the right tool | Sign with apksigner, not jarsigner | [ ] |
| Enable modern schemes | Ensure v2 and v3 signatures are applied | [ ] |
| Use the release key | Confirm the build is not debug-signed | [ ] |
| Handle bundles correctly | Sign the AAB and let Play App Signing sign APKs | [ ] |
| Verify locally | Run apksigner verify before uploading | [ ] |
The step teams skip most is verifying locally, because a quick apksigner verify catches every one of these before the upload does.
When it is really an upload key mismatch
One honest caveat: not every signing failure is a toolchain problem. If your artifact is correctly signed but with a key that does not match the upload key Play has on record, the fix is not reordering tools but using the right key, or requesting an upload key reset if the key is lost. That case shows up as a key or certificate mismatch rather than an invalid-signature error, and it is resolved separately from the alignment and scheme issues covered here.
So read the exact message. If Play complains that the signature is invalid or the APK is not signed with a required scheme, you are in the toolchain family addressed here. If it says the certificate does not match the expected upload certificate, you are in the identity family, and the fix lives with your keys and Play App Signing rather than with zipalign and apksigner.
Where a scan fits
A signing failure is a build problem, so a scanner does not fix it, but once your artifact signs cleanly it is worth checking that your signing setup is not leaking secrets.
A scanner like PTKD.com analyzes your build and flags issues such as keystores or signing passwords committed into the repo, hardcoded secrets, and over-broad permissions by severity, mapped to OWASP MASVS. To be clear about the boundary: PTKD does not sign your app or reorder your build steps. It helps confirm that the signing credentials you just got working are stored safely rather than sitting in the project where they can leak.
What to take away
- App signing failed in Play Console usually means the artifact is not validly signed, most often from a toolchain order or tool mistake rather than a bad key.
- Run zipalign before apksigner, because any change after signing, including alignment, invalidates the signature.
- Sign with apksigner, not jarsigner, so a v2 or higher scheme is applied, since a v1-only signature is a common cause of failure.
- For an app bundle, sign the AAB and let Play App Signing produce and sign the delivered APKs, without zipalign or apksigner steps.
- Verify with apksigner verify before uploading, and if the message is a certificate mismatch it is a key problem, not a toolchain one; a tool like PTKD.com helps keep signing secrets out of the repo.
