How to Publish an Android App on Google Play in 2026

The short answer: the sequence from code to live

Publishing an Android app on Google Play in 2026, step by step, is eight moves: create a Play Console account and clear identity verification, create the app and finish its app setup checklist, upload a signed Android App Bundle to the closed testing track, get at least 12 testers actually opted in, keep them opted in for 14 days continuously, apply for production access from the Dashboard, create your first production release, then push every later update through Publishing overview.

The step that makes this longer than the old "upload an APK and go live" workflow is the closed test. Google states the rule plainly: developers with personal accounts created after November 13, 2023 must run a closed test "with a minimum of 12 testers who have been opted-in for at least the last 14 days continuously" (App testing requirements for new personal developer accounts). Until that is met, the Production and Pre-registration areas of Play Console stay disabled for that app.

Two corrections to the mental model most first-time publishers bring. First, this is a dependency chain, not a checklist: each step unlocks the next, and doing them out of order does not save time, it just moves the wait. Second, Google publishes only a handful of durations in its own documentation. Every other number you read ("identity verification takes 48 hours", "reviews clear faster in the morning") is either a community report or an invention, and planning on it is how schedules slip.

Work through them in order. Each section below says what to do, what Google blocks until you do it, and what is genuinely uncertain.

Step 1: Create the developer account and clear verification

Sign up at play.google.com/console with a Google account you intend to keep, accept the Developer Distribution Agreement, and pay the one-time US$25 registration fee. Then start identity verification immediately, before you have a build ready. Verification is a separate process from publishing and it runs on its own clock, so every day it overlaps with your build time is a day you do not pay twice.

Account type matters more here than anywhere else in this guide. Google's testing requirement is published under the title "App testing requirements for new personal developer accounts", and its stated scope is personal accounts created after November 13, 2023 (source). If you register as an organization, the paperwork is heavier and the testing question is different. We cover what changes and what does not in Does an Organization Account Skip the 12-Tester Rule?, because the answer is not a simple yes.

What Google does not publish is a total duration for identity verification. It publishes durations for individual sub-checks only. Do not accept a guide that tells you the whole thing takes "24 hours" or "up to 3 weeks" as fact; both are guesses. The full signup sequence, including what each verification step actually asks for and the account-date cutoff that decides whether the 12-tester rule applies to you at all, is in how to create a Google Play developer account in 2026.

What clears this step: the account can create apps in Play Console. Note that an account can usually create apps before every verification sub-step has finished, so if you are blocked later, check whether the blocker is verification or app setup before assuming the worst.

Step 2: Create the app and finish the app setup checklist

Select your app in Play Console and work the Dashboard task list to completion. This is not administrative busywork: Google ties the closed test to it directly. Its testing-requirements page says "You can start a closed test once you're finished setting up your app" (14151465), and the testing setup page says "You can start an internal test before completing app setup" (9845334). That contrast is the whole dependency in one line: internal testing is available early, closed testing is not.

The practical symptom of an unfinished setup is a greyed-out Create new release button. Google documents the cause on its release pages: "If Create new release is disabled, you may have outstanding setup tasks to complete. These may be listed on the Dashboard page" (7381861). Open the Dashboard rather than hunting through the testing menus.

The checklist covers your store listing (title, short and full description, icon, feature graphic, screenshots), the content rating questionnaire, the Data safety form, a privacy policy URL, target audience, and app access credentials so a reviewer can sign in. Each of those has its own failure mode, and two of them cause most first-submission rejections: a Data safety declaration that does not match what your app and its SDKs actually collect, and reviewer credentials that do not work. We cover the listing fields in preparing your store listing before closed testing and the declaration itself in what to declare on the Data safety form.

What clears this step: the Dashboard shows no outstanding tasks and Create new release is enabled on your closed testing track.

Step 3: Build a release bundle and publish it to the closed track

Google Play expects an Android App Bundle, not an APK, for new apps. Build a release variant, sign it, and enroll the app in Play App Signing so Google holds the app signing key and you hold the upload key. Two console facts are worth knowing before you upload, because both are irreversible or slow: once you upload an artifact the package name is fixed and cannot be changed (9845334), and an upload that fails Google's checks can still burn a version code, so every subsequent upload needs a higher one.

