Why signing matters at all
Every Android app is signed with a cryptographic key. The signature is how the OS verifies the app is genuine and unmodified, and, crucially for developers, it is how updates work: an update must be signed with the same key as the original, or the system treats it as a different app and refuses to upgrade it.
Lose the key and you lose the ability to update your published app. There is no recovery and no 'reset'. That single fact drives most of the signing advice you will read.
The keys involved
A keystore (.jks) is the file holding your signing key and its passwords. When you 'sign' an app you sign it with the key inside a keystore.
Play App Signing, which Google recommends and which is required for new apps in most cases, splits this: Google holds the app signing key and generates the optimized APKs; you hold an upload key that only signs the bundles you upload. If your upload key leaks, you can rotate it. If your app signing key leaks, the app's trust is gone.
There is also a debug key, used for development builds. It is not for publishing.
The practical rules
Back up the keystore and passwords somewhere safe, offline. Never share the private key. Keep the same signing setup across rebuilds of the same app. A different key on a 'rebuild' produces an app that cannot update the previous one.
When a tool builds for you, ask what it signs with. An auto-generated keystore per build means every build is a fresh identity, fine for testing, a trap for updates.
How Tapbound handles signing
Android builds use an upload key auto-generated for the app, so the aab you get is a real, signed, publishable bundle. If you prefer to bring your own keystore, you can upload it and your builds are signed with your key. Your choice, both valid.
Either way, a store submission build carries the app's stable identifier, so a later rebuild updates the same listing instead of creating a new app.