Google Play closed testing requirements: the complete checklist

1. Account and app setup

Before any track is available, the Play Console wants the basics of the app in place. Google states plainly that closed testing requires a completed app setup, so the dashboard's setup tasks are not optional paperwork you can finish later.

If you have a personal developer account created after 13 November 2023, the closed-testing requirement applies to every new app you publish. Organisation accounts are not subject to it today, but still have to complete the same setup tasks before a track can be used.

• Store listing: app name, short and full description, icon, feature graphic and screenshots for every form factor you support.
• App content declarations: privacy policy URL, ads declaration, app access (test credentials if parts of the app are behind a login), content rating questionnaire, target audience and content, and the data safety form.
• Pricing and distribution: countries, free or paid, and the policy declarations the console asks for.
• Identity verification on the account, if the console is still asking for it.

2. Build requirements

The build you put into closed testing is the build Google's reviewers and your testers will judge, so it has to meet the same technical bar as a production release.

• Upload an Android App Bundle (.aab). APK uploads are not accepted for new apps.
• Use Play App Signing — it is mandatory for new apps, and Google holds the app signing key.
• Target the API level Google currently requires for new apps. The requirement moves up roughly once a year (usually around August), so check the Play Console's warning banner rather than relying on a number from a blog post.
• Include 64-bit native libraries if the app ships any native code.
• Fix the crashes and ANRs the pre-launch report flags on the closed-test build; the report runs automatically and reviewers can see it.
• Bump the version code for every upload — a new build on the same track keeps your testers opted in and gives them a reason to open the app again.

3. Setting up the closed track

The closed testing track is the only track Google measures. Internal testing is optional (and uncounted); open testing unlocks after production access is granted.

1. 1In the Play Console open Testing → Closed testing and create a track (the default one is called Alpha; the name does not matter).
2. 2Choose how testers join: an email list you maintain in the console, or a Google Group whose members become testers automatically.
3. 3Select the countries and regions where testers can install the app.
4. 4Upload the app bundle, write release notes and submit the release for review. Releases on closed tracks are reviewed too, so allow some time.
5. 5Copy the opt-in link from the Testers tab once the release is live. That link is what every tester needs.

4. 12 testers, 14 consecutive days

This is the headline requirement: at least 12 testers opted in continuously for at least 14 days. Each tester's days are counted individually and must be consecutive. A tester who opts out and later opts back in starts again from zero, and a tester who is removed from the email list stops counting immediately.

When you apply for production access, Google checks that 12 testers have been opted in for the preceding 14 days — so the window needs to be satisfied at the moment you apply, not at some point in the past.

• Recruit a few more than 12 so one or two drop-outs do not reset your timeline.
• Start counting the 14 days from the day the 12th tester is opted in and has installed the app, not from the day you created the track.
• Keep the tester list unchanged for the whole window; removing an inactive tester to add a new one also removes their days.

5. Engagement during the test

Google's help pages say that developers may be asked to keep testing when there were fewer than the required opted-in testers or when tester engagement was insufficient. Engagement is not defined as a number, but the intent is clear: the test should look like real people using a real app, not a dozen installs on day one and silence afterwards.

Treat the closed test as a product sprint. Ask testers to try specific flows, ship at least one update based on what they report, and collect their feedback somewhere you can summarise later — the production application asks you to describe exactly that.

• Testers open the app on multiple days across the window, not only on install day.
• Core features are exercised: sign-up, the main task the app exists for, settings, notifications.
• Feedback is collected and acted on, with at least one follow-up build.
• Crashes and ANRs reported by testers or the pre-launch report are fixed before you apply.

6. The production access application

Once the test meets the bar, the dashboard shows an Apply for production button. The form has three sections — about your closed test, about your app or game, and about your production readiness — and each section is saved only when you press Next or Apply. Leaving the page early loses your answers.

Google usually completes the review within about seven days, though it can take longer, and emails the account owner. Approval unlocks the Production track and open testing; otherwise you will be asked to continue testing.

The one-page checklist

Copy this into your task list and tick it off in order.

• Account verified; dashboard setup tasks complete (listing, content rating, data safety, target audience, app access, privacy policy).
• Signed app bundle uploaded with the current target API level; pre-launch report clean.
• Closed track created with an email list or Google Group; release live; opt-in link copied.
• At least 12 testers opted in via the link and installed from Google Play (recruit a buffer).
• 14 consecutive days completed by 12+ testers with real usage; at least one update shipped during the window.
• Feedback collected and summarised; production application drafted with specific numbers.
• Applied from the dashboard; watch the account owner's inbox for Google's decision.