If the format itself is unfamiliar, What Is an AAB File? Google Play's App Bundle Explained covers what sits inside the bundle, how Play assembles the installable build for each device from it, how to produce one from Android Studio, Gradle, Flutter or React Native, and the upload errors that waste a version code before the file ever reaches the track.

Google's own recommendation is to run an internal test first: "We recommend running an internal test before releasing your app to closed or open tracks" (9845334). It costs you nothing, it distributes to up to 100 testers within minutes, and it catches signing and packaging errors before they sit on the track where your 14-day clock is supposed to run.

Then go to Test and release, Testing, Closed testing, click Manage track, open the Testers tab and choose how testers get access. Two methods are supported: an email list (create up to 200 lists, up to 2,000 addresses each, with up to 50 lists per track) or a Google Group entered as [email protected]. Add a feedback URL or email, because that channel appears on the tester opt-in page, then save and copy the shareable link.

Expect a delay at this point. Google warns that "after publishing an open, closed, or internal test for the first time, the test link can take several hours to become available to testers" (9845334). If your opt-in link 404s an hour after you publish it, that is documented behaviour, not a broken setup. Full console walkthrough: how to set up closed testing in Play Console. The target API level check also runs at upload, and new apps must meet Google's current minimum; see the target API 36 rule for the dates.

Step 4: Get 12 testers actually opted in

The requirement is not "12 addresses in a list". Google's wording throughout is that testers must be "opted-in" (14151465), and the mechanism that produces that state is the shareable link you copied in Step 3: each person opens it while signed in to their own Google account and joins the test. Sending an invitation is not the same as being opted in. The console's opt-in count is the only number that matters, and it is the number Google says must read at least 12 when you apply.

Two mechanical details cause most of the wasted weeks we see. A tester who joins with a different Google account than the one on their phone installs nothing. A tester whose Play country is outside the test's available countries hits an availability wall; Google notes that country and region changes "apply across all tracks" (9845334), so fix targeting in the console rather than arguing with the tester. If someone reports the app is unavailable, work through why testers see "app not available" before recruiting a replacement.

Recruit above 12. That is a recommendation, not a Google rule: Google publishes no buffer and no minimum beyond 12. Our reasoning is that opt-outs are ordinary human behaviour and the count has to still read 12 on the day you apply, so a plan that starts at exactly 12 has no margin. Across the 1,500+ closed-testing campaigns in our own records, the phase that stalls is the opt-in count rather than the 14-day window itself, because people join with the wrong account or never open the link at all. How many testers you actually need, and the honest failure modes of each recruitment channel, are covered in seven ways to get 12 testers.

Step 5: Run the 14-day window

Google's rule has three parts and developers routinely get the third one wrong. At least 12 testers must be opted in. They must have been opted in "for at least the last 14 days continuously" (14151465). And the 12 must still be there when you apply, not merely at some point during the fortnight.

Google spells out what breaks the streak: "we won't count testers who opted in, tested for less than 14 days, and then opted out. Even if they opt back in so that they are opted in for a total of 14 days, these 14 days must be consecutive to count towards the criteria" (14151465). So a tester who leaves on day 9 and returns on day 12 restarts their own clock; days 10 to 11 are simply lost, and if that person was one of your 12, your whole window does not complete until they have a fresh consecutive run. This is why dropping below 12 mid-test feels like the console "stopped counting" rather than subtracting one.

Engagement is a separate axis from opt-in, and it surfaces later than you expect. Google's page does not publish a minimum number of daily app opens or a crash threshold. What it publishes is a consequence: after you apply, "if your app isn't ready to be published, you may be required to continue testing", with the examples it gives being "not having 12 testers opted-in to your closed test, or your testers not being engaged with your app during your closed test" (14151465). In other words, engagement is evaluated against your application, so treat it as something to be able to describe rather than a number to hit. We answer the daily-open question directly in do testers have to open the app every day, and the reset mechanics, including which actions restart the clock and which do not, in what resets the 14-day test.

