Quick answer: every APK must be signed with a cryptographic key before Android will install it, and every later update must be signed with the same key or the update is refused. The free tier signs your APK with the builder's key, which is fine for direct installs. Google Play requires a key of your own; Pro lets you upload or generate a keystore, and Play App Signing then keeps a copy so a lost key does not strand the app.
What the signature does
A signature proves that an APK has not been altered since it was built, and that whoever built the update is whoever built the original. Android checks the first at install time — a tampered file fails — and the second at update time: a new APK with the same package name installs over the old one only if the certificates match. That second check is the one you feel. It is why an app rebuilt with a different key shows "App not installed" until the old one is removed, and why the key must be kept for as long as the app exists.
Keystore, key, certificate
A keystore is a password-protected file (.jks or .keystore) that holds one or more keys, each with an alias and its own password. Each key has a certificate — the public half that ends up in the APK. Three things identify a signing identity, and you need all three to sign: the file, the keystore password, and the key alias with its password. Lose any of them and the key is gone.
The free tier: the builder's key
Free builds are signed with a key the builder holds. The APK installs on every phone, works offline, and updates correctly as long as you keep building through the same builder with the same package name — the key is stable. What you cannot do with it is publish on Google Play, because Play ties the upload key to your developer account and will not accept a key it has seen used by other accounts. For testing, internal apps, kiosks and client previews, the shared key is exactly right.
Pro: your own key
Pro builds can be signed with a keystore you upload, or one the builder generates for you and gives you to download. Use it when:
- You are publishing on Google Play (required).
- You want to be able to rebuild the app elsewhere — Android Studio, another service — and still update existing installs.
- Your organisation requires control of the signing identity.
Keep the file and both passwords somewhere that survives a lost laptop: a password manager with file attachments, an encrypted backup, a second copy in a safe. There is no recovery from a lost keystore except Play App Signing.
Play App Signing
When you first upload an AAB, the Play Console offers Play App Signing, and you should accept it. Google generates the app signing key that end users' installs are verified against, keeps it in its own infrastructure, and re-signs each build you upload. The key you hold becomes an upload key — if it is lost or stolen, you prove your identity to Google and register a new one, and users are unaffected. Without Play App Signing, a lost key ends the app. The Play guide covers the enrolment step.
Signature schemes, briefly
Android has versioned signature formats — v1 (JAR signing), v2, v3, v4. The builder signs with the schemes each Android version expects, so this is invisible to you; it is mentioned because "signature scheme" appears in Play Console messages. You never choose one.
Symptoms of a signing problem
| Symptom | Meaning | Fix |
|---|---|---|
| "App not installed" when updating | New APK signed with a different key than the installed one (or same versionCode) | Uninstall the old one; or rebuild with the original key |
| Play: "upload key does not match" | AAB signed with a different key than the first upload | Sign with the registered upload key, or request an upload-key reset |
| Play: "APK signed with a debug certificate" | Test key used | Not applicable to builder output; use Pro with your keystore |
| Data lost after update | Different key and the old app was uninstalled first, so it was a fresh install | Same key, install over the top |