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

# Publish to Google Play Store

> Step-by-step guide to uploading your Capwrapper-built AAB to Google Play, setting up a keystore, and avoiding common rejection reasons.

Once Capwrapper finishes your build, you have a signed AAB and APK ready to go. Submitting to Google Play is a separate process that requires a Google Play Developer account and your own release keystore — the AAB that Capwrapper produces is the artifact you upload directly into Play Console.

## What you need before you start

* A signed AAB file downloaded from your Capwrapper dashboard (preferred over APK for Play Store submissions)
* A [Google Play Developer account](https://play.google.com/console) — there is a one-time \$25 registration fee
* Your own release keystore (see below — the debug keystore will not pass Play Store validation)

<Warning>
  Do not use the auto-generated debug keystore for a Play Store submission. Google Play requires apps to be signed with a consistent release keystore across all updates. If you publish with a debug key and later lose it, you will be unable to update your app. Generate a dedicated release keystore and keep it safe.
</Warning>

## Generate a release keystore

If you don't already have a release keystore, run the following command using the `keytool` utility that ships with any JDK installation:

```bash theme={null}
keytool -genkey -v -keystore my-release-key.jks -alias mykey -keyalg RSA -keysize 2048 -validity 10000
```

You will be prompted to set a keystore password and provide some identity information (name, organisation, country). Store the resulting `.jks` file and both passwords somewhere secure — you will need them for every future update to this app.

When configuring your next Capwrapper build, supply this keystore under **Configuration > Signing** so that the output AAB is signed with your release key.

## Submit to Google Play

<Steps>
  <Step title="Log in to Google Play Console">
    Go to [play.google.com/console](https://play.google.com/console) and sign in with the Google account associated with your developer account.
  </Step>

  <Step title="Create a new app listing">
    Click **Create app** in the top-right corner. Choose a default language, enter your app name, select **App** or **Game**, and confirm it is free or paid. Then click **Create app**.
  </Step>

  <Step title="Fill in your store listing">
    Navigate to **Store presence > Main store listing**. Complete the required fields:

    * Short description (up to 80 characters)
    * Full description (up to 4,000 characters)
    * At least 2 screenshots per required screen size
    * A feature graphic (1024 × 500 px)
    * App icon (512 × 512 px)
    * Category and contact details
  </Step>

  <Step title="Set the content rating">
    Go to **Policy > App content > Content rating** and complete the questionnaire. Google requires all apps to have a rating before they can be published. The process takes about five minutes and results in an IARC rating being assigned automatically.
  </Step>

  <Step title="Set up pricing and distribution">
    Under **Monetise > Pricing**, set whether your app is free or paid. Under **Distribution**, select the countries where you want your app to be available.
  </Step>

  <Step title="Upload your signed AAB">
    Go to **Release > Production** (or **Internal testing** if you want to test first) and click **Create new release**. Upload your signed AAB file from your Capwrapper dashboard. Google Play will process the file and display the version code it detected.

    <Note>
      Each new build submitted to the Play Store must have a higher `appVersion` than the previous submission. Capwrapper derives the numeric version code from the `appVersion` field in your build config — increment it before every build you plan to publish.
    </Note>
  </Step>

  <Step title="Submit for review">
    Once all sections show a green checkmark in Play Console, click **Review release**, then **Start rollout to Production**. Google typically reviews new apps within 1–3 business days.
  </Step>
</Steps>

## Common rejection reasons

Knowing why apps get rejected saves you a review cycle. The most frequent causes for Android rejections are:

| Reason                                             | How to avoid it                                                                                                                                                               |
| -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Version code not higher than previous submission   | Increment `appVersion` in your Capwrapper build config before every build you submit                                                                                          |
| Policy violation                                   | Review the [Google Play Developer Program Policies](https://play.google.com/about/developer-content-policy/) before submitting, especially around permissions and data safety |
| Screenshots or description don't match app content | Use real screenshots of your actual app; descriptions must accurately reflect functionality                                                                                   |
| Missing privacy policy                             | If your app collects any user data (including analytics), you must provide a publicly accessible privacy policy URL in the store listing and in the app itself                |
| Incorrect or missing data safety form              | Complete the **Data safety** section in Play Console honestly — it must match what your app actually collects                                                                 |

<Tip>
  Start with an **Internal testing** release track before submitting to production. It lets a small group of testers validate the build on real devices without going through the full public review process.
</Tip>