Step 6: Apply for production access from the Dashboard

The application lives on your app's Dashboard, not under the Production menu, which is disabled precisely until this step clears. Google's instructions are two lines: "1. Go to the Dashboard. 2. Click Apply for production" (14151465).

The form has three sections: About your closed test, About your app/game, and Production readiness. Google publishes what it asks for in two of them. In the closed-test section: how easy you found it to recruit testers, what engagement you received (whether testers used all of your features, whether usage matched what you would expect from a production user), and a summary of the feedback you received plus how you collected it. In the production-readiness section: what changes you made based on what you learned during the closed test, and how you decided the app was ready. Then click Apply.

One warning Google repeats twice in the same article: if you click Discard or quit partway through, "your changes won't be saved". Draft your answers offline first, in a text file, then paste them in a single sitting.

Review timing is one of the few durations Google actually publishes: "When the review is complete, we'll email the account owner with an update. This usually takes 7 days or less, but may occasionally take longer" (14151465). If the answer is no, the outcome is not an account strike, it is a request to keep testing, with the same two examples Google gives above. Fix what it names and apply again once the criteria are met. Section-by-section guidance on wording answers that do not waffle: how to apply for production access, plus eligibility versus approval for what the two states actually mean.

Step 7: Create and roll out the first production release

Once approved, Test and release, Production is enabled. Click Create new release, upload the bundle, add release notes, review the summary, and start the rollout. Google's release guide is explicit about two things that trip up first-time publishers.

First, errors block you and warnings do not: "You can't publish your app until errors are resolved. If you have warnings, minor issues, or a combination of the two, then you can still publish your app" (9859348). Open the Errors summary, fix the listed items, and stop worrying about the warning list.

Second, and this is where a lot of published advice is simply wrong: staged rollouts are not available on a first release. Google states "Rollout percentage options are unavailable for a first release" (9859348) and, separately, "Staged roll-outs can only be used for app updates, not when publishing an app for the first time" (6346149). You will not see a 5 percent or 20 percent option on your first production release, and guides telling you to start your first rollout at 20 percent are describing update behaviour. What Google does say is that "if rolling out a first production release, clicking Start rollout to production publishes your app to all Google Play users in your selected countries or regions" (9859348), so country selection is the lever you actually control on day one.

Countries come from your production country configuration; Google documents how distribution regions are chosen in choose where to distribute your app. Do the final sanity pass before you click: listing complete, privacy policy reachable, reviewer credentials work, Data safety matches the build. Once the rollout starts, the app status under your app name reads Production, and the app becomes downloadable by users in your selected countries.

How long does it take? What Google publishes and what it does not

Honest answer: nobody can give you a total, because Google does not publish one. The fixed component is 14 days of continuous opt-in. The variable components are verification, setup, release review, and the production access review, and of those Google publishes durations for only some.

Three claims you will read elsewhere have no Google source, and it is worth knowing which is which before you plan around them: that verification takes a fixed number of hours, that submitting a release at a particular time of day speeds its review, and that a stated share of applications is rejected at the questionnaire. Google publishes none of these. Treat them as community experience at best and marketing at worst, and treat the table above as the only timings you can commit to a plan.

One more published behaviour affects your schedule: updates are not automatic. Google states that "your changes are not automatically sent for review" and they queue on the Publishing overview page until you decide when they go out (9859751). Standard publishing pushes approved changes as soon as possible; managed publishing lets you hold them. That is a useful lever once you are live and no longer useful before.

Where this sequence breaks in our own campaigns

Based on our internal records from 1,500+ closed-testing campaigns, the pattern is consistent enough to be worth stating as our own analysis rather than as any Google rule. The 14-day window is almost never the part that slips. What slips is the handoff into it: addresses added to the list that never become opt-ins, testers joining from a Google account that is not signed in on the device, and a release published while app setup still has an outstanding task, which means Create new release stays disabled and the calendar silently burns anyway.

