How to submit an app to Google Play, step by step

Google Play's submission flow has one thing Apple's does not: a gate. If your developer account is a personal account created after 13 November 2023, you cannot reach the production track at all until you have run a closed test with at least 12 testers opted in continuously for 14 days, and then applied for production access and been approved.

That number is 12, not 20. Google's own wording is "At least 12 testers must be opted in to your closed test when you apply for production access" and "they must have been opted in continuously for the preceding 14 days". The 20 figure circulating in forum posts and older blogs was the requirement when the policy launched; it was reduced. Plan against 12, and against the fact that the 14 days are consecutive.

Here is the whole path, in order.

1. Create the app in Play Console

All apps → Create app. You give the app name, default language, whether it is an app or a game, free or paid, and confirm the declarations.

What blocks it: free to paid is a one-way door. An app published as free can never be switched to paid, so decide before you publish, not after.

2. Build an Android App Bundle

Play distributes from an .aab, not an .apk, and generates per-device APKs from it. Google's stated ceiling is a 200MB maximum compressed download size for the APKs generated from one bundle for a single device.

What blocks it: the target API level. From 31 August 2026, new apps and updates must target Android 16 (API level 36) or higher, with exceptions: Wear OS and Android Automotive OS need API 35 or higher, and Android TV and Android XR need API 34 or higher. Existing apps must target at least API 35 to stay available to new users on newer Android versions. Google has said an extension to 1 November 2026 can be requested through Play Console.

3. Set up app signing

On your first release you choose whether Play App Signing uses a Google-generated app signing key or one you upload.

What blocks it: losing the upload key later. Play App Signing gives you a recovery path for the upload key; there is no recovery path for a signing key you manage entirely yourself and then lose. Decide this once, deliberately.

4. Fill in the store listing

Grow → Store presence → Main store listing. App name, short description, full description, app icon, feature graphic, phone screenshots, and the same set for every language you add.

What blocks it: the feature graphic and a minimum number of phone screenshots are required, and Play checks dimensions at upload. Text limits are enforced in the field.

5. Complete App content

Policy and programs → App content. This is a list of declarations, and the app will not publish while any required one is outstanding. The set includes:

• Privacy policy, a live URL
• App access, where you supply sign-in details for anything behind a login
• Ads, whether the app contains ads
• Content ratings, the questionnaire
• Target audience and content, the age groups you are aiming at
• Data safety, the disclosure form
• News apps and the permissions declaration form, where relevant

What blocks it: App access. If a reviewer cannot get past your login, the review fails, exactly as on Apple. Supply credentials that work and do not expire.

6. Content rating questionnaire

Play uses IARC, so one questionnaire produces ratings for multiple regional boards at once.

What blocks it: it must be completed and it must be honest. A rating that does not match the app is a policy problem later, not a form problem now.

7. Data safety

The Data safety form asks what data you collect and share, why, whether collection is optional, and what security practices apply. It covers third-party SDKs, not only your own code.

What blocks it: Google puts the responsibility squarely on you: "You alone are responsible for making complete and accurate declarations in your app's store listing on Google Play." Apps that do not comply face "blocked updates or removal from Google Play". A wrong Data safety form is a slow-acting failure, not an instant one, which is what makes it dangerous.

8. Understand the tracks before you pick one

Four rungs, and they matter for the gate:

Track	Who can install	Tester limit
Internal testing	People you list by email	Up to 100 testers per app
Closed testing	Lists you curate, or Google Groups	200 lists total, up to 2,000 users per list, up to 50 lists per track
Open testing	Anyone who joins from your store listing	Effectively public
Production	Everyone	Live

Internal testing is the fast lane. Builds land quickly and it is the right place to check that a bundle installs and runs.

9. Run the closed test that satisfies the gate

Create a closed testing track, add a tester list, and publish a release to it. Then the clock starts.

Google's rules, in its words: testers "who opt in, test for fewer than 14 days, and then opt out do not count toward the requirement", and "If a tester opts out and opts back in later, the 14 days must be consecutive to count toward the minimum requirement".

What blocks it: attrition. Twelve testers who opt in and then drift away reset your count. Recruit more than twelve, tell them explicitly not to opt out, and check the opted-in number rather than assuming.

Two things worth being blunt about. Opting in means accepting the test through the opt-in link, not merely being on your list. And buying testers from a service that swaps installs with strangers is a policy risk, because the application asks how you recruited them and what you learned.

10. Apply for production access

Once the 12-for-14-days condition holds, open the Dashboard in Play Console and use Apply for production. The application is a form in three parts: details of your closed test, information about the app or game, and your readiness for production. It asks how you found testers, how engaged they were, what feedback you collected, and what you changed as a result.

What blocks it: thin answers. This is read by a human, and "I ran the test" is not an answer to "what did you learn". Write specifics.

11. Release to production

With production access granted, create a release on the Production track, attach the bundle, write release notes, and roll out.

What blocks it: any outstanding App content declaration, and review. Google publishes no standard turnaround, but does say: "For certain developer accounts, we'll take more time to thoroughly review your app to help better protect users. This may result in review times of up to seven days or longer in exceptional cases."

12. Use a staged rollout for updates

A staged rollout sends the update to a percentage of users you choose, which you raise over time. It is available for updates only, not for publishing an app for the first time.

Start it from the release itself, in the Staged rollout section, then Start rollout to production. Afterwards the controls live under Manage rollout:

• Update rollout to raise the percentage, then Confirm update
• Halt rollout to stop new users receiving it, while users who already got it keep the version they have
• Resume rollout to continue from where you stopped

What blocks it: the fact that halting is not a rollback. Users who already updated stay updated. If a build is genuinely broken, halt it and ship a fixed version on top, because there is no undo.

13. Turn on managed publishing if timing matters

By default, approved changes publish as soon as review clears. Managed publishing holds them until you say go.

Publishing overview → Managed publishing status → Turn on managed publishing → Save. Approved changes then collect under Changes ready to publish, and Publish changes sends them live "within a few minutes". You can toggle it on or off at any point, including while a change is in review.

What blocks it: forgetting it is on. A team that switches managed publishing on for a launch and never switches it off will eventually wonder why an approved fix never reached users.

14. Watch the Publishing overview, not your inbox

The Publishing overview page is where a change's review state actually lives. If a release seems stuck, look there first: something is usually sitting in review, or waiting on a declaration, or waiting on you because managed publishing is enabled.

The Play flow is more forgiving than Apple's in one way, since tracks let you ship to real devices without any review at all, and less forgiving in another, because the closed-testing gate is 14 days of calendar time that no amount of preparation shortens. If you are on a new personal account, start the closed test on day one of the project, not the week you plan to launch.

AppSubmit pushes listings, screenshots and releases through the Play Developer API and will tell you which permission or declaration is missing before a push fails, but the 12 testers and the 14 days are Google's clock, and nothing can hurry them.