Based on how Google words the rule, a normal app update shouldn't reset the 14 days. The requirement is about testers being opted in continuously, not about a single version of your app staying unchanged. What can break the count is anything that takes testers out of the test, such as removing their list or country from the track.
Here is how the count works, and which changes are safe.
What the 14 days are actually measured on
Google's help page for new personal developer accounts says you "must run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days." It adds that at least 12 testers must be opted in "when you apply for production access, and they must have been opted in continuously for the preceding 14 days."
Notice what the rule is attached to:
- the testers (at least 12 of them)
- their opt-in (continuous, with no gaps)
- the moment you apply (looking back 14 days)
There is no mention of a specific build or version. Google's official text doesn't explicitly say "updates don't reset the counter", so treat this as a careful reading rather than a quote. But it fits Google's own advice: it encourages you to keep running the closed test "while resolving user-reported issues and bugs", and the production application asks what you changed after testing. A rule that restarted every time you shipped a fix would contradict that advice.
If you're not sure what "opted in" means in practice, read what counts as an opted-in tester.
Changes that are safe for the count
As long as the same testers keep access to the same track, these should not affect the opt-in count:
- uploading a new app bundle with a higher version code
- editing release notes
- updating the store listing text or screenshots
- answering App content declarations
- a release going through review
Your existing testers stay on the tester list during review, and they keep the version they already have until the new one is approved. For the mechanics of shipping a build mid-test, see updating your app during a closed test.
Changes that can break the count
The things that hurt are changes that remove testers' access or cause them to leave. Google is clear that "testers who opt in, test for fewer than 14 days, and then opt out do not count", and that if a tester opts out and back in, "the 14 days must be consecutive to count."
Be careful with:
Removing a tester list or Google Group
If you delete the email list or Google Group your testers belong to from the Testers tab, they are no longer part of the test. Re-adding it later is unlikely to recover the days they had, because Google requires the 14 days to be consecutive.
Moving testers to a new track
Testers are attached to a track. If you set up a fresh closed track and point people at it, their earlier days on the old track don't carry over to the new one in any documented way. Keep everyone on one track for the whole test.
Unselecting a country
The countries for a testing track can be edited under Testing > Closed testing > Manage track > Countries/regions. If your testers are in a country you then remove, they likely lose access to the closed test. Our testers are in Indonesia, so Indonesia has to stay selected for as long as the test runs. More background is in countries and regions for a closed testing track.
Testers leaving on their own
A tester who opts out, uninstalls and walks away, or stops using your app is a risk to your count and to your engagement. Google lists "fewer than 12 opted-in testers" and "insufficient tester engagement" as reasons it may ask for more testing. See what happens if a tester drops out.
A broken update is a different problem
Even if an update doesn't touch the counter, a bad one can still hurt you. A build that crashes on launch may push testers to uninstall, and an app that stops working for days is hard to describe as "tested" in your application. Keeping the app installed and using it regularly is strongly advised for testers, and you can't expect that if the app doesn't open.
Before you send an update:
- Install it yourself on at least one real device.
- Check the pre-launch report Play Console generates when you upload a bundle.
- Ship fixes in one meaningful release rather than many rushed ones.
How to check your count is still on track
Whatever progress indicators your Play Console dashboard shows, it's worth keeping your own record too. In practice you track two things:
- How many testers are opted in right now. See how to check how many testers have opted in.
- When the 12th tester opted in. Count 14 full days from the date you had 12 or more testers continuously opted in. Write that date down when it happens.
Because the rule looks at "the preceding 14 days" at the moment you apply, a cushion of an extra day or two before applying is a sensible habit. Our apply-production guide recommends applying on day 15.
Key takeaways
- The 14 days are tied to testers staying opted in, not to one version of your app.
- Normal updates, listing edits and reviews shouldn't restart the count.
- Removing tester lists, switching tracks or unselecting your testers' country can break it.
- Testers who opt out and rejoin start a new consecutive run.
- Google decides whether the testing was enough, so keep the app stable and the testers engaged.
If you'd rather not manage tester retention yourself, GoPlayTester provides 12+ real testers who stay opted in for 14 continuous days, starting from 8 PM WIB in queue order. The guide shows the setup and you can order here.
