Skip to main content
Every app on Google Play must be signed with a cryptographic key. Google uses that key to prove each update came from the same developer as the original release. Newly generates the key for you as step 3 of the AAB build wizard — but you have to download and keep it.
This is the one step in the Android flow you cannot redo. If you lose your signing key, you can never publish another update to that app on Google Play. Your only option is to publish a brand-new app under a new package name and ask your users to reinstall. Back the files up somewhere you will still have access to in five years.

​
Where this happens

When you choose the AAB target in the Deploy modal, you go through a four-step wizard: You cannot advance past step 3 until both key files are downloaded. This is deliberate.

​
First build — generating a new key

If your project has no key yet, Newly generates one automatically when you reach step 3, then shows two download buttons. Both are required to continue:
1

Download Keystore (.p12)

Saves release-keystore.p12 — the key itself. The button turns green and reads “Keystore Downloaded ✓” once saved.
2

Download Credentials (.txt)

Saves keystore-credentials.txt — the passwords and alias needed to use the keystore. The .p12 file is useless without it.
3

Continue

The Continue button stays disabled, with “Download both files to continue” underneath, until both downloads are done.
Store both files together, in a password manager or an encrypted backup — not just your Downloads folder. Losing either one has the same effect as losing both.

​
What’s in the files

The keystore is a standard PKCS#12 container holding a 2048-bit RSA key and a self-signed certificate valid for 25 years. The credentials file records everything you’d need to use the keystore in any other Android toolchain: Because it’s a standard format, this key isn’t locked to Newly. You can use it with Android Studio, Gradle, or EAS if you ever move your project elsewhere.

​
Later builds — reusing your existing key

Newly stores your key with the project, so returning to step 3 shows “Existing Signing Key Found” along with the date it was created, and two choices:
Loads the key that’s already on file and signs the new build with it. Google Play accepts the upload as an update to your existing app. You can still download backup copies of the .p12 and .txt from this screen — worth doing if you never saved them.
Replaces the key on file. Newly shows a red confirmation warning first, because the consequence is permanent: builds signed with a new key can no longer update your existing Play Store app. Google will reject the upload.Only do this if you’re starting a genuinely new app that has never been published.

​
Your key belongs to one project, not to your app

Signing keys are stored per Newly project. If you duplicate your project — or rebuild your app in a new one — the copy starts with no signing key, and the AAB wizard silently generates a fresh one. The resulting .aab is signed with the wrong key, and Google Play rejects it.
This is the most common way people end up locked out of their own app, and it doesn’t look like a mistake while it’s happening: the duplicate project builds cleanly, and the problem only surfaces at upload time.

​
If you already built from a duplicate project

The key you need is still in your original project. The new project’s certificate is not a substitute — Google only accepts the key your first release was signed with.
1

Confirm the original project still has the key

Open the original project, start an AAB build, and go to step 3. It should show “Existing Signing Key Found” with a creation date.
2

Download the backups while you're there

Save the .p12 and credentials .txt now, whatever else you decide to do.
3

Build from the original project

Port your changes back into the original project and build the AAB there, choosing Use Existing Key. This is the only fix you can do entirely on your own.
There’s currently no way to import a keystore into a different project from the UI. If moving your changes back isn’t practical, contact support — the key can be migrated between your projects on our side. Have both project names ready.
Planning to work in a duplicate? Keep publishing from the original project, or sort the key out before you build, not after.

​
Upload key vs. app signing key

Google Play runs Play App Signing on all new apps. It’s worth understanding which key is which:
  • The key Newly generates is your upload key. You sign your AAB with it, and Google verifies it on upload to confirm the release is really from you.
  • Google holds the app signing key — the one that actually signs the APKs delivered to users’ devices. Google generates and stores this on first release.
The practical consequence: if you lose your upload key, Google Support can reset it, because they still hold the app signing key. It’s a manual support process and it takes time — treat it as a last resort, not a plan.

AAB, keystores and Play App Signing explained

Longer background on Android App Bundles, signing, and how Play App Signing works.

​
Common problems

The AAB was signed with a different key than your first release. Two common causes:
  1. You built from a duplicate or new project. Keys don’t travel with a copied project — see Your key belongs to one project above. Build from the original project instead.
  2. Someone clicked Generate New Key on step 3. Rebuild using Use Existing Key.
If the original key is genuinely gone, you’ll need to request an upload key reset from Google Play support.
Check whether the key is still on file in your project — open the AAB wizard and go to step 3. If it shows “Existing Signing Key Found”, download the backups immediately. If it doesn’t, and your app is already published, contact Google Play support to request an upload key reset.
The Continue button unlocks only after both the .p12 and the .txt have been downloaded. If you dismissed a browser download prompt, click the button again — the label shows a green checkmark once a file has actually been saved.
No. The APK target is for testing and sideloading, and doesn’t take you through the signing wizard. Only the AAB target — the format Google Play requires — needs your release key.

App Deployment

How Newly builds APKs and AABs

Google Play Setup

Connecting your Google Play Console account

App Store Submission

The full start-to-finish submission walkthrough

Changing your Bundle ID

Why your package name is hard to change later