A keystore backup is four things, and the file is only one of them.
An Android keystore is a binary file holding private keys and their certificates, so backing one up means copying the file plus its password, the key alias and that key's own password. Miss any of the four and you have a file you cannot open. What the loss costs you depends entirely on which key was in there. If you manage your own app signing key, Android's documentation says plainly that you cannot regenerate it and you cannot update the app. If the app is on Play App Signing, Google holds that key and a lost upload key is a reset request. Every figure and screen name below comes from Google's and Android's own pages, read on 21 October 2026. Most people meet this file on the way to a release, which is also where the iOS half, publish to app store, comes in.
What follows is what is really inside the file, the exact wording Android uses about losing it, what Play App Signing does and does not rescue, and the four line backup that would have saved most of the people who have asked this question.
Start hereThe short version
Copy the file, the alias and both passwords, then check who holds the key.
Android calls the four items together a signing configuration: the keystore location, the keystore password, the key alias and the key password. That is the backup. A copy of the file on its own is a locked box, and the passwords are the part nobody writes down, because Android Studio asked for them once and never again.
The cost of losing it splits on one question: who holds the app signing key. Hold it yourself and the documentation is blunt about the outcome, which is that the app in that listing can never be updated again. Let Google hold it through Play App Signing and the thing you can lose locally is the upload key, which is resettable by request. The rumour that a lost keystore kills the app is correct, and it is correct for one of those two cases, not both.
What is actually inside an Android keystore file?
Private keys and certificates, nothing else. Android's signing documentation describes a Java keystore, extension .jks or .keystore, as a binary file that holds certificates and private keys. A public key certificate, a .der or .pem file, carries the public half of a key pair along with details identifying the owner, such as a name and a location. The certificate is safe to hand out. The private key is the half that signs, and the half you can lose forever. If that distinction is still fuzzy, the code signing certificate types breakdown takes the whole family apart before you start copying files around.
Two keys matter, and they do different jobs. The app signing key is the one used to sign the APKs installed on a user's device, and Android says it never changes during the lifetime of your app. The upload key is the one you use to sign the app bundle or APK before you hand it to Google Play, so that Google can verify your identity. If you let Google generate the app signing key when you opt in, the key you signed your first release with becomes your upload key. Google's own tip is to keep the two different.
The dialog that creates one tells you exactly what is being stored. Android Studio asks for a key store path ending in .jks, a keystore password, a key alias, a key password, a validity in years, and some certificate details about you that never show up in the app. Two of those fields have numbers worth getting right. Android recommends a validity period of 25 years or more, so the same key can sign updates for the life of the app. And there is a hard floor for the store: if you plan to publish on Google Play, the key you sign with must have a validity period ending after 22 October 2033. That page carries its own last updated date of 6 March 2026, and it still said so when it was read on 21 October 2026.
Google Play adds format requirements on top. Play Console Help, read on 21 October 2026, says the upload key must be an RSA key of 2048 bits or more, that app signing keys Google generates are RSA 4096 bit, and that a custom app signing key must be RSA 2048 bit or higher. One more naming trap before you search for anything: Android also uses the word keystore for the Android Keystore system, an on-device container that apps use at runtime to hold keys whose material stays non-exportable. That is a different subject with the same name, and it is not a file you can back up.
Android Developers, sign your app, last updated 6 March 2026, read 21 October 2026
What does Android's documentation say happens if you lose it?
It says you cannot update the app, and it says so without hedging. The signing page states that your private key is required for signing all future versions of your app, that if you lose or misplace your key you will not be able to publish updates to your existing app, and that you cannot regenerate a previously generated key. A separate paragraph on managing your own key repeats the consequence from Google's side: if you lose access to your app signing key or it is compromised, Google cannot retrieve the app signing key for you, and you will not be able to release new versions of your app as updates to the original app.
This is worth saying clearly, because the usual pattern with these pages is that the thing everybody repeats turns out to be a year out of date. Not here. The widely repeated warning matches what Android publishes today, in the same words, on a page that was last updated in March 2026.
The mechanism behind it is the update check, and knowing it tells you what the loss actually costs. When Android installs an update it compares the certificates in the new version with the ones in the installed version, and allows the update only if they match. Sign the new version with a different certificate and you must give the app a different package name, and the user then installs it as a completely new app. You still have the code, so the bill lands somewhere else: the install base, the reviews, the rating and every link anyone ever made to your listing. Picking that new name costs you something too, and the bundle identifier rules are stricter than most people expect once an app has shipped once.
There is one more reason the same certificate matters past updates. Android lets APKs signed by the same certificate run in the same process if they ask to, and it enforces signature based permissions, so an app can expose functionality only to another app signed with a specified certificate. A team that shares data between two of its own apps has tied both of them to one key. Lose it and both apps stop, including the one nobody was about to release.
Work out the damage
Which one went missing?
Pick what you cannot find. Two of these end the app in its current listing. The rest cost you an afternoon.
Nothing picked. If you can still sign a release build today, this is a good hour to find out where that file lives and who else has a copy.
Based on Google and Android documentation read on 21 October 2026, not a promise about your account.
Does Play App Signing change that answer?
Yes, for one specific key and not for the habit. With Play App Signing, Google manages and protects the app signing key on the same infrastructure it uses to store its own keys, protected by its Key Management Service. Android states the comparison itself: for apps that have not opted in, losing the app signing key means losing the ability to update the app. Opting in moves the unrecoverable item out of your hands. It also makes it unrecoverable for you in the other direction, because once Play App Signing is configured you cannot retrieve a copy of your app's signing key, and Google may retain a backup copy of it for disaster recovery purposes.
The upload key is the one you still hold, and it is the one with a recovery path. Play Console Help, read on 21 October 2026, says that if you lose your upload key or suspect it was compromised you are not locked out of your app. You create a new upload key in Android Studio, export its certificate to PEM with keytool, using the form keytool -export -rfc with your keystore, alias and output file, then submit the reset request in the Play Console. Android's page adds the reassurance that matters: resetting your upload key does not affect the app signing key Google uses to re-sign APKs before delivering them to users.
Two practical cautions. Configuring Play App Signing needs admin permission on the Play Console account, so a solo developer is fine and a contractor may not be. And the menu path is not stable across Google's own pages. The Android Studio page points at Release, then Setup, then App signing. Play Console Help points at Protected with Play, then Play Store distribution, then Go to Play app signing, and then in its own reset steps at Protected with Play, then Play Store protection, then Manage Play app signing. All three were read on 21 October 2026. Search the console for the words App signing rather than trusting any one of those paths.
For a new app the decision is mostly made for you. Android's signing page says Play App Signing is required to sign apps distributed through Google Play, with a carve out for apps created before August 2021, which may carry on distributing self signed APKs. Play Console Help goes further on what a new app gets today: it is automatically enrolled in quantum ready hybrid signing with Google generated keys, which combines a classical RSA 4096 bit key with a post quantum ML-DSA-65 key, plus a separate classical key for devices on Android 16 and below, so the app ends up using three distinct keys. You hold none of them, and you register all of their fingerprints with any API provider that authenticates your app, because providers check the key Google signs with and not your local upload key.
So what goes in the backup, and what can you let go?
Four items, kept in two places. The keystore file, the keystore password, the key alias and the key password are what Android calls a signing configuration, and all four have to survive together. Keep the passwords somewhere other than the folder holding the file, so that one leaked archive is not a signing identity. Android's signing page, the source for the previous two sections, also tells you to pull your signing details out of your Gradle build files, where they otherwise sit in plain text, into a keystore.properties file holding storePassword, keyPassword, keyAlias and storeFile, and to keep that file out of source control. That advice is good and it creates the gap people fall into, because a backup of the repository then misses the only copy of the passwords.
Some of the files in this story need no protecting at all, and knowing which ones keeps the backup small. The debug keystore is the obvious one. Android Studio creates it at $HOME/.android/debug.keystore on your first run or debug and sets its passwords for you, its certificate expires 30 years from its creation date, and the documented fix when that expiry breaks your build is to delete the file and let Android Studio write a new one. Most stores including Google Play refuse apps signed with a debug certificate, so there is nothing in it to keep. Certificates and fingerprints are the other case. You can download the app signing and upload certificates from the Play Console, and they are meant to be handed out, because they carry the public half of a key pair and no private key. The work with those is registering the right ones with your API providers, and never hiding them.
If you have inherited a keystore from someone else, check two things before you trust it. Open it and read the validity period against that 22 October 2033 floor, because a key made years ago by someone following a short tutorial may already fail it. Then check whether the app is on Play App Signing, which tells you whether the file in your hands is an upload key you can reset or an app signing key you cannot. Apple keeps its equivalent credentials somewhere else again, behind the app store connect api, so a team shipping to both stores has two sets of secrets to keep and two different recovery stories.
One habit is worth more than any backup tool here. Before every release, have someone who is not you sign a build from the backup copy, on a machine that has never had the original. A restore you have never tested is a belief, and the day you find out it was wrong is the day the documentation stops offering you options.
The inventory, and whether anything can replace it
| What it is | Where it lives | Replaceable if lost |
|---|---|---|
| The keystore file, .jks or .keystore | Wherever you put it. Android Studio asks for the path when it creates the file. | No |
| Keystore password | Nowhere by default. You chose it in the New Key Store dialog. | No |
| Key alias | Inside the keystore, readable with keytool or the Gradle signing report. | Yes |
| Key password | Nowhere by default. Android Studio asks you to make it match the keystore password. | No |
| keystore.properties | Project root, and deliberately outside source control. | No |
| Upload certificate, .pem | Exported from the keystore with keytool, or downloaded from the Play Console. | Yes |
| App signing key, on Play App Signing | Google's own key infrastructure, protected by its Key Management Service. | Yes |
| debug.keystore | $HOME/.android/debug.keystore, created on your first run or debug. | Yes |
Replaceable here means replaceable without changing the app your users already have installed. An upload key counts as replaceable only because Google is holding the key that users actually verify.
Where this lands if a builder generated your app
The rules do not soften because an AI wrote the code. Whoever holds the key holds the app, and the store checks a signature and never asks where the code came from. What a builder can change is how much of the signing material you own and can therefore copy, and whether you ever see it at all.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own, with two way GitHub sync so the code sits in your repository rather than inside a product. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, and can build a standalone Android APK. It does not submit to the App Store for you, because Apple requires the owner of the content to be the one who submits. It costs $25 a month, with no free tier.
For keystores that lands in a useful place. A new app published through Google Play is enrolled in Play App Signing, so the key your users verify against is held by Google from the first release and is not in a folder on anyone's laptop. The item that is genuinely yours to lose is the upload keystore, and that one has a reset. The honest limit: no builder can back up a password for you, and the four line signing configuration is still a human writing something down and putting it somewhere that is not the same disk as the file.
Questions people ask about Android keystore backup
It is a binary file that holds private keys and their certificates. Android's signing documentation describes a Java keystore, with a .jks or .keystore extension, as a repository of certificates and private keys. Each private key in it sits under an alias and has its own password, and the file itself has a separate password. The certificate is the public half plus some details about the owner, and it is meant to be shared. The private key is the part that signs your app, and it is the part you cannot replace.
Find the file today, while finding it is still boring
Locate the keystore, write the alias and both passwords somewhere that is not next to it, then sign a build from the copy to prove the copy works. That half hour is the whole of this subject.
Start building