Google Play Production Access

Production access is what lets you publish a release to the general public on Google Play rather than keeping it limited to a testing track. For some developer accounts it is granted only after Google reviews an application. For others it is available without that step.

It is worth separating two things that get discussed together. Being technically able to release is one thing. Being ready to release is another, and the review is interested in both.

For developer accounts subject to the rule, the closed testing prerequisite is a condition of applying: a minimum number of testers who remain opted in for a continuous period. The figure most commonly cited is 12 testers for 14 continuous days.

Because Google sets and revises this policy, confirm the current requirement for your own account type before you plan a window. App testing requirements for new personal developer accounts is the authoritative source.

Why Google asks for testing at all

The requirement exists to filter out apps that have never run outside a developer's own device. A closed test demonstrates that the app has been installed and used by other people, on other hardware, for a sustained period.

That framing is useful when preparing an application, because it tells you what the record needs to show: real testers, real installs, a real window, and enough continuity to be credible.

Nothing here is complicated. All of it is easier if the campaign recorded it as it happened, and laborious if you are reconstructing it the week you apply.

• The exact start and end dates of the testing window
• The number of testers actually opted in, never the number invited
• The number of days the opted-in count stayed at or above the threshold
• Any interruption, its date, and what caused it
• Which builds were tested, and when each one went out

Participation you can stand behind

The temptation is to describe the campaign at its best moment: the day the full roster had opted in. The safer approach is to describe the period as it actually ran, including the days when it dipped.

• State opted-in testers, and keep invitations out of that number.
• Describe the window continuously, saying whether the count ever fell below the threshold.
• If testers were replaced, say so and give the dates.
• Use the same figures as your campaign record, so the description and the evidence agree.

Testing feedback

Feedback is what turns 'we tested' into 'here is what testing found'. It does not need to be extensive. It needs to be genuine and attributable to a build.

• Group findings by the build they were raised against, so it is clear what was fixed when.
• Note the device and Android version where the finding occurred.
• Record what changed as a result, including findings you decided not to act on and why.
• Keep the raw record. A summary nobody can trace back is weaker than a list with dates attached.

The record you keep afterwards is written during the window, not assembled the week you apply. These are the figures it has to be able to produce.

• The testing window, with exact start and end dates
• Testers opted in, and testers invited, kept as separate figures
• The number of continuous days the count stayed at or above the threshold
• Any interruption, its date, and what caused it
• The builds tested, and the findings raised against each one

If a figure in your application would not be traceable to a date in this summary, that is a sign the campaign was not recorded closely enough while it was running.