How to Publish an App on Google Play: Step by Step

Your Android app works and now it has to go on Google Play. Play Console guides you through most of it, but the order matters, and two steps take days rather than minutes: setting up a developer account, and, for many new accounts, a closed test that has to run for two weeks before you can publish. This guide lists the steps in the order you will meet them, for a small team publishing a phone app. Google's requirements below come from its own pages as of 14 September 2026.

The short version

1. Create a Google Play developer account.
2. Create the app in Play Console and accept the declarations.
3. Complete the App content declarations: privacy policy, ads, sign-in details, target audience, content rating, Data safety.
4. Fill in the store listing: name, descriptions, icon, feature graphic, screenshots, contact email.
5. Build a signed Android App Bundle that targets API level 36, and set up Play App Signing.
6. Test on the internal and closed tracks. New personal accounts need 12 testers for 14 days.
7. Create a production release, send it for review and roll it out.

1. The developer account

You publish from a Google Play developer account, either personal or for an organisation. The account type changes what comes next: as of 14 September 2026, Google's help says developers with personal accounts created after 13 November 2023 must meet specific testing requirements before they can make an app available on Google Play. Our guide to the Google Play developer account covers the choice and what each type needs.

2. Create the app

As of 14 September 2026, Google's help page Create and set up your app describes the steps. In Play Console, select Home, then Create app, and:

• choose a default language and the app's name as it will appear on Google Play;
• say whether it is an app or a game, and whether it is free or paid;
• add a contact email address for users;
• acknowledge the Developer Program Policies and US export laws declarations, and accept the Play App Signing Terms of Service.

Choose your package name with care. The same page says package names are permanent: they can't be deleted or reused. Once the app exists, its dashboard lists the setup tasks that follow.

3. App content declarations

The App content page (Policy and programs, then App content) is where you tell Google what is in the app. Google's page Prepare your app for review lists what it covers, as of 14 September 2026:

• Privacy policy. Required for apps that request sensitive permissions or data and for apps that target children, and a link you will want regardless.
• Ads. You must declare whether the app contains ads, including ads from third-party SDKs. Apps that do get a "Contains ads" label.
• Sign-in details. If any part of the app sits behind a login, you must give reviewers what they need to get in. You can add up to five sets of instructions.
• Target audience and content. You declare the target age group. Apps that include children must meet the Families policy requirements.
• Content rating. Fill in the questionnaire. Google warns that "Unrated" apps may be removed from Google Play.
• Data safety. You tell Google about your app's privacy and security practices. Our Data safety form guide walks through it.
• Permissions. If the app requests high-risk or sensitive permissions, such as SMS or Call Log, you may need to complete a Permissions Declaration Form and get approval.

Do these early. They take longer than they look, and the reviewer relies on them.

4. The store listing

Your Main store listing is shared across tracks, so testers see it too. As of 14 September 2026, Google's help sets these limits and requirements:

The graphics rules are on Google's page Add preview assets to showcase your app. Our guides to Android app icon sizes and Google Play screenshot sizes go into the details, including the adaptive icon your app itself needs.

5. The app bundle and Play App Signing

New apps publish Android App Bundles (.aab), not APKs. Google's page Prepare and roll out a release says APKs remain an option for apps created before August 2021. Google Play builds and serves optimised APKs for each device from your bundle.

On your app's initial release, Play Console asks you to configure Play App Signing. As of 14 September 2026, Google's Play App Signing page explains the two keys:

• The upload key stays with you. You sign each bundle with it before upload. It must be an RSA key of 2048 bits or more, and if you lose it, Google can reset it for you.
• The app signing key is held by Google, which uses it to sign the APKs users install.

Configuring Play App Signing needs admin permission on the developer account. Each new bundle also needs a higher versionCode than the last, and the create-app page sets 2100000000 as the highest value Play Console accepts.

Flutter and React Native

Cross-platform apps produce the same bundle. Flutter's Android deployment guide builds it with flutter build appbundle. React Native's signed release guide uses npx react-native build-android --mode=release, which writes android/app/build/outputs/bundle/release/app-release.aab. Both guides cover setting up the upload key in Gradle before you build.

6. The target API level

Google Play sets a minimum target API level for every submission. As of 14 September 2026, Google's page on target API level requirements says that starting 31 August 2026, new apps and app updates must target Android 16 (API level 36) or higher to be submitted, with lower levels for Wear OS, Android Automotive OS, Android TV and Android XR. Developers who need more time can request an extension to 1 November 2026. Set targetSdk to 36 in your module's Gradle file and test the behaviour changes before you upload. Our target API level guide covers the details.

7. Testing tracks

Play Console has three testing tracks. As of 14 September 2026, Google's page Set up an open, closed, or internal test describes them:

• Internal testing reaches up to 100 testers you add by email. You can start it before finishing app setup, and new bundles reach testers within minutes.
• Closed testing reaches a wider group you choose. You can run several closed tracks at once.
• Open testing lets anyone join from Google Play and send private feedback.

Google says the link for a newly published test can take several hours to reach testers. Our testing tracks guide compares the three.

The 12-tester requirement

As of 14 September 2026, Google's page on testing requirements for new personal accounts says that developers with personal accounts created after 13 November 2023 must run a closed test with at least 12 testers who have been opted in continuously for at least 14 days. Production and pre-registration stay disabled until then. Once you meet the criteria, you apply for production access from the Dashboard and answer questions about your test, your app and its readiness. For those accounts, open testing becomes available after production access is granted.

Plan for this: two weeks of testing, plus the time to recruit testers and apply. Our guide to 12 testers for 14 days covers finding testers and keeping them opted in.

8. The production release and review

When the app is ready, go to Test and release, then Production, and click Create new release. Following Google's release page, as of 14 September 2026:

1. Add your app bundle and name the release. The name is for you; users don't see it.
2. Enter release notes, up to 500 Unicode characters per language. See writing Google Play release notes.
3. Review the summary. You can't publish while there are errors; warnings are allowed but worth fixing.
4. Start the rollout. Rollout percentages aren't offered for an app's initial release, so the rollout to production makes the app available to all Google Play users in the countries and regions you chose, once review approves it.

Review

Google reviews new apps and updates before they go live. As of 14 September 2026, its page Publish your app says that for certain developer accounts it takes more time, which may mean review times of up to seven days or longer in exceptional cases. Leave at least a week. Our guide to Google Play review time covers what affects it and how to read the statuses.

Managed publishing for updates

Once the app is live, managed publishing lets you decide when approved changes go out. Google's page on managed publishing says your app must already be available to use it, so it doesn't apply to the launch itself. For later updates, staged rollouts let you release to a percentage of users and halt if something breaks.

If you also ship on iOS, see how to publish on the App Store.

How FeedbackKit fits in

Launch day is when strangers start using your app. Without a place inside the app to send ideas, many of them will write a review instead, and a feature request in a one-star review helps nobody. Give them a better door before you roll out.

FeedbackKit adds a request board to your app: users post ideas, vote and comment without leaving it. There are Jetpack Compose views for Android (Kotlin docs, with a setup guide), and SDKs for Flutter and React Native. It is also a good home for what closed testers tell you during those 14 days. FeedbackKit's beta status is called TestFlight, after Apple's service, and Android users see that same label. Many teams use it to mean "in testing", whichever store's beta it is.

When you fill in the Data safety form, include FeedbackKit like any other SDK you ship. Here is how collecting requests looks in FeedbackKit, with sample data from a fictional hiking app:

Publishing is a checklist; listening is a habit. Start free and have your feedback board live from version 1.0.