Play Console has four release tracks, and the ladder people describe is not the one Google documents.
Play Console gives you three testing tracks, internal testing, closed testing and open testing, plus production. Internal testing takes up to 100 testers and unlocks nothing first. Closed testing wants a completed app setup. Production wants a closed test that ran with at least 12 testers opted in continuously for 14 days, if your personal developer account was created after 13 November 2023. And open testing, the track everybody calls beta and treats as the step before launch, becomes available only once you already have production access. Those four entry requirements are Google's own, from the table on its App testing requirements page, read on 21 October 2026.
What follows is what each track is for, what the tester limits really are, how a build moves from one track to another, and whether it can skip one. Every figure below came off a Play Console Help page on 21 October 2026. Those pages print no last-updated date of their own, so the date you are reading is the date somebody checked, and that is the only honest date to give you.
Start hereThe short version
The gate sits on your account, not on your build.
Nothing in Play Console stops a particular app bundle from going to production. What stops you is the account it belongs to. Google Play requires personal developer accounts created after 13 November 2023 to test their apps before those apps are eligible for distribution, and until that is done both Production and Pre-registration stay disabled in Play Console. Once the gate opens it stays open, which is why the question people ask, which track does my build have to pass through, has such a dull answer.
It also helps to separate two words Play Console uses carefully. A build is an app bundle you uploaded. A release is a named set of one or more of those bundles that you roll out to one track, with its own release notes, capped at 500 Unicode characters per language. The bundle is uploaded once. Assigning it to a track is a separate act, and you can do it more than once. Running the 14 days is the real work, and google play closed testing covers how to get through them without resetting the clock.
What tracks does Play Console actually have?
Four names, in two places in the sidebar. Test and release, then Testing, holds Internal testing, Closed testing and Open testing. Test and release, then Production, holds the fourth. Google's release guide puts it as three testing tracks plus production, and every one of them takes a release made of app bundles. Legacy apps, meaning apps created before August 2021, may still use APKs.
Closed testing is not a single track, which is the first thing worth knowing. Play Console hands you one closed track to start with, and a Create track button next to it. Google's own example for extra tracks is one per development team, so two teams can work on different features at the same time without fighting over a build. Additional closed tracks cost you four features: enterprise targeting used to publish private apps, country targeting, device compatibility for bundles published only through those tracks, and track details in the Play Console mobile app, where an extra track shows up as an open testing track instead.
Then there are tracks for shapes of device. Play Console Help's page on managing form factor releases on dedicated tracks says Wear OS got its own track in March 2023, Android TV in October 2023, and Android XR was announced in December 2024. Wear OS is the one that is not optional: releases left on the mobile track still serve users but cannot be updated, so an existing Wear OS app has to move. Android TV and Android Automotive OS are a recommendation rather than a rule, with Automotive depending on the app category.
One more set of names catches people reading API examples. The Google Play Developer API addresses the same tracks as strings, and they are not the words in the console. Production is production, open testing is beta, internal testing is qa, and closed tracks keep whatever custom name you gave them. A form factor track is the prefix, a colon, then the default name, so Wear OS has wear:production, wear:beta and wear:qa. The prefixes are automotive, wear, tv, android_xr and google_play_games_pc. That page, APKs and Tracks in the Play Developer API documentation, prints its own last updated date of 18 December 2025, which is the only dated source in this article.
Pre-registration confuses the count because of where it sits. It appears under Test and release, Testing, in the same group as the three test tracks, and it is disabled alongside Production until the testing requirement is met. It is a campaign on your store listing, not a track you push builds to.
What is each track for, and who can join it?
Internal testing is the quick one. Up to 100 testers per app, added by email address, and you can release to it before your app setup is finished. Before the first review, testers see a temporary name for the app, which Play Console shows in the app summary on your Dashboard, for up to 48 hours. Google gives two different speeds for delivery on two different pages, and both were live on 21 October 2026: the App testing requirements page says builds are normally available within seconds of being added, while the page on setting up a test says a new app bundle becomes available within minutes. Treat the slower one as the promise.
Internal testing also behaves differently in ways that save you an afternoon. Device exclusion rules do not apply to internal testers. A tester in a country where your production, open or closed version is not available still gets the internal build. Internal tests might not be subject to standard Play policy or security reviews, and an app active only on internal testing is exempt from Google Play's Data safety section. The catch is that uploading any artifact fixes the package name for good.
Closed testing is where the real audience arrives. Testers come from email lists, from Google Groups by address, or from an organisation whose admins assign users for you. The limits are generous and worth knowing before you plan a recruitment drive: up to 200 lists, up to 2,000 users in each, and up to 50 lists attached to one track. If somebody is picked in both Play Console and the Google Admin console, they receive the highest version code available to them. Open testing puts the test build on Google Play, with unlimited testers by default or a cap you set, and the cap has to be at least 1,000.
Money splits along the same line, and this is the difference that ruins a test week. Testers on an open or closed test have to buy a paid app like any other customer. Internal testers install it free. In-app purchases are charged on every track unless you add the person to a license testers list, and purchases in an app published to internal testing or still in draft are subject to spend limits. Apple's half of the same job needs an app store connect sandbox tester instead, and the mechanics of a test transaction are in in app purchase sandbox testing.
Two things hold across all three test tracks. Feedback from testers does not affect your public rating, and testers cannot leave public reviews on a test version at all, so you supply the channel. Play Console makes you enter a feedback URL or email address on each track's Testers tab and shows it on the opt-in page. And a change to pricing or to country availability applies to every version on every track at once, internal testing excepted for countries.
Play Console Help, set up an open, closed, or internal test, read 21 October 2026
Pick the situation
Which track does this build belong on?
Choose what you are actually trying to do. The answer names the track and the thing that has to be true before Play Console will let you use it.
Internal testing
Up to 100 testers per app, added by email address. Google gives two numbers for how fast a new bundle reaches them: within seconds on the App testing requirements page, within minutes on the Set up a test page.
Before you can use it: Nothing to unlock. Google lists the requirement to access this track as none.
Read from Play Console Help on 21 October 2026. Those pages carry no last-updated date of their own, so check the figure before you plan a release around it.
How do you move a build from one track to the next?
Not with a promote button, because Play Console Help does not document one. The word promoted does appear in Google's documentation, but as a status describing a state of affairs: a track is promoted when all of its active app bundles are also active on its fallback track, for example when every active open testing bundle is also active in production. The route the documentation actually gives is plainer. Open the track you want, click Create new release, and on the Prepare release page click Add from library to pick an app bundle you have already uploaded rather than uploading it again. Name the release, write the notes, click Next, resolve any errors, and click Start rollout.
Two mechanical rules then decide what a phone installs, and they outrank any button. The first: a device receives the app version that has the highest version code compatible with that device and is published to a track the user is eligible for. The second: that eligibility stacks upwards. Everyone is eligible for production. A user in open testing is eligible for production and open testing. A user in closed testing is eligible for production and closed testing. Somebody in both is eligible for all three.
Internal testers are the exception, and it surprises people every time. Opting into an internal test removes you from open and closed eligibility even if your address is sitting on those lists, and you receive only the version code published to internal testing. To get an open or closed build, an internal tester has to opt out of the internal test first and then opt in again elsewhere. That is also why a colleague who tested an early build sometimes reports the wrong version for weeks.
When the tracks disagree, Play Console tells you so with four words. Shadowed means one bundle serves part or all of the same device configuration at a higher version code. Promoted is the tidy case above. Superseded means every active bundle on a track is completely shadowed, so nobody on that track is being served by it. Partially shadowed means some users on the track get its build while others get production's, and Google says that one usually indicates an error in version code assignment. If testers keep receiving the live app, the fix is a higher version code, not a longer tester list.
One queueing rule trips up release day. You cannot create a new release while you have outstanding ones. Take any staged rollout to 100 percent, or remove the changes on the Publishing overview page and discard unpublished releases, before starting the next. And once you publish to an open track the app signing key is fixed. Changing that key earlier means internal and closed testers who already installed stop receiving updates and have to uninstall and reinstall, and previously uploaded versions cannot be reused.
Play Console Help, version codes and testing track statuses, read 21 October 2026
Can a build skip a track?
Yes, and the question is usually asked backwards. In the Play Developer API an app bundle is uploaded into a storage area and only becomes a release when you assign its version code to a track, so one bundle can sit on several tracks at once and nothing records which track it came from. Play Console offers the same four destinations from a fresh upload. No part of Google's documentation says a bundle must pass through internal testing before closed, or closed before production.
What cannot be skipped is the entry requirement on each track, and Google prints those as a table. Internal testing: none. Closed testing: complete your app setup. Open testing: gain access to production. Production: run a closed test with at least 12 testers opted in continuously for 14 days, then apply in Play Console and answer questions about your testing, your app and its production readiness. The 12 have to be opted in for the preceding 14 days at the moment you apply, which is why a dropout in week two is expensive. Read on 21 October 2026.
Read that table next to the prerequisites on the page about setting up a test, which state that you must test your app before releasing it to production, and the practical order for a new personal account falls out. Internal testing if you want it. Closed testing for at least 14 days. Apply. Production. Open testing afterwards, if you ever need a public beta at all. The familiar internal, closed, open, production ladder is not what Google documents, and a plan built on it will stall at the point where open testing turns out to be locked.
One question the documentation leaves open, and I went looking for it on the App testing requirements page itself, is whether a second app on the same account repeats the 14 days. That page is written about an account and its apps without separating the two cases, so do not plan around either reading. One more timing note from Google's own prerequisites: after you publish an open, closed or internal test for the first time, the test link can take several hours to reach testers, and later changes can take several hours too. The API documentation says the same about committed edits.
Apple has no equivalent ladder, which is worth saying because people shipping both platforms expect symmetry. There is one TestFlight, with internal and external testers inside it, and a single review gate at the moment you submit. The steps on that side are in publish to app store.
Play Console Help, summary of testing requirements per track, read 21 October 2026
The four tracks, side by side
| What you want to know | Internal testing | Closed testing | Open testing | Production |
|---|---|---|---|---|
| Where it lives in Play Console | Test and release > Testing > Internal testing | Test and release > Testing > Closed testing | Test and release > Testing > Open testing | Test and release > Production |
| Who can join | An email list you control | Email lists, Google Groups or a named organisation | Anyone on Google Play | Everyone in your chosen countries and regions |
| How many testers | Up to 100 per app | Up to 200 lists of 2,000 users, up to 50 lists per track | Unlimited by default, or a cap of at least 1,000 | No limit |
| What unlocks the track | Nothing | A completed app setup | Production access | A closed test, 12 testers, 14 continuous days, then an application |
| Findable on Google Play | No | No | Yes | Yes |
| A paid app installs free for testers | Yes | No | No | No |
| Data safety section required | No | Yes | Yes | Yes |
| Testers can leave a public review | No | No | No | Yes |
Every row above came off a Play Console Help page on 21 October 2026. Those pages carry no visible last-updated date of their own. The only last-updated string in the page source belongs to the support case widget, not to the article, so the date somebody read the page is the best date anyone can give you. The tester counts and the 14 day window are the two figures to re-read before you plan a release around them.
Where this lands if a builder generated your app
The tracks do not care who wrote the code, but they do decide how far a tool can get on your behalf. Internal testing is the only track with no entry requirement, and it is the only one you can reach before app setup is finished. That is exactly why it is the track a build pipeline can deliver to, and why the step after it is always yours.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own, with two-way GitHub sync so the code is never trapped. On Android it publishes to Google Play internal testing and can build a standalone APK. On iOS it uploads to TestFlight. It is $25 a month, with no free plan. What it does not do is submit to the App Store for you, because App Store Review Guideline 4.2.6 requires apps created from an app generation service to be submitted by the provider of the app's content, which is you.
So the honest division of labour on Google Play looks like this. A builder gets a working bundle onto internal testing, where a hundred people can install it today. You complete the app setup, create the closed track, find 12 people who will keep the app installed for 14 days, apply for production access, and answer Google's questions about your testing. No tool can do that part, because the requirement is real humans holding a real app on real phones.
Questions people ask about Play Console tracks
Three testing tracks and production. Internal testing, closed testing and open testing sit under Test and release, Testing in the Play Console sidebar, and production has its own page under Test and release. Closed testing is not one track: Play Console gives you an initial closed track and a Create track button for as many more as your teams need. On top of those there are dedicated form factor tracks for Wear OS, Android TV, Android Automotive OS and Android XR. Pre-registration appears in the same Testing group in the sidebar, but it is a store listing campaign rather than a track you release builds to.
Get a build onto internal testing first, then start the clock
Internal testing costs you nothing to unlock and takes 100 people. Use it to find out whether the app works at all. The 14 days of closed testing are the part you cannot shorten, so the sooner the build exists, the sooner that window can open.
Start building