> ## Documentation Index
> Fetch the complete documentation index at: https://docs.newly.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Android Signing Keys

> Generate, download, and safeguard the signing key Google Play requires for every Android release.

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.

<Warning>
  **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.
</Warning>

## Where this happens

When you choose the **AAB** target in the Deploy modal, you go through a four-step wizard:

| Step | What you do                                                       |
| ---- | ----------------------------------------------------------------- |
| 1    | Enter your **bundle identifier** (e.g. `com.companyname.appname`) |
| 2    | Set your **version name and version code**                        |
| 3    | **Generate and download your signing key** ← this page            |
| 4    | Build the AAB                                                     |

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:

<Steps>
  <Step title="Download Keystore (.p12)">
    Saves `release-keystore.p12` — the key itself. The button turns green and reads "Keystore Downloaded ✓" once saved.
  </Step>

  <Step title="Download Credentials (.txt)">
    Saves `keystore-credentials.txt` — the passwords and alias needed to *use* the keystore. The `.p12` file is useless without it.
  </Step>

  <Step title="Continue">
    The **Continue** button stays disabled, with "Download both files to continue" underneath, until both downloads are done.
  </Step>
</Steps>

<Tip>
  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.
</Tip>

### 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:

| Field             | Value                             |
| ----------------- | --------------------------------- |
| Keystore file     | `release-keystore.p12`            |
| Keystore type     | PKCS12                            |
| Key alias         | `release-key`                     |
| Keystore password | Randomly generated, 16 characters |
| Key password      | Same as the keystore password     |

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:

<AccordionGroup>
  <Accordion title="Use Existing Key — what you almost always want">
    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.
  </Accordion>

  <Accordion title="Generate New Key — only for a fresh app">
    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.
  </Accordion>
</AccordionGroup>

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

<Warning>
  **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.
</Warning>

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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="Download the backups while you're there">
    Save the `.p12` and credentials `.txt` now, whatever else you decide to do.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Note>
  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.
</Note>

<Tip>
  Planning to work in a duplicate? Keep publishing from the original project, or sort the key out **before** you build, not after.
</Tip>

## 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.

<Card title="AAB, keystores and Play App Signing explained" icon="book-open" href="https://newly.app/aab-builder">
  Longer background on Android App Bundles, signing, and how Play App Signing works.
</Card>

## Common problems

<AccordionGroup>
  <Accordion title="Google Play rejects my upload: 'not signed with the correct key'">
    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](#your-key-belongs-to-one-project-not-to-your-app) 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.
  </Accordion>

  <Accordion title="I lost my keystore files">
    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.
  </Accordion>

  <Accordion title="I can't get past step 3">
    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.
  </Accordion>

  <Accordion title="Do I need a signing key for an APK build?">
    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.
  </Accordion>
</AccordionGroup>

## Related

<CardGroup cols={2}>
  <Card title="App Deployment" icon="rocket" href="/features/deployment">
    How Newly builds APKs and AABs
  </Card>

  <Card title="Google Play Setup" icon="google-play" href="/guides/google-play-setup">
    Connecting your Google Play Console account
  </Card>

  <Card title="App Store Submission" icon="list-check" href="/guides/app-store-submission">
    The full start-to-finish submission walkthrough
  </Card>

  <Card title="Changing your Bundle ID" icon="tag" href="/guides/bundle-id-changes">
    Why your package name is hard to change later
  </Card>
</CardGroup>