Quick Answer
As of August 14, 2026, Google Play requires developers with personal developer accounts created after November 13, 2023 to run a closed test with at least 12 testers who have remained opted in for at least the last 14 days continuously before they can apply for production access. Google announced the gate on November 9, 2023 at 20 people for a minimum of two weeks, then reduced the tester minimum to 12 on December 11, 2024 while keeping the 14-day period. Reaching the threshold makes a developer eligible to apply, not approved: Google reviews the application, says that review usually takes 7 days or less, and can ask for more testing. Internal testing has its own 100-tester cap and does not satisfy this closed-test prerequisite. Closed-test access can be managed through email lists or Google Groups, and managed Google Play organizations can also be granted access.
If the number you are missing is the twelve people
That is the one figure on this page you cannot look up, and it is what PrimeTestLab supplies: real testers who stay opted in for the full window. How that works →
Most pages that rank for these queries answer a slightly different question than the one being asked. The searches behind this topic are overwhelmingly verification searches: someone has already read a number somewhere and wants to know whether it is current, what it actually counts, and who says so. That is a different job from a tutorial, so this post is built as a reference. Each statistic gets one sentence, one date qualifier and one source, and nothing is rounded up from a plausible guess into a fact. Everything here is current as of August 14, 2026, checked the same day against Google's own Help pages, developer documentation and published safety reporting.
Two habits are worth carrying into every block below. First, 12 is current and 20 is historical; pages still printing 20 as a 2026 requirement are quoting an announcement Google superseded in December 2024. Second, a threshold is not a decision. Almost every distressed thread in Google's own Developer Help Community comes from someone who met the numeric condition and expected that to be the end of it.
The Reference Desk
Three instruments built for a page of numbers. Nothing here needs an account, an upload or a network request; each one runs in your browser against values you choose.
The five most-quoted numbers
Five figures carry almost all of the demand behind this topic: 12 testers, 14 continuous days, the November 13, 2023 account cutoff, the December 11, 2024 reduction from 20, and the 7 days or less Google gives as the usual production access review time. Each one below is written as a complete sentence, so it can be lifted without losing what it means.
-
01
Verified
Google Play's current closed-testing minimum is 12 opted-in testers for at least the last 14 days continuously, for affected new personal developer accounts.
Google Play Console Help, answer 14151465 · checked August 14, 2026
-
02
Verified
The 12-testers rule applies to personal developer accounts created after November 13, 2023.
Google Play Console Help, answers 14151465 and 6112435 · checked August 14, 2026
-
03
Verified, historical
Google's original announcement, on November 9, 2023, called for 20 people for a minimum of two weeks before applying for production access.
Android Developers Blog, November 9, 2023 · checked August 14, 2026
-
04
Verified
Google reduced the requirement from 20 testers to 12 on December 11, 2024, while the two-week testing period remained.
Android Developers Blog update, plus Google's official Help Community guide · checked August 14, 2026
-
05
Verified
Google says a production access application usually takes 7 days or less to review, although it can occasionally take longer.
Google Play Console Help, answer 14151465 · checked August 14, 2026
Instrument 01
Citation Composer
Pick any number on this page and a format. You get the sentence it supports, its source, the date it was checked, and its confidence grade, ready to paste into a document, a ticket or a reply.
Every line is dated on purpose. Policy pages move, and an undated statistic is how a superseded number stays in circulation for two years.
Where to see closed testing progress and statistics in Play Console
Open the app in Play Console and check the production-access testing requirement on the app Dashboard. The qualifying number is the opted-in tester count shown for that requirement, not the email-list size, not installation events, and not the Play Store install count.
This is its own search, and it deserves the direct answer above rather than an explanation first. The figure that decides your eligibility is the count Play Console recognises against the production-access requirement itself. That is the number to watch, and it is the one the application gate reads.
The reason this confuses people is that several other counts are visible nearby and none of them is the qualifying one. These are four different measurements:
| What you can see | What it measures | Is it the qualifying number? |
|---|---|---|
| Addresses on your email list or Google Group | Who is eligible to join the test. | No |
| Installs or installation events in Statistics | Device-level install activity, on its own reporting delay. | No |
| Play Store listing install count | Store-side aggregate, not test enrolment. | No |
| Opted-in testers shown for the production-access requirement | Testers Play Console counts as continuously opted in to the closed test. | Yes |
Source: Play Console Help, answer 14151465 and answer 9845334 · checked August 14, 2026
Two practical consequences follow, and they are different in kind. The qualifying tester count can differ from installation figures because they measure different things, so a mismatch between them is expected rather than a fault. Developers also report delayed counter updates, but Google does not publish the counter's refresh schedule or its calculation algorithm, so there is no documented interval to wait out. Use the Dashboard production-access requirement as the final indication of eligibility. The full diagnosis for a counter stuck below your roster size is in the post on adding 12 testers and seeing zero opted in.
There is no separate "closed testing statistics" screen. Play Console reports installs, vitals and ratings under Statistics and Android vitals, and reports your eligibility against the production-access requirement on the Dashboard. Those are two different surfaces, and only the second one is measuring the 12/14 condition. Reading the first and expecting the second is the most common version of this confusion.
Partial Google documents both surfaces; it publishes no combined progress report by that name.
The 12 testers, 14 days rule
For an affected account, Google's condition is a closed test with at least 12 testers who have been opted in for at least the last 14 days continuously. Meeting it unlocks the ability to apply for production access from the app's Dashboard. It does not unlock production itself.
"If you have a newly created personal developer account, you must run a closed test for your app with a minimum of 12 testers who have been opted-in for at least the last 14 days continuously."
Google Play Console Help, answer 14151465 · checked August 14, 2026
Read that sentence slowly, because four separate constraints are packed into it and each one is a place developers lose weeks. The track must be closed. The count is at least 12. The state being counted is continuous opt-in status rather than installs, downloads or a documented daily-active-use target. And the window is the last 14 days, continuously, which means the qualifying period is the one immediately behind you rather than any fourteen good days you can point to in your history.
That is the published numeric threshold, and it is only half of the picture. Engagement is assessed separately, and it is still material: Google asks how testers engaged with the app, whether their usage resembled the usage you expect in production, and what feedback they provided, and it says insufficient tester engagement can result in a request for more testing rather than a grant of access. Opt-in status is what the count measures. Engagement is what the review reads.
| Statistic | Current value | What it actually means |
|---|---|---|
| Affected account type | Personal | The gate is documented against new personal accounts, not against every developer on Google Play. |
| Account creation cutoff | After November 13, 2023 | Personal accounts created on or before that date sit outside the cohort this Help page describes. |
| Required track | Closed testing | Internal testing does not substitute for it, however many people you run through it. |
| Tester minimum | 12 | Current value. It was 20 until December 11, 2024. |
| Required period | 14 days continuously | Those testers must have stayed opted in across the whole of the most recent 14 days. |
| Next step once you qualify | Apply for production access | An application from the app Dashboard, not an automatic promotion. |
| Application sections | 3 | Your closed test, your app or game, and production readiness. |
| Stated review time | 7 days or less, usually | Google says usually. It allows explicitly for longer reviews. |
Source: Play Console Help, answer 14151465 · checked August 14, 2026
The dates in the tester-minimum row have a narrative behind them that this post deliberately does not retell. If you want the full account of how 20 became 12 and what Google said at each step, that history lives in the post on Google Play changing 20 testers to 12. Everything here is the evidence, not the story.
Who the requirement applies to
Google Play offers two developer account types, Personal and Organization, and charges the same US$25 one-time registration fee for either. The additional testing requirement is documented against personal accounts created after November 13, 2023. That is the whole of what the current Help text says about scope.
Say this carefully. "Organization accounts are exempt" is the phrasing everyone uses, and it is a reasonable practical read of the scope, but Google does not write that sentence in the Help text reviewed for this page. The defensible version is the one this post uses: the documented 12-testers production-access requirement is scoped to affected new Personal accounts. If you are choosing between the two account types, the trade-offs are covered in the personal versus organization account post.
Partial Supported by scope, not by an explicit exemption sentence.
What "14 days continuously" is counting
This is the single most rewritten sentence in the whole topic. Commercial pages routinely restate it as 12 installs, 12 daily active users, or an app that must stay installed for 14 days. Google's own wording is about opt-in status held continuously, and the difference matters because it changes what you monitor while the clock runs.
Google says this
- A minimum of 12 testers.
- Opted in for at least the last 14 days continuously.
- The test must be a closed test.
- Each tester needs to opt in through the test enrollment process.
- A user opted into an internal test must opt out of it before becoming eligible for an open or closed test.
Google does not say this
- That testers must open the app every day.
- That the requirement is 12 installs or 12 daily active users.
- That an uninstall automatically counts as opting out.
- That a single dropout resets everyone's clock to day zero.
- That every tester must be on a physical device rather than an emulator.
None of that means engagement is irrelevant. It means engagement is judged somewhere else: in the production access application, where Google asks how you recruited testers, how they engaged with the app and what feedback you acted on. Treat the 14-day window as an opt-in count to protect and the application as the place your testing quality is assessed. The day-by-day mechanics of the window are covered in the post on the 14 consecutive days rule.
Instrument 02
Your Numbers
This page carries around thirty figures and only some of them are conditions for production access. Answer three questions and it sorts them into what you must satisfy to apply, what happens after you qualify, and the separate publishing facts that are true regardless.
Every Google Play testing track number
Internal testing supports up to 100 testers per app. Closed testing can be managed through email lists or Google Groups, and managed Google Play organizations can also be granted access to a track. Email lists hold up to 2,000 users each, with 50 lists per track and 200 lists in total; Google states there are no size limits on Google Groups used with additional closed tracks. Open testing is either Unlimited or limited to a configured cap of at least 1,000.
| Track or method | Documented limit | Eligible track for the prerequisite? | The qualification that matters |
|---|---|---|---|
| Internal | 100 testers per app | No | Optional track. Builds are normally available to testers within minutes of being published. |
| Closed, via email list | 2,000 users per list | Yes | Being on the list is not the same as opting in. Only opted-in testers count. |
| Closed, email lists per track | 50 lists | Yes | A configuration limit on lists. Do not multiply it into a unique-tester ceiling. |
| Closed, total email lists | 200 lists | Yes | Account-level configuration limit described by Google. |
| Closed, via Google Group | No size limit stated for groups used with additional closed tracks | Yes | Testers must join the group and then opt in. Group membership alone does not enrol anyone. |
| Closed, via managed Google Play organization | No published tester figure | Yes | You choose which organization can access the track; that organization's admins assign the users. |
| Open | Unlimited, or a configured floor of 1,000 | No | The 1,000 is the minimum you may configure a limit to, not a number of participants to recruit. |
| Any track, tester account | Google Account or Google Workspace account | Prerequisite for all | Google says users need a Google Account or a Google Workspace account to join a test. |
Sources: Play Console Help, answer 9845334 and answer 14151465 · checked August 14, 2026
Internal testing numbers
Internal testing supports up to 100 testers per app, and Google's wording is that a new app bundle published to the internal track is available to testers within minutes. It is the fastest track for getting a build in front of a small group, which is exactly why it traps people: the production access prerequisite names a closed test, so time spent on the internal track does not accumulate toward the 14 days no matter how many people you put on it or how diligently they use the app. It is not the most permissive track either, since an open test can be set to Unlimited.
Internal testing has one genuine advantage the other tracks do not: if the app is paid, internal testers can install it for free. On an open or closed test, Google says testers still need to purchase a paid app. That is a real cost to plan for, and it is separate from the $25 registration fee.
The most expensive mistake on this page
Running twelve people through internal testing for fourteen days produces nothing that counts toward production access. There is a second trap layered on top: Google says a user opted into an internal test needs to opt out of internal testing before becoming eligible for an open or closed test, so the same people can silently fail to register on the track that does count.
Closed testing list limits
Closed testing can be populated three ways, and the famous numbers only describe one of them. Google documents tester email lists, Google Groups, and granting a managed Google Play organization access to the track. The figures everyone quotes, 2,000 users per list, 50 lists per testing track and 200 email lists in total, are limits on email lists specifically. They are three separate configuration ceilings, and none of them is a statement about how many unique humans may test your app.
Whichever route you use, the enrolment step is the same and it is the one that decides your number. Testers need a Google Account or Google Workspace account, and each one has to opt in through the enrolment link. For a Google Group, Google is explicit that users need to join the group before opting in to the test, so group membership and qualifying tester are two different states with two different counts.
Do not multiply these numbers. Fifty lists times two thousand users is a calculation, not a Google statistic. Google expresses list limits, not a definitive unique-person cap, so a figure like "100,000 maximum testers" is a derived number being presented as documentation. This page does not publish it, and neither should anything quoting this page.
There is a second reason the arithmetic fails. Email lists are not the only way to populate a closed test: Google also documents using Google Groups, and says there are no size limits to those groups. A ceiling that can be bypassed by choosing a different configuration was never a ceiling on testers in the first place.
Open testing numbers
An open test can be set to Unlimited, or limited to a tester cap you configure, in which case that configured limit must be at least 1,000. This is the most misquoted number in the whole topic. It is a floor on a setting, not a requirement to find a thousand people, and it has nothing to do with the closed-test gate. Google also documents running multiple closed tests alongside one open test at the same time.
If open testing is greyed out
For an affected new personal account that is the expected state, not a bug. Google's current requirement page says open testing becomes available when production access is available, so the order is closed test first, then application, then the other tracks. What each track is for, and when to choose it once they are all open to you, is covered in the internal versus closed versus open testing comparison.
Instrument 03
Track Cap Planner
Choose a track, say whether you are testing to satisfy the new-personal-account requirement, and enter the roster you have in mind. This checks it against the documented limits for that specific configuration, rather than applying the 12-tester threshold to every closed test ever run.
Production access statistics
Day 14 does not publish anything. It makes you eligible to apply for production access from the app's Dashboard, through an application with 3 sections. Google then reviews it, says that review usually takes 7 days or less, and can conclude the app is not ready and ask you to keep testing. A successful application grants production access and open testing.
-
Step 1
Qualify
At least 12 testers opted in for at least the last 14 days continuously, on the closed track.
You control this -
Step 2
Apply
A 3-section application from the app Dashboard: your closed test, your app or game, and production readiness.
You control this -
Step 3
Review
Google decides. Usually 7 days or less, occasionally longer, and the outcome can be a request for more testing.
Google controls this
Almost every distressed thread in Google's own Developer Help Community collapses into the gap between steps two and three. Developers post titles like "production access rejection despite 12 testers opted-in for 14 days continuously" and describe testers who never uninstalled, because they had understood the threshold as the decision. It is not. Twelve testers for fourteen continuous days is an eligibility condition, and Google's documented process is explicit that it can require continued testing if it judges the app is not ready.
Completing 12 testers for 14 continuous days makes a developer eligible to apply for production access. It does not guarantee production approval.
Google Play Console Help, answer 14151465 · checked August 14, 2026
Nobody outside Google can put a number on how often the review says no, because Google does not publish one. Repeated rejection is well attested in Google's own Help Community rather than in a statistic, so this page treats it as a documented possibility with community evidence, not as a rate. Recovery mechanics after a denial, including whether a new window starts, are covered in the post on why closed testing gets rejected.
What Google asks after the closed test
The application has three sections. Google's questions cover how you found and worked with your testers, what the app is and who it is for, and whether it is ready for a public audience. There is no published scoring formula behind them, so the useful posture is accuracy rather than optimisation.
How testers were recruited, how they engaged with the app, and what feedback came back.
What the app does, who it is for, and the value it offers that audience.
What changed as a result of testing and why the app is ready for production now.
There is no published answer key. Google names the three sections and the subject matter it asks about. It does not publish a scoring model, a character budget, or a list of phrases that pass. Any page presenting one has invented it. Worked examples of how developers actually describe their test are in the production access questionnaire post.
On timing, Google's 7 days or less is the only figure with a primary source behind it, and Google qualifies it with "usually". Treat it as a description of the common case and not as a deadline you can plan a launch date around. Stage-by-stage review timing across the whole publishing journey is covered in the Google Play review time post.
Closed testing policy timeline
Four dates carry the whole history: the announcement, the affected-account cutoff four days later, the reduction from 20 to 12 in December 2024, and the current state. The announcement date and the cutoff date are different things, and conflating them is the most common error in write-ups of this policy.
-
November 9, 2023
Announced at 20 testers
Google announced that new personal developer accounts would need to test with 20 people for a minimum of two weeks before applying for production access, so developers could identify issues and get feedback before launch.
Verified, historical -
November 13, 2023
The affected-account cutoff
The date Google's current Help page uses to define who is affected: personal developer accounts created after it. This is a cohort boundary, not the announcement date, and the two are four days apart.
Verified -
December 11, 2024
20 became 12
Google updated the policy to reduce the testing requirement from 20 testers to 12. The 14-day period was unchanged. Developers noticed the change in Play Console before the documentation caught up, which is why some contemporaneous threads treat it as a possible bug.
Verified -
Today, August 14, 2026
12 testers, 14 continuous days
The current state, checked against Google's requirement page on this date. No replacement threshold or end date for this rule was found in the sources reviewed.
Verified
That is the evidence, without the story. The full account of what changed, why developers reacted the way they did, and what it meant for apps that were mid-test at the time lives in the post on Google Play changing 20 testers to 12, which remains this site's canonical record of the policy change.
What Google says, and what it does not
Eight claims do most of the damage in this topic, and all eight are extrapolations from Google's actual wording rather than quotations of it. The table below pairs the symptom as developers report it with the most defensible reading of the documentation, and grades how firm that reading is.
| What developers report | Most defensible explanation | What to check | Grade |
|---|---|---|---|
| "I added 12 emails but Play Console counts fewer." | Being on an email list is not the same as completing the tester opt-in. | Confirm each tester used the enrollment link with an eligible account and actually opted in. | Verified |
| "I ran internal testing with 12+ people for 14 days." | The prerequisite specifies closed testing. Internal time does not accumulate toward it. | Configure and start the Closed testing track. The 100-person internal allowance does not substitute. | Verified |
| "I reached day 14, why can I not publish?" | Day 14 qualifies you to apply for production access, nothing more. | Open the app Dashboard and complete the production access application once eligibility shows. | Verified |
| "Google rejected me even though I had 12 testers." | The threshold governs eligibility to apply, not the outcome of the review. | Continue testing if asked, and answer the application accurately on recruitment, engagement, feedback and readiness. | Verified |
| "Open testing is disabled for my app." | Expected for the affected account flow. Open testing becomes available when production access is available. | Complete the closed test and the production access application first. | Verified |
| "Do my testers have to open the app every day?" | Google specifies continuous opt-in. It publishes no one-open-per-day numeric condition. | Encourage genuine use and collect feedback, because engagement is assessed in the application, but do not present daily opens as a Google rule. | Verified |
| "One tester uninstalled. Did my 14 days reset?" | The published condition is continuous opt-in, and the source does not equate uninstalling with opting out. | Check actual opt-in state and whether at least 12 testers still satisfy the continuous 14-day condition. | Partial |
| "My tester count looks wrong after a rejection." | Reported repeatedly in Google's Help Community. Google does not document a counting algorithm that explains it. | Reconcile roster against opt-in state before assuming a Console fault. Ghost tester is developer language, not a Google term. | Reported |
The pattern across all eight rows is the same. Google publishes a threshold and a process; it does not publish the mechanics underneath them. That gap is where commercial pages insert confident-sounding detail, and it is why this post grades every line instead of flattening them into one voice. If your counter specifically is stuck below the roster size, the full diagnosis is in the post on adding 12 testers and seeing zero opted in.
On paid tester services, including this one. Developers in Google's Help Community have asked directly whether using a paid service caused their rejection. No primary Google source found for this page says paid tester services are permitted, and none says they are prohibited. The accurate position is that Google documents requirements and reviews applications; it does not publish a rule about recruitment channels either way. Any page claiming Google endorses or bans them is filling a gap in the documentation with an opinion.
Unverified No primary Google source located in either direction.
Numbers Google does not publish
Six of the most-quoted items in this topic had no primary Google source behind them in the sources reviewed for this page: a closed-testing approval rate, a rejection rate, an exact current count of apps on Google Play, a daily app-open threshold, a scoring formula for the production access review, and the algorithm behind Play Console's tester count. If a page hands you one of these as a Google statistic, ask it which primary Google page the figure came from.
-
A closed-testing approval or success rate No source found
No Google-published percentage describing how often developers who meet the 12/14 threshold are granted production access was located. Percentages in circulation come from commercial services describing their own results, which is a different measurement with a different denominator.
-
A Google Play rejection rate No source found
Google publishes counts of policy-violating apps stopped, not a denominator-based rejection percentage. A rate cannot be reconstructed from those counts, because the population they were drawn from is not published alongside them.
-
An exact current app count for Google Play Millions, unquantified
Google's current material describes Play as home to millions of apps and content rather than giving a precise inventory figure. Commercial app-intelligence estimates exist and are not Google numbers, so this page does not substitute one.
-
A daily app-open requirement Not in the rule
The current eligibility rule specifies continuous opt-in and does not state a numeric requirement of one app open per tester per day. Google does ask about tester engagement when evaluating production access, which is where engagement genuinely matters.
-
A production access scoring formula No source found
Google names the three application sections and the subject matter it asks about. No weighting, threshold, character budget or model for how answers are evaluated appears in the documentation reviewed for this page.
-
A tester-count or reset algorithm No source found
Google publishes the condition that at least 12 testers must have been opted in for the last 14 days continuously. It does not publish how Play Console derives that count, what happens to the individual clocks when a tester drops out, or whether any event resets the window for everyone. The reset stories in circulation are inferences from Console behaviour, not documentation.
There is one more absence worth naming, because it is the one most often filled with something that sounds authoritative. Google has not published a standalone numerical impact for the 12-tester requirement. Its safety reporting groups testing requirements with developer verification and mandatory pre-review checks and describes the combined effect. Any sentence of the form "the 12-tester rule reduced X by Y percent" is a construction, not a citation.
A test you can run on any page, including this one
For every statistic, ask three questions: what exact sentence is this drawn from, when was that sentence last checked, and does the source say it or does the page merely imply it? A statistic that cannot survive those three questions is not a statistic. Every number above is written so it can be checked back to a Play Console Help answer number or a named Google publication, which is also why the Citation Composer near the top of this post attaches the source and the date to whatever you copy.
How PrimeTestLab helps with the number you cannot look up
Every verified figure above can be traced to a primary source; the partial interpretations and the figures Google does not publish are labelled separately. Only one figure on this page is a task rather than a fact: 12 real people, opted in, for 14 continuous days. PrimeTestLab supplies that group on real devices spanning Android 7 to 17, from $19.99, and holds it for the whole window so the count does not fall below the threshold while you are working on the build.
What that buys is a stable opt-in count, which is the one variable the documentation makes you responsible for and the one that quietly breaks most self-organised tests. It does not buy a decision. Google reviews the production access application itself, and no service can promise the outcome of that review. What we can commit to is the part inside our control: if a campaign does not deliver the testing you paid for, the guarantee is a free retest or a full refund.
| What has to be handled | Recruiting the group yourself | A managed group |
|---|---|---|
| At least 12 testers | Friends, forums and swap groups. Finding twelve is possible; finding twelve who follow through is the hard part. | 12 allocated up front, with larger tiers at 20 and 25 testers for a buffer above the minimum. |
| Opted in for 14 continuous days | You are monitoring opt-in state daily and chasing anyone who drops, because falling below the minimum breaks the continuous condition. | The group is held for the full window, so the count you are protecting is somebody else's job to protect. |
| Tester and device diversity | Whoever you can persuade, on whatever hardware they own. | Real people on real devices spanning Android 7 to 17, across 120+ countries. |
| Feedback for the readiness question | Depends entirely on how engaged your recruits are. Often the weakest part of a self-run test. | Structured tester feedback you can point to when the application asks what changed as a result of testing. |
| Cost | No cash outlay, paid for in days of chasing people during the window you most need to be building. | From $19.99 for the 12-tester tier. |
| The production access decision | Google's | Still Google's. No service can promise approval, and any that does is describing something it does not control. |
For context on scale rather than as a claim about your app: PrimeTestLab has run closed testing for 7,400+ apps with a 99.9% record across 120+ countries. Those are our numbers, measured on our campaigns, and they belong in the same category as every other first-party figure on the internet: useful, and not a Google statistic.
Frequently Asked Questions
Do I still need 20 testers for Google Play in 2026?
No. The current minimum is 12 testers, not 20. Google announced a 20-person, minimum-two-week requirement on November 9, 2023 and updated the policy on December 11, 2024 to reduce the tester minimum to 12, while the 14-day period stayed. Pages that still print 20 as the 2026 figure are quoting the superseded announcement.
Do the 12 testers have to stay opted in for all 14 days?
Google's wording is that at least 12 testers must have been opted in for at least the last 14 days continuously. For that published numeric threshold Google counts continuous opt-in status rather than installs, downloads or a documented daily-active-use target. Engagement is separate but still material: Google asks how testers engaged with the app, whether their usage resembled expected production usage and what feedback they provided, and insufficient engagement can result in a request for more testing. A group of testers who each participated at different times does not add up to the same thing as 12 testers who were all opted in across the same continuous 14-day window.
When does the 14-day period actually begin?
Not when you add the email addresses. Adding someone to a list or a Google Group only makes that person eligible to join; the qualifying state is testers who have completed the opt-in and then remained opted in. The condition Google publishes is that at least 12 testers have been opted in for at least the last 14 days continuously, so treat the eligibility state Play Console shows for the production-access requirement as the source of truth rather than counting days from the date you configured the track.
Does internal testing count toward the 12 testers for 14 days?
No. Google's production access prerequisite expressly requires a closed test. Internal testing is described separately as an optional track that supports up to 100 testers per app, and internal builds are normally available to testers within minutes of being published. Running 12 people through internal testing for 14 days does not satisfy the closed-testing requirement.
Do my 12 testers have to open the app every day?
Google's public numeric requirement does not state a one-app-open-per-day threshold. The documented numeric condition is continuous opt-in. Engagement still matters, because the production access application asks developers about how testers were recruited, how they engaged with the app and what feedback they gave, and Google says insufficient tester engagement can result in a request for more testing. What no Google source found for this page publishes is a daily-open number, so treat genuine use as something to encourage and describe, not as a documented quota to hit.
I finished 14 days. Am I automatically approved for production?
No. Completing a qualifying closed test makes you eligible to apply for production access from the app's Dashboard in Play Console. Google reviews that application and can conclude the app is not ready and ask you to continue testing. Twelve testers for 14 continuous days is an eligibility threshold, not an approval guarantee.
How long does Google take to review production access?
Google's current Help page says the production access review usually takes 7 days or less, and that it may occasionally take longer. That is a description of the usual case, not a service level agreement or a guaranteed decision date, so it should never be quoted as an exact seven-day deadline.
Can I use open testing instead of closed testing?
Not for this prerequisite. Google's current requirement page describes a closed test for affected new personal accounts, and says open testing becomes available when production access is available. The 1,000 figure attached to open testing is the minimum configured tester limit when an open test is not set to Unlimited, not a requirement to recruit 1,000 participants.
Can I use Google Groups instead of individual email lists?
Yes. Google documents closed-test access through tester email lists, through Google Groups, and by granting a managed Google Play organization access to the track. The 2,000-users-per-list, 50-lists-per-track and 200-lists-in-total figures describe email lists specifically; Google states there are no size limits on Google Groups used with additional closed tracks. Group membership is not the same as being opted in: Google says users need to join the group before opting in to the test, so those are two separate counts.
Do my testers need Google Accounts?
Yes. Google says users need a Google Account or a Google Workspace account to join a test. An address sitting in your contacts or an ordinary mailbox that is not attached to an eligible Google account cannot complete the opt-in, which is one reason a roster can look complete while the qualifying count stays lower.
Do closed testers have to purchase a paid app?
Yes, if the app itself is paid. Google says testers in an open or closed test still need to purchase the app, while testers in an internal test can install a paid app for free. That cost sits alongside the US$25 one-time developer registration fee and anything you pay a testing provider, and it applies to the closed track that the production-access requirement asks for.
Do Organization accounts need the 12-testers test?
Google's current documentation scopes this additional testing requirement to personal developer accounts created after November 13, 2023, and separately identifies Personal and Organization as the two developer account types. The precise, defensible statement is that the documented 12-testers production-access requirement is scoped to affected new Personal accounts. Google does not use the sentence Organization accounts are exempt in the Help text reviewed for this page.
Why does Play Console show fewer testers than the emails I added?
Adding an address to an eligible email list and having that person complete the tester opt-in are two different steps. Google tells developers to distribute the opt-in URL and says each tester needs to opt in. Developer Help Community threads repeatedly show rosters larger than the qualifying count for exactly this reason, so check the opt-in state of each tester rather than the size of the list.
Where do I see my closed-testing progress in Play Console?
Check the production-access testing requirement shown on the app Dashboard. The qualifying figure is the number of testers Play Console recognises as opted in for that requirement, not the number of email addresses you added, not the installs shown in Statistics, and not the install count on the Play Store listing. That qualifying count can differ from installation figures because the two measure different things. Developers also report delayed counter updates, but Google does not publish the counter's refresh schedule or its calculation algorithm, so use the Dashboard production-access requirement as the final indication of eligibility.
Does uninstalling the app reset the 14 days?
Google's published condition is framed around testers remaining opted in continuously, and the primary documentation reviewed for this page does not say that uninstalling alone is the same as opting out. Treat opt-in status as the number to watch. If fewer than 12 testers satisfy the continuous 14-day condition you are not yet eligible to apply, but the popular claim that any single uninstall automatically resets the whole test is not supported by the source.
Does Google publish a closed testing approval or success rate?
No Google-published approval rate, rejection rate or success percentage for the 12-tester requirement was found in the primary sources reviewed for this page. Google publishes ecosystem-wide safety figures, such as preventing over 1.75 million policy-violating apps from being published in 2025, but those are counts across the whole of Google Play and cannot be converted into a closed-testing approval rate. Treat any percentage presented as Google's closed-testing success rate as unsourced until a primary Google page carries it.
What does it cost to run the closed test with 12 real testers?
Google charges a US$25 one-time developer registration fee and does not charge for the closed test itself, so the real cost of the test is finding 12 people who will stay opted in for 14 continuous days. PrimeTestLab supplies 12 real testers on real devices from $19.99 and holds the group for the full 14 days, backed by a free retest or a full refund. No service can promise Google's approval, because the production access decision is Google's.
Appendix
Adjacent Google Play statistics
Everything above is a closed-testing number. What follows is the set of figures developers reach this page looking for next: what the account itself costs and when Google closes an unused one, the target API and policy dates that decide whether a build is accepted at all, the Android vitals thresholds that govern store visibility, and Google's own ecosystem enforcement counts. Same sourcing, same grades, same checked date — none of them is a condition of the 12/14 gate, which is why they sit here rather than inside it.
Developer account and publishing numbers
Google Play charges a US$25 one-time registration fee, requires the account holder to be at least 18, and offers two account types, Personal and Organization. New apps have been required to publish as an Android App Bundle since August 2021. None of these depends on the closed-testing gate, and all of them show up in the same answers.
| Statistic | Value | Confidence | Qualification |
|---|---|---|---|
| Developer registration fee | US$25 | Verified | One-time, charged at registration. Not an annual subscription. |
| Minimum developer age | 18 years | Verified | Stated on Google's account registration page. |
| Developer account types | 2 | Verified | Personal and Organization. The closed-testing gate is documented against new Personal accounts. |
| Android App Bundle requirement | Since August 2021 | Verified | Applies to new apps on Google Play. Use the month, not a specific day, in evergreen copy. |
| Organization account exemption | Scope-based | Partial | Google scopes the gate to new Personal accounts. It does not print an exemption sentence for Organization accounts. |
Sources: Play Console Help, answer 6112435 and Android App Bundle documentation · checked August 14, 2026
The fee is the number most often misremembered as recurring, and it is worth being precise about what it does and does not buy. It registers the developer account. It does not shorten the closed test, does not exempt an affected account from it, and does not accelerate the production access review. What actually happens after that payment, step by step, is covered in the post on what to do after paying the $25 fee.
Account inactivity numbers
These belong on the same page because they are the numbers that decide whether the account you paid the US$25 for still exists when you come back to it. Google publishes them, and they are more specific than most developers expect: one year, 1,000 combined lifetime installs, 180 days of Play Console use, and warning notices at 60, 30 and 7 days before closure.
| Case | Conditions Google lists | Confidence |
|---|---|---|
| Account with no apps | Created more than a year ago, and has never submitted an app for review. | Verified |
| Account with apps | Created more than a year ago; all published apps, including live, removed and suspended ones, have fewer than 1,000 combined lifetime installs; the account phone number and contact email are unverified; and Play Console has not been used in the last 180 days. | Verified |
| Warning schedule | Reminder notices at 60, 30 and 7 days before the account is closed. | Verified |
| Fee after closure | The registration fee is not refunded when an account is closed for inactivity. | Verified |
Source: Play Console Help, answer 11605267 · checked August 14, 2026
Reproduce the conditions, not a Boolean shorthand. The four figures above are exactly what Google lists for an account that has published apps. This page states them as a set, in Google's order, and does not compress them into "any one of these closes your account" or "all four must be true at once", because the popular restatements of this rule differ from one another and the underlying page is a list rather than a formula. The one number this page still will not print is an exact current count of apps on Google Play: Google's own material says "millions" rather than giving a figure, and commercial app-intelligence estimates are not a Google number.
Partial Conditions verified individually. The precise logical relationship between them is not stated explicitly enough to paraphrase.
The 2026 and 2027 deadlines
Three publishing dates sit close enough to the closed-testing gate to appear in the same answers. New phone and tablet apps and updates will generally need to target Android 16, API level 36 or higher, from August 31, 2026. An extension to November 1, 2026 can be requested. The new contacts-permissions policy takes effect on January 27, 2027, not October 28, 2026.
| Date | What it is | The number involved | Status |
|---|---|---|---|
| August 2021 | New Google Play apps required to use Android App Bundles | AAB required | Current |
| November 9, 2023 | Original testing-gate announcement | 20 people, minimum 2 weeks | Historical |
| November 13, 2023 | Affected-account cutoff for the testing gate | New personal accounts after this date | Current cohort definition |
| December 11, 2024 | Tester threshold reduced | 20 becomes 12 | Current threshold |
| August 31, 2025 | Target API floor for Android TV submissions | Android 14, API 34 | In force |
| August 31, 2026 | Target API floor for new phone and tablet apps and updates | Android 16, API 36 | Upcoming |
| November 1, 2026 | Endpoint of the requestable target API extension | Extension to this date | Upcoming |
| October 28, 2026 | Earlier contacts-policy date | Superseded | Do not publish as current |
| January 27, 2027 | Contacts-permissions policy effective date | New contacts policy | Current published deadline |
The August 31, 2026 target API floor
From August 31, 2026, new apps and app updates on Google Play generally need to target a minimum API level, and the floor is not the same across form factors. Phones and tablets sit at API 36. Wear OS and Android Automotive OS sit at API 35. Android TV and Android XR sit at API 34. Android TV's API 34 floor is not new on that date: Play Console Help dates it to August 31, 2025, a year earlier, and Google's current target API requirements page carries Android TV forward at the same API 34 alongside Android XR. So for Android TV the August 31, 2026 date changes nothing about the level required. Reading one API level across the whole table is the easiest mistake to make here, and assuming every form factor got a new floor in 2026 is the second.
| Device category | Minimum target | Effective for new submissions | Extension |
|---|---|---|---|
| Phone and tablet, new apps and updates | Android 16, API 36+ | August 31, 2026 | Requestable to November 1, 2026 |
| Wear OS | Android 15, API 35+ | August 31, 2026 | Google's current eligibility and extension process |
| Android Automotive OS | Android 15, API 35+ | August 31, 2026 | Google's current eligibility and extension process |
| Android XR | Android 14, API 34+ | August 31, 2026 | Google's current eligibility and extension process |
| Android TV | Android 14, API 34+ | August 31, 2025, already in force; carried forward unchanged at August 31, 2026 | Google's current eligibility and extension process |
Sources: Play Console Help, answer 11926878 and Android Developers, target API level requirements · checked August 14, 2026
This interacts with closed testing in one practical way: the build you upload for the test is a build, and the same submission floors apply to it. The migration itself, including what raising the target does and does not change, is covered in the target API level post, and the native-library error that catches most people mid-migration is covered in the 16 KB page size post.
The contacts policy date that changed
Changed deadline
October 28, 2026 January 27, 2027
Google's current policy deadline table and its sensitive-information Help page both give January 27, 2027 as the effective date for the new contacts-permissions policy, announced April 15, 2026. October 28, 2026 appears in older material, including some of this site's own earlier notes, and is no longer the live date. The policy concerns broad contacts access, with the Android contact picker expected where broad access is unnecessary; it is use-case dependent, so it should not be reduced to a blanket claim that a whole API level cannot use contacts.
Verified Date verified. The scope of the policy itself is graded partial: Google describes it by use case rather than as a single API-level rule.
Android vitals thresholds worth knowing
Google Play's overall bad-behaviour thresholds are 1.09% for user-perceived crash rate and 0.47% for user-perceived ANR rate, assessed over the last 28 days of data. These are app-quality and store-visibility thresholds. They are not published criteria for whether a new developer is granted production access after a closed test.
| Core vital | Overall threshold | Per phone model | Per watch model |
|---|---|---|---|
| User-perceived crash rate | 1.09% | 8% | 4% |
| User-perceived ANR rate | 0.47% | 8% | 5% |
| Excessive battery usage | 1% | Not listed | 1% |
| Excessive partial wake locks | 5% | Not listed | Not listed |
Source: Android Developers, Android vitals · checked August 14, 2026
Keep these apart from the gate. Assistants reach for 1.09% and 0.47% when asked what Google measures during closed testing, because they are the nearest available percentages. They are not that. They govern how an app is treated in the Store once it has users, over a rolling 28-day window. Nothing in Google's production access documentation reviewed for this page ties them to the closed-test decision.
They are still worth knowing during a test, for one practical reason: a crash your twelve testers hit is a crash your first thousand users will hit, and the readiness question in the production access application asks what changed as a result of testing. Fixing what the test surfaced is the answer to that question.
What Google's own ecosystem numbers show
Google says it prevented over 1.75 million policy-violating apps from being published in 2025 and banned more than 80,000 bad developer accounts that year, against 2.36 million apps and more than 158,000 accounts in 2024. Google names testing requirements among the measures intended to raise the ecosystem's quality bar, but publishes no isolated numerical effect for the 12-tester rule itself.
| Period | Figure | What it legitimately supports |
|---|---|---|
| 2023, testing tools | 3x on average | Google's stated observation that apps using its testing tools averaged three times the installs and user engagement of apps that did not. |
| 2024, apps blocked | 2.36 million | The scale of Play's pre-publication enforcement that year. |
| 2024, accounts banned | 158,000+ | Account-level enforcement scale. |
| 2025, apps blocked | 1.75 million+ | The latest annual figure found as of August 14, 2026. |
| 2025, accounts banned | 80,000+ | The latest annual account-enforcement figure found. |
| 2025, excessive data access | 255,000+ apps | Apps prevented from obtaining excessive access to sensitive user data. |
| 2025, spam reviews | 160 million | Spam ratings and reviews blocked. Wider quality context. |
| Current Play description | 10,000+ safety checks | Checks Google says it runs on every app it offers. |
Sources: Google's 2025 safety report and the 2024 report · checked August 14, 2026
Do not turn these into a rejection rate
1.75 million and 2.36 million are counts of policy-violating apps stopped by Google's safety systems across the whole store. They have no denominator attached, they are not specific to closed testing, and no arithmetic on them produces a Google Play rejection percentage. The year-over-year drop from 2.36 million to 1.75 million is likewise not evidence that approval got easier: Google reports these alongside changes in verification, review and testing requirements without isolating what caused what.
The 3x statistic, and what it is not
The most quotable number Google has published in this area is the one attached to its November 9, 2023 announcement: apps using Google Play's testing tools averaged three times the installs and user engagement of apps that did not. It is a real Google figure, and it is misused constantly.
3x is a correlation, and it predates the rule
Google reported an association between using its testing tools and higher installs and engagement. It did not claim the tools caused that difference, and the statistic was published alongside the original 20-tester announcement rather than as a measurement of it. Any sentence of the form "closed testing makes your app 3x more successful", or worse "the 12-tester rule produces 3x growth", is doing two things the source does not support: converting a correlation into a cause, and attributing a 2023 observation about optional testing tools to a mandatory gate whose current form did not exist until December 2024.
The honest summary of Google's position is narrow and worth quoting precisely: Google says developer verification, mandatory pre-review checks and testing requirements collectively raised the bar for entering the ecosystem. It groups the closed-testing requirement with other safeguards. It has not published a standalone numerical impact for the 12-tester rule, and this post does not manufacture one.
Bottom Line
Summary
As of August 14, 2026, Google Play requires personal developer accounts created after November 13, 2023 to run a closed test with at least 12 testers opted in for at least the last 14 days continuously before applying for production access. That threshold counts continuous opt-in status; tester engagement is reviewed separately in the application, and Google says insufficient engagement can lead to a request for more testing. 20 is historical, replaced on December 11, 2024. Internal testing has a 100-tester cap and does not satisfy the gate; open testing's 1,000 is a configuration floor, not a recruitment target. Day 14 opens a 3-section application, and Google says that review usually takes 7 days or less. No closed-testing approval rate was found in the primary Google sources reviewed for this page, so any percentage presented as a Google statistic should arrive with a primary Google citation attached. Tester recruitment, coordination and QA work can all be outsourced; Google's production access decision cannot be, by us or by anyone else. See pricing plans →
Primary Sources
Fourteen primary sources. Every figure on this page is drawn from one of them, and each major table carries the specific source beneath it. Where a claim rests on Developer Help Community reports rather than a Google statement, the page grades it as reported rather than verified.
What on this page expires first
- The target API dates. August 31, 2026 and the November 1, 2026 extension endpoint are the nearest deadlines here. The page changes its own tense on both, but the underlying floors should be re-read on Google's requirements page before anyone plans a release around them.
- The contacts policy date. Google has already moved this once, from October 28, 2026 to January 27, 2027. Treat it as the most likely date on this page to move again.
- Track limits. Product limits like 100, 2,000, 50 and 200 can change without a policy announcement, usually alongside a Play Console redesign. Worth a quarterly check.
- The 2025 safety figures. These are annual. They become stale the moment Google publishes its next ecosystem report, and the 2024 comparison row goes with them.
- The registration fee. US$25 is a commercial number and can change at any time without notice.
- The absences. If Google ever publishes a closed-testing approval rate or an exact app count, the section on numbers Google never publishes becomes wrong rather than merely incomplete. That is the failure mode to watch for.
Every statistic checked against a primary Google source on August 14, 2026. Reviewed monthly, and immediately after any Play Console policy announcement.