Beta testing on Google Play runs through Play Console. You upload a signed Android App Bundle to a testing track and send testers that track’s opt-in link. Which track you use isn’t always up to you.
Personal developer accounts created after November 13, 2023 have to run a closed test with at least 12 testers opted in for 14 continuous days before they can apply for production access (Play Console Help, November 2026).
Internal testing doesn’t count toward that, and open testing stays locked until production access is granted.
Which Google Play testing track should the first beta use?
Start with internal testing, move to closed testing, and leave open testing for last. A new personal developer account can’t use open testing at all until Google grants production access.
Personal accounts created after November 13, 2023 can’t reach production without a completed closed test (Play Console Help, November 2026). So closed testing ends up setting your launch date, whatever you do on the other tracks.
| Track | Who joins | Limit | Review and visibility |
|---|---|---|---|
| Internal | Email list, any country | 100 testers per app | Might skip standard review, hidden from search |
| Closed | Email lists, Google Groups, organizations | 2,000 users per list, 50 lists per track | Reviewed, joined through the opt-in link |
| Open | Anyone with the link or store search | Unlimited, or a cap of at least 1,000 | Reviewed, visible on Google Play |
Internal testing
Builds reach internal testers within minutes, and one app takes up to 100 of them (Play Console Help). It’s the only track you can start before app setup is finished, so it’s handy for a first look at the build on a real phone. Testers in any country get access, and paid apps install free for them.
The downsides are real. The 100-tester cap is firm, and none of those testers count toward the closed test requirement. Google notes internal tests might skip standard policy and security review, so a clean run here says little about how review will go.
One more thing catches people out. A tester who opts in to this track stops receiving closed and open builds until they opt out.
Closed testing
Most first betas belong here, since this is the track Google’s production access rule counts. You pick the audience, Google Groups cover larger pools, and feedback stays out of the public rating. App setup has to be finished first, and every tester must opt in through the link before the build reaches them.
The limits are generous at 200 lists per app, 2,000 users per list and 50 lists per track. Extra closed tracks suit separate teams testing separate features. They place no size limit on their groups, though country targeting is not supported on them.
Open testing
Open testing puts the build in front of strangers. The audience can be large, and feedback comes to you privately instead of landing in public reviews. The app and store listing do have to be ready for public view, though. Testers are unlimited by default, or you can set a cap that must be at least 1,000.
I’d skip it for a first beta unless you really want unknown users installing an unfinished build.
What has to be ready in Play Console before the first release
A registered developer account and an app created in Play Console come first. Any track beyond internal testing also needs a finished app setup.
- The developer account costs a US$25 one-time registration fee, and you must be 18 or older. Google may also ask for a government ID and credit card in your legal name (Play Console Help)
- The app entry is created from the All apps page with a name, default language and app or game type. The package name locks once the first artifact is uploaded, so settle it before that
- App setup is the task list on the dashboard, and it covers the store listing, content rating and policy declarations
Internal testing is the exception. Google allows it before setup is complete, and the app shows a temporary name and store listing for up to 48 hours.
Closed testing needs the finished setup. Google’s testing requirements table lists completed app setup as the only entry condition for that track.
Google exempts apps active on internal testing tracks from the Data safety section. That article names internal tracks only, so plan to fill in the declaration before a closed test.
Target API level matters too. Since August 31, 2026, new apps and updates must target Android 16 (API level 36) or higher to be submitted. Wear OS and Android Automotive OS apps need Android 15 (API level 35), Android TV and Android XR apps need Android 14 (API level 34), and the optional extension ran to November 1, 2026 (Android Developers documentation).
Country and region availability changes apply to every track at once. Internal testers are the exception and get access from any location.
How to build and sign the Android App Bundle
Build a signed Android App Bundle (.aab) in Android Studio and sign it with an upload key. Google Play then re-signs what it delivers to devices with the app signing key.
The menu path is Build > Generate Signed Bundle/APK. Google Play has required the .aab format for new apps since August 2021 (Chrome for Developers, Bubblewrap documentation).
You generate the upload key, keep it private and sign the bundle with it, which lets Google verify the upload came from you. The app signing key stays with Google under Play App Signing, and Google uses it to sign the APKs that reach devices.
More than 90% of new apps use a Google-generated app signing key, according to Google’s Play App Signing documentation. That key cannot be downloaded, which protects it from loss.
Losing the upload key doesn’t lock you out. Create a new one in Android Studio, export its certificate to PEM with keytool, and request an upload key reset in Play Console.
Version codes trip people up more often than keys do. Every upload needs a higher version code than any bundle already uploaded to the app.
- Tauri derives the code as major x 1,000,000 + minor x 1,000 + patch, so version 1.2.3 becomes 1002003 (Tauri documentation)
- Reusing a code gives you the error “An AAB with version code (1) has already been uploaded” (Microsoft .NET MAUI documentation)
Devices receive the highest version code compatible with them across the tracks they are eligible for (Play Console Help). Version codes therefore also decide which build a tester actually gets.
Tauri adds one more catch. The first upload has to be made by hand on the Play Console website so Google can verify the app signature and bundle identifier.
For a phone or tablet app, set targetSdk to 36 in build.gradle before you build. A bundle below the target level for its device type does not meet the submission requirement for new apps and updates.
How to create a beta release and send it to a testing track
Open the track in Play Console, create a release, upload the signed bundle, add release notes and start the rollout. Internal builds reach testers without waiting for app review, according to the Google Play Console site.
- Go to Test and release > Testing and pick Internal testing or Closed testing (on the closed page, select Manage track).
- Select Create new release.
- Accept Google-generated signing under Play App Signing when Play Console asks for a signing key on the first release.
- Upload the signed .aab file.
- Name the release and write release notes for testers.
- Select Review release and fix any errors Play Console flags.
- Start the rollout to the track.
Closed and open tracks follow your country and region availability. Internal testers get access from anywhere.
Timing is a little fuzzy. For internal builds, Play Console Help says seconds in one article and minutes in another, so plan on minutes. The first publish on any track can leave the test link missing for several hours, and later changes can take several hours again.
Schedule the first closed release a few hours ahead of any tester deadline.
How to add testers and share the opt-in link
Open the track’s Testers tab, attach an email list or a Google Group, copy the link and send it. Nothing installs until each tester opts in.
Every tester needs a Google Account or a Google Workspace account to join (Play Console Help).
Email lists and Google Groups
An email list takes about a minute to build.
- On the Testers tab, select Create email list.
- Name the list. The same list can be reused for tests on any of your apps.
- Paste addresses separated by commas, or upload a CSV file.
- Select Save changes, then Create, and tick the list in the Testers table.
CSV files carry two traps. An upload overwrites every address already entered, and Play Console rejects files saved as UTF-8 with BOM.
Closed tests also accept Google Groups, entered as yourgroupname@googlegroups.com. Internal tests take email addresses only.
Only members of the named group can join, and each person has to join the group before opting in. Groups suit a changing tester pool because membership is managed outside Play Console.
The opt-in link and the tester install
The link exists only once the app status is Published. Apps in Draft or Pending publication show no link at all.
Each tester opens the link, reads the tester responsibilities, then opts in. Internal and closed tests do not appear in Play Store search, so the link or the Play Store URL is the only way in.
Set the feedback URL or email address before you copy the link, because Play Console shows that channel on the opt-in page.
How do testers send feedback, and what shows up in Play Console?
Testers report through the feedback channel you set, and Play Console adds automated results from the pre-launch report and Android vitals. Testers cannot leave public reviews on a test version (Play Console Help).
| Source | What it reports | Limit for a small beta |
|---|---|---|
| Testing feedback | Tester comments, filterable by date, language, reply state, app version and device type | Only what testers choose to send |
| Pre-launch report | Stability, compatibility, performance and accessibility findings | Lab devices sit in the United States, start at Android 9 and cannot make purchases |
| Android vitals | Crash and ANR rates for Google Play installs | Hidden until enough users make an anonymous report possible |
Testing feedback lives under Monitor and improve > Ratings and reviews > Testing feedback. Keep a running log of it, because the production access form asks you to summarize what testers told you.
The pre-launch report runs on upload when lab capacity allows. Each build is installed on test-lab devices and crawled for several minutes.
Results usually arrive within an hour of upload, according to Play Console Help. If nothing has appeared after two days, upload the artifact again to trigger a new report.
An app with a sign-in screen needs a test account in the Pre-launch report settings. Without credentials, the crawler stops at the login.
Android vitals counts issues per daily active user. Its overall bad behavior thresholds are 1.09% for user-perceived crashes and 0.47% for user-perceived ANRs, and exceeding them can reduce store visibility (Android Developers).
A 12-person beta rarely clears the anonymity bar, so an empty vitals dashboard during testing is normal. Lean on tester reports and the pre-launch report until real traffic arrives.
Why can testers not see or update the app?
When a tester can’t find the build, the cause is almost always release status, opt-in order, search expectations, country settings or version codes.
Visibility and opt-in failures
| Symptom | Cause | Fix |
|---|---|---|
| No opt-in link in Play Console | App status is Draft or Pending publication | Publish the release and wait for Published |
| Link returns “Item not found” or a 404 | Build not live yet, or the account is not on the list | Wait for live status, open the link with the invited account |
| App missing from Play Store search | Internal and closed tests are not searchable | Share the opt-in link or Play Store URL |
| Group member cannot opt in | Joined the Google Group after opting in, or never joined | Join the group first, then open the link |
| App unavailable for one tester | Their country is not on the track | Add the country to the track |
A wrong Google account is the cause developer guides report most often (Testers Community, TesterBee, Indie Hackers). The invited address has to match the account signed in to Play Store on the phone.
Google’s Help page documents the Published rule and the group order. The “Item not found” wording comes from developer reports, not from Google’s documentation.
Wrong build or no update
Installed testers receive new test builds automatically within a few minutes (Play Console Help). When they don’t, version codes are the usual cause, and Play Console puts a label on the failure.
A build is shadowed when a bundle with a higher version code covers the same device configuration. If every bundle on the track is shadowed, the track is superseded and no tester receives anything.
Partially shadowed means some testers get the test bundle while others get production. That usually points to a version code error.
Compare the production version code with the test track before blaming the tester.
When Play beta testing is the wrong tool
Testers without a Google Account can’t join at all. Android Developers documentation lists Firebase App Distribution and Play Console internal app sharing as other ways to hand a build to an internal team.
A quick check with two colleagues needs none of the closed track, unless a personal account still owes the production access run.
What does production access require after the closed test?
Production access takes twelve testers opted in continuously for 14 days, then a reviewed application from the Dashboard.
The tester count and the 14-day rule
Google measures the rule at the moment you apply. At least 12 testers must be opted in then, and each must have been opted in for the preceding 14 days (Play Console Help).
The Help page scopes the rule to personal accounts created after the November 2023 cutoff. Third-party guides add that organization accounts are exempt.
Guides that still say 20 testers are out of date. Google’s own page previously stated 20 before the change, as Android Authority reported.
Sources disagree on what resets the clock. Google’s wording says a tester who opts out before day 14 does not count, and one who opts out and back in needs 14 consecutive days. Testers Community says opt-outs, uninstalls and dips below 12 do not reset the clock, but pausing the track does. Bitcot goes further and says a single inactive tester resets the counter.
Google’s wording counts continuity per tester, so a lapse removes that tester from the total without restarting the clock for everyone else. Pausing the track ends the test, which fits the guide that calls pausing a reset.
Recruit a few testers beyond 12, and never pause the track mid-test.
The numbers to keep in mind: 12 testers opted in when you apply (Play Console Help), each with 14 days of continuous opt-in behind them. Review usually takes 7 days or less, though some run longer. Google’s earlier page said 20 testers (Android Authority), so ignore any guide that repeats that figure.
What the application asks and what happens next
The application has sections for the closed test, the app or game, and production readiness. The closed test section asks how easy recruiting was, whether testers used all features, what feedback you received and how you collected it.
For the app or game, you describe the target audience, the value proposition and an estimated first-year install range. The production readiness section wants the changes you made after testing and how you decided the app was ready.
Google emails the account owner when the review ends. An approval opens the Production page and Open testing, and the sensible move is to release the bundle that survived testing, not a fresh build nobody has run.
A rejection tends to name fewer than 12 opted-in testers or insufficient tester engagement. Google then expects the closed test to continue.
Review is no place to troubleshoot. An app that requires sign-in needs working credentials in Play Console, and the target age group and content rating have to match what the app does.
Add 14 days of testing to a review of up to a week and the first Production page lands about three weeks after the closed release goes live. Budget more if the reviewers ask for further testing.
Google Play Beta Testing FAQ
Can I run more than one test on the same app at once?
Yes. Play Console allows multiple closed tests alongside one open test at the same time. Internal testing can also run concurrently with closed and open tests, as long as each carries a different app version (Play Console Help).
How do paid apps and in-app purchases work for testers?
Testers of a paid app in an open or closed test must buy it, while internal testers install it free. In-app purchases cost testers real money unless you add them to a license testers list.
How do I end a closed test?
Open the closed testing page, select Manage track if prompted, and click Pause track. Testers stop receiving updates, but the app stays installed on their devices.
Guides report that pausing mid-run breaks the continuity production access requires, so wait until the 14 days are done.
Is it safe to pay a service for the 12 testers?
Google documents no approval path for paid testers. Its Help page points to personal networks, colleagues and user communities instead.
The production access form asks how you recruited testers and how engaged they were, and low engagement is a stated reason for continued testing.
What to Set Up First for Google Play Beta Testing
On a new personal account, Google Play beta testing should begin with a published closed release and 12 testers who opt in on the same day. Finish app setup, publish the release, then get everyone opted in on day one.
Google counts continuity per tester, so the twelfth tester to opt in sets the earliest application date, not the release date. A single slow tester delays the launch by as many days as the tester lags.
The trade-off is polish for speed. A closed release published early carries rough edges, but testers report them, and those reports supply the answers the production form asks for.
The sequence holds as of November 5, 2026. A change to Google’s tester count or opt-in duration would reorder it.
- Protecting Users and Brand Standards Across Image-Driven Platforms - November 10, 2026
- Go Cheat Sheet - November 9, 2026
- Build or White-Label Software? How Software Teams Decide What to Resell in 2026 - November 9, 2026
