Google Play closed testing: what we learned shipping two apps through the 12-tester, 14-day rule

If you opened a personal Google Play developer account recently, you've met the rule: before your app can go to production, it has to survive a closed test with at least 12 testers who stay opted in for 14 days in a row. Only then can you press "Apply for access to production" — and Google reviews that application separately from the app itself.

This autumn we took two of our own products through that process: Niyukti, an app that helps people in India track government job openings, and OrbiSketch, a physics puzzle game built in Unity. Very different apps, very different problems. This post is the checklist we wish we'd had on day one — written from the build logs, not from the help pages.

The rule, in one paragraph

For personal developer accounts created after November 2023, Google requires a closed test with a minimum of 12 testers who have been opted in for at least the last 14 days continuously before you can apply for production access. The number was 20 when the rule launched and was lowered to 12 at the end of 2024. Organisation accounts are treated differently, and Google adjusts these policies from time to time — so always confirm the current requirement in your own Play Console before you plan a launch date around it.

1. Treat the 14 days as a real beta, not a waiting room

The production application asks how you ran your test: how testers used the app, what feedback you got and what you changed because of it. If the honest answer is "nothing happened for two weeks", that's a weak application. So we used the window the way it's meant to be used.

On OrbiSketch we shipped several builds to the closed track during testing — fixing release problems, redesigning the daily-puzzle card on the home screen and adding Google Play Games features. Uploading new builds is normal during a closed test; what matters for the clock is that your 12 testers stay opted in.

• Keep a simple changelog of every build and why it shipped. It becomes your answer in the production form.
• Ask testers one or two specific questions ("Was level 1 clear?", "Did sign-in work?") instead of "Any feedback?".
• Write down real bugs testers found. A closed test that found and fixed problems is a stronger story than a perfect one.

2. Twelve testers who actually stay

"12 testers" sounds easy until you need 12 people with Android phones to accept an invite, install from the Play link, and not opt out for two weeks. A few things made this much smoother for us:

• Invite more than 12. Someone always forgets, switches phones or leaves the group — a buffer protects your 14-day streak.
• Use a Google Group (or an email list) as the tester list, so adding people doesn't need a new release.
• Send a short message with exactly two steps: open the opt-in link, then install from the Play Store link. Testers who sideload an APK don't count.
• Ask testers to use the Google account they actually use on their phone. A tester who opts in with one account and opens Play with another won't see the app.
• Send a reminder around day 7 with a new build and a question. It keeps people engaged — and engaged testers give you something to write in the production form.

3. Your release build is not your debug build

This one cost us a build — and it's the lesson we'd underline twice. OrbiSketch is a Unity game. Day to day we tested fast development builds on a phone over USB. When we inspected a release bundle before uploading it, we found three problems that never appeared in development:

1. The INTERNET permission was missing. The game itself plays offline, but Google Play Games (leaderboards, achievements, cloud save) needs the network. In a release build it would simply have failed to sign in.
2. The code shrinker (R8) was removing Google Play Games classes, because our keep rules weren't being applied in the release configuration. Development builds don't shrink code, so they hid the problem completely.
3. A development build had quietly changed a generated Gradle template so the 64-bit (arm64) library was excluded. Google Play requires 64-bit support for native code.

None of these would have shown up in a quick test of a debug APK. We fixed all three, then made a rule: before any upload, build a release-like test APK — same compiler settings (IL2CPP), same shrinking (R8) — install it on a real phone and walk through sign-in, saving and the main flows. Then inspect the bundle itself: permissions, included architectures, the classes you depend on, debug symbols, and that it's signed with your upload key.

4. The sign-in error that wasn't a network error

After adding Google Play Games, sign-in failed on a test phone with NETWORK_ERROR. The network was fine. The cause: the phone had eight Google accounts, and Play Games was using one that wasn't on the tester list. Choosing the tester account inside the Play Games app and clearing its cache fixed it immediately — the console setup had been correct all along.

Two more Play Games details that are easy to miss while you're in testing:

• While the Play Games Services project is still in draft, only accounts added as testers can sign in. Everyone else sees a failure that looks like a bug in your app.
• Add a credential for every certificate that signs your app: the debug key for USB builds and the Play App Signing key for builds installed from the Play Store. With Play App Signing, Google re-signs your app — your upload key's fingerprint is not the one users' phones see.

5. Policy work runs in parallel with code

Niyukti shows information about government job openings. For apps in that space Google expects a clear in-app disclaimer that the app is not affiliated with any government body, and links to the official sources for the information it shows. That is product work — screens, copy, links — so plan it alongside development instead of discovering it in a review email.

The same goes for the Data safety form. Adding Google Play Games meant the game now handled things like user IDs, app interactions and diagnostics through Google's SDK, so the privacy policy, the Data safety answers and the store listing all had to be updated — together, for the exact build being shipped. We keep them in one place in the repository and change them in the same commit as the feature.

• Host a real privacy policy page (and, if you store anything for users, a page that explains how to delete their data).
• Fill the Data safety form from what your SDKs actually do, not from what your own code does.
• Re-read the store listing before every release; promises about "no ads" or "offline" must stay true.

6. Keys and signing: boring, and critical

Losing an upload key or leaking a keystore is the kind of mistake that turns a launch into a support ticket. Our setup is deliberately boring:

• The upload keystore lives outside the project folder and is never committed. Its password is typed at build time, never saved in a file.
• A pre-commit hook blocks keystores, secrets, large files and generated folders from ever entering git.
• Play App Signing is on, so Google holds the app-signing key and the upload key can be reset if it's ever lost.
• Native debug symbols go into the release bundle, so crash reports from testers are readable.

7. Your store page doesn't exist yet (for everyone else)

During a closed test, the public Play Store URL for your app returns "not found" to anyone who isn't a tester. Testers signed in with the right account see a normal listing with an Install button — which makes it easy to assume the app is public when it isn't. We learned to keep store links off websites and social posts until production access is granted, and to say "in testing" instead.

Applying for production

Once your 12 testers have been opted in for 14 continuous days, Play Console lets you apply for production access. The form asks about your test: how you recruited testers, how they used the app and what you changed based on their feedback. Answer it like an engineer writing a short report — specific builds, specific fixes — not like marketing copy.

Niyukti finished its closed test and we submitted the production application on 2 November 2026.

Our pre-launch checklist

1. Recruit more than 12 testers before the first build is ready; use a Google Group.
2. Ship real updates during the test and keep a changelog of what changed and why.
3. Build and install a release-like build (same compiler and shrinking settings) on a real phone before every upload.
4. Inspect the bundle: permissions, 64-bit libraries, required classes, debug symbols, upload-key signature.
5. Add signing credentials for both the debug key and the Play App Signing key for any Google API you use.
6. Finish policy work early: disclaimers, privacy policy, data-deletion page, Data safety form.
7. Keep store links private until production access is granted.
8. Answer the production questions with specific builds and fixes from the test.

None of this is glamorous, but it's the difference between a launch that slips by weeks and one that goes out on the date you promised. If you're planning an Android app and want a team that has already walked this path, we're happy to help.

Frequently asked questions