If you've never shipped an Android app to Google Play before, the signing key part is where a lot of people get quietly stuck. It's not a hard concept, but the way Google documents it makes it feel like you're juggling three different keys that could all brick your release if you mess up.
Here's what actually went wrong for me the first time.
What I thought I was doing
I generated a keystore the way most tutorials tell you. Ran keytool, set a password, saved the .jks file somewhere on my machine, and moved on. Then I signed my release APK with that key, uploaded it, and assumed I was done.
I was not done.
What I missed
Google Play now uses something called Play App Signing. What that means in practice is that Google manages the actual app signing key on their side. The key you generate locally is called your upload key. Those are two different things.
The upload key is what you use to sign the AAB before uploading to Play. Play then strips that signature, re-signs the build with the actual app signing key, and ships it to users.
If you lose your upload key, you can reset it. Annoying, but not fatal.
If you lose your app signing key and Google doesn't have it, your app is done. You can't update it. Users who installed it will stay on that version forever. I didn't know this at the time.
The week I lost
Here's what ate up my week. I signed my first release build with a key. Uploaded the AAB. Rejected, because I hadn't enrolled in Play App Signing yet. Enrolled, re-uploaded. Accepted.
Then I made a small fix a few days later. Signed the new build with what I thought was the same key. Rejected again. The fingerprints didn't match.
Turned out I'd generated a second keystore by accident when I was testing something, and my build gradle was pointing at that one. I spent the better part of an evening trying to figure out which keystore was the real upload key. The one I'd used, the one that was in my backups, or the one gradle was actually loading.
Eventually got it sorted by comparing SHA1 fingerprints against what Play had on file. But that whole mess could have been avoided if I'd understood the upload key vs app signing key distinction from day one.
What I do now
Three things.
First, one keystore per app, named clearly, backed up in two places. I keep the .jks file in a password manager attachment slot and a second copy on an encrypted drive.
Second, I write down the SHA1 fingerprint of the upload key the moment I create it. That way if anything ever looks weird, I can compare against a known-good value instead of guessing.
Third, I let tools handle the signing config for me. This is partly why I ended up building IOn Emit. It handles the upload keystore generation, stores the fingerprint, and keeps the signing config consistent across builds so you don't end up pointing at the wrong file halfway through a release cycle.
Play App Signing is actually a good thing once you understand it. It's just that the docs treat it like you already know the upload key vs app signing key distinction, and nobody explains that clearly until after you've tripped over it.
If you're about to ship your first Android app and this is new to you, the short version is: generate one upload key, back it up, enroll in Play App Signing, and let Google handle the rest. Don't try to keep your own app signing key. That's the old workflow and it's not worth the risk.
Anyway, this is the stuff I wish someone had told me before I spent a week chasing my own tail.
IOn Emit is freemium and handles a lot of this friction for you: https://theionproject.com/ionemit
