Google Play Testing Tracks: Internal, Closed and Open Testing

Google Play has no separate beta app. Testing happens on tracks: release channels in Play Console that sit next to production, each with its own testers. For a small Android team, choosing the right track for each build is most of the work of a good beta. This guide covers internal, closed and open testing, how testers join, how a build moves between tracks, and two tools that sit around them: internal app sharing and the pre-launch report. Google's figures below come from its Play Console Help pages as of 6 September 2026.

The short version

• Internal testing reaches up to 100 testers per app, and a new build is with them within minutes.
• Closed testing uses email lists of up to 2,000 people each, or Google Groups, and you can add extra closed tracks.
• Open testing lets anyone on Google Play join, with an optional cap of at least 1,000 testers.
• Builds move between tracks without a fresh upload, and each device gets the highest version code it is eligible for.
• Internal app sharing gives you a download link for any build, good for 100 downloads and 60 days.

The three testing tracks

The tracks live under Test and release > Testing in Play Console. You can run an internal test alongside closed and open tests for different versions, and you can run several closed tests and one open test at the same time.

Source: Google's help page Set up an open, closed, or internal test, as of 6 September 2026. The same page notes that feedback from your testers won't affect your app's public rating.

Internal testing: your team, within minutes

You build an email list in Play Console (Test and release > Testing > Internal testing, then the Testers tab), and you can reuse that list on any of your apps. Google says a new app bundle on this track reaches testers within minutes, which makes it the right home for daily builds.

You can start an internal test before your app is fully set up. Until the app has had its opening review, testers see a temporary name for it on Google Play. Internal testers still pay for in-app purchases unless you add them as licence testers.

One rule catches teams out. A person who opts in to your internal test is no longer eligible for your closed or open test. To join one of those, they have to leave the internal test and opt in again. So keep your own team on the internal track, and don't expect them to see closed builds as well.

Closed testing: invited users

Closed testing is where real users come in. You choose testers in one of two ways on the track's Testers tab:

• Email lists. Up to 200 lists, each with up to 2,000 people, and up to 50 lists on a track.
• Google Groups. You enter the group's address, in the form yourgroupname@googlegroups.com, and members of that group can join. People then join or leave through the group, not through Play Console.

You can also create extra closed tracks with their own names and testers, for example one per feature team. These don't support country targeting.

Closed testing also matters for a reason beyond quality. Developers with personal accounts created after 13 November 2023 must meet Google's testing requirements before they can publish to production. Our guide to the 12 testers for 14 days requirement covers what that involves.

Open testing: public, with private feedback

An open test is visible on Google Play, so your listing has to be ready for strangers. If your app already has a production version, people opt in from your store listing. If it doesn't, Google treats it as early access and people can find the open test through search. You can also share a link.

By default an open test has no tester limit. You can set one, but it must be at least 1,000. Testers on open and closed tracks can send you private feedback through Google Play, and they can't leave public reviews for a test version. Where that feedback lands is the subject of our guide to Google Play testing feedback.

How testers join

Each track has a shareable opt-in link. Google's notes on it, as of 6 September 2026:

• The link appears once the app's status is Published. Apps in Draft or Pending publication show no opt-in link.
• After you publish a test, the link can take several hours to start working, and later changes can take several hours as well.
• Testers see an explanation of what testing involves, then opt in. Each tester has to opt in for themselves.
• For a closed test that uses a Google Group, people must join the group before they opt in.
• You give each track a feedback URL or email address, and it shows on the opt-in page.

Once someone has opted in, their installed app updates to the test version within a few minutes. To end a test, open the track and choose Pause track. Testers keep the app on their device but stop receiving updates.

Moving a build between tracks

You don't upload a build again to move it. On the next track, choose Create new release and use Add from library to pick the app bundle you already uploaded. Google's page Prepare and roll out a release covers the rest.

What a tester actually receives follows a version code rule. A device gets the version with the highest version code that is compatible with it and published on a track the person is eligible for. Everyone is eligible for production. So if production carries a higher version code than your closed track, your closed testers get production. In practice:

• Give each test build a higher version code than the current production build.
• Remember that internal testers receive the internal track's version and nothing from closed or open tracks.
• A common path is internal, then closed, then open, then production, ideally with a staged rollout at the end.

Internal app sharing: a link for any build

Internal app sharing sits outside the tracks. You upload an app bundle or APK and get a download link to send to testers. Google's page Share app bundles and APKs internally sets out its rules, as of 6 September 2026:

• Version codes don't need to be new, debuggable builds are allowed, and you can sign with any key. Google re-signs the build with an internal app sharing key.
• You can send a link to as many people as you want, but at most 100 can download through it. Upload the same build again for a fresh link.
• Links expire 60 days after the upload date.
• You choose whether anyone with the link can download, or people on your email lists.
• Testers have to switch the feature on: in the Play Store app's settings, tap the Play Store version in the About section seven times, then turn on Internal app sharing.
• Builds shared this way can't be added to a release on any track.

That suits a branch build on a colleague's phone, not a beta with real users.

The pre-launch report

The pre-launch report is Google's own test pass. According to Google's page Use a pre-launch report to identify issues, as of 6 September 2026, Play generates one when you upload an app bundle, subject to capacity in its device lab. It installs your app on a set of test devices, crawls it for several minutes by typing, tapping and swiping, and reports stability, Android compatibility, performance and accessibility issues.

• Results usually arrive within an hour. If a report hasn't finished after two days, Google suggests uploading again.
• You can give the crawler test account credentials, a Robo script, up to three deep links and up to five languages, under Test and release > Testing > Pre-launch report > Settings.
• Test devices are in the United States and run Android 9 and above.

How FeedbackKit fits in

Testing tracks deliver builds. They don't give testers a place to ask for features or to see what others asked for. FeedbackKit does: testers post requests and vote on them inside the beta build, through the Jetpack Compose screens in the Kotlin SDK, or the Flutter and React Native SDKs. If your beta and production builds use the same FeedbackKit project, votes from testers and from everyone else add up on the same requests.

FeedbackKit's six statuses are Pending, Approved, In Progress, TestFlight, Completed and Rejected. The 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 a requested feature reaches your closed or open track, move the request to TestFlight, and the people who voted for it can see in the app that it is being tested. The person who submitted it is emailed about the change when TestFlight is one of the statuses your project emails about. Choosing that list needs Pro; plans are on the pricing page, and the emails are covered in our guide to closing the loop.

Those voters make good closed testers for that feature, because they asked for it. Here is how the request list looks in FeedbackKit, with sample data from a fictional hiking app:

If you also ship on iOS, see our TestFlight beta testing guide. And if you want your testers' requests, votes and that testing status in one place, start free with FeedbackKit.