Our campaigns run on physical devices, not emulators, across Samsung, Pixel, Xiaomi and OnePlus hardware running Android 11 through 15, with testers in more than 80 countries, and a match is normally confirmed within 24 hours of a request. Country spread is the operational detail people underestimate: a test recruited entirely from one country is fine until your production targeting does not include it, and then the opt-in link reports the app as unavailable to someone who has already done everything else correctly.

The other first-hand observation worth passing on is that the console's own count, not your spreadsheet, is the source of truth on the day you apply. Keep a tracker if you like, but reconcile it against the Testers tab before you open the application, because the application is where the two most common problems, a count below 12 and testers Google reads as disengaged, actually surface. We do not publish success or approval rates for our own service, because Google does not publish a benchmark to compare against and an internal figure would not describe your app.

Frequently Asked Questions

Do I have to do closed testing to publish on Google Play?

For a personal developer account created after November 13, 2023, yes: Google requires a closed test with at least 12 testers opted in for 14 days continuously before you can apply for production access, and the Production track is disabled until then (14151465). Accounts outside that scope are documented separately by Google; check your own Dashboard, where the presence or absence of the Apply for production prompt is the definitive answer for your account.

Where is the Apply for production button?

On your app's Dashboard in Play Console, not under the Production menu. Google's instructions are "Go to the Dashboard" then "Click Apply for production" (14151465). The Production menu is locked until this application is approved, so looking for it there will never work.

Does my 14-day clock start when I upload the build?

No. The clock runs per tester, from the point they are opted in, and Google requires that the days be consecutive (14151465). Uploading a bundle starts nothing; a release that is not yet usable by testers, plus opt-ins that have not happened yet, means day zero has not arrived.

What happens if one tester opts out during the 14 days?

That tester's run breaks. Google states it will not count testers "who opted in, tested for less than 14 days, and then opted out", and that even if they opt back in, the 14 days must be consecutive to count (14151465). If your total drops below 12, the window does not complete until you are back at 12 and the qualifying run is unbroken.

Can I start my first production release as a staged rollout?

No. Rollout percentage options are unavailable for a first release (9859348), and Google confirms that staged roll-outs "can only be used for app updates, not when publishing an app for the first time" (6346149). Your first release goes to all users in your selected countries; percentages become available from your second release onward.

How long does the production access application take?

Google publishes one duration for it: the review "usually takes 7 days or less, but may occasionally take longer" (14151465). It publishes no upper bound and no total end-to-end timeline from account creation to a live listing, which is why every published total you see elsewhere is an estimate rather than a rule.

Sources

Primary sources used for every policy claim on this page, in the order the steps appear.

1. App testing requirements for new personal developer accounts - Google's official statement of the 12-tester, 14-day continuous opt-in requirement, the November 13, 2023 account-date cutoff, the disabled Production and Pre-registration areas, the Dashboard application flow and its three sections, the 7-day-or-less review statement, and the consequences of a failed application.
2. Set up an open, closed, or internal test - track differences, the recommendation to run an internal test first, the rule that an internal test can start before app setup, closed-test tester lists and Google Groups, the fixed package name after first upload, and the several-hour delay before a first test link works.
3. Distribute your instant experience - the documented cause of a disabled Create new release button, which is outstanding setup tasks listed on the Dashboard.
4. Prepare and roll out a release - release creation steps, the rule that errors block publishing while warnings do not, the absence of rollout percentages on a first release, and what a first production rollout to production does.
5. Release app updates with staged roll-outs - the confirmation that staged roll-outs are for app updates only, never for a first publication.
6. Publish your app - publishing status definitions, standard versus managed publishing, the extended-review statement of up to seven days or longer in exceptional cases, and the rule that changes are not automatically sent for review.
7. Choose where to distribute your app - how production country and region targeting is configured, which sets where your first rollout is available.
8. Manage how your changes are reviewed and published - queued changes on the Publishing overview page and the timing control managed publishing gives you.

Campaign observations in this article come from OnTesters' own internal records covering 1,500+ closed-testing campaigns, not from Google, and are labelled as our analysis wherever they appear. Where Google publishes no figure, we have said so rather than substituting an estimate.