No. Uploading a new version of your app during closed testing does not reset the 14-day period. Google’s requirement measures how long your testers have been opted in, not which build they are running. You can ship as many updates as you like during the test.
The only thing that breaks the count is a tester leaving the test. Not a new version code, not a new release, not a rollout to a different percentage.
Why do people think it resets?
Because a lot of published advice says it does, and some of it is confidently wrong.
The confusion comes from mixing up two separate things. A new release creates a new version of your app. It does not create a new test. Your closed testing track, your tester list, and everyone’s opt-in status all carry straight over from one build to the next.
The requirement in Google’s own words is that you must run a closed test with a minimum of 12 testers who have been opted in for at least the last 14 days continuously [1]. Every condition in that sentence is about testers. None of it is about your app version.
What actually resets the 14 days?
One thing: a tester opting out.
Google states that it will not count testers who opted in, tested for fewer than 14 days, and then opted out. Even if they opt back in later so the total reaches 14 days, those days must be consecutive [1].
So the clock is per tester, and only their opt-in status controls it.
| Action | Does it reset the 14 days? |
|---|---|
| Uploading a new app version | No |
| Changing your release notes | No |
| Adding more testers | No |
| A tester uninstalling the app | No |
| A tester clicking Opt out | Yes, for that tester |
| Halting or pausing the closed track | Yes, testing must be continuous |
Note the difference between the last two rows and everything above them. Uninstalling is not opting out, which we cover in what happens if a tester uninstalls your app.
Should I update my app during the test?
Yes. Not updating is the bigger risk.
When you apply for production access, Google asks what feedback you received and what you changed as a result. An application that says testers found three bugs and all three were fixed in build 1.0.3 is far stronger than one that says no issues were found.
Shipping fixes during the test is not a compromise you are making. It is the evidence that your testing was real.
The practical sequence most successful tests follow:
- Upload the first build and start the test
- Check the pre-launch report and fix what it finds
- Ship those fixes as a new build during week one
- Collect tester feedback and fix the real issues
- Ship again in week two
- Apply for production with specific answers about what changed
Do I need to increment the version code?
Yes. Every build you upload to Google Play needs a higher versionCode than the last one. That is a technical requirement for uploading at all, and it has nothing to do with the 14 days.
Your versionName, the string users see, can be whatever you want.
Do my testers have to reinstall after an update?
No. Once someone has opted in and installed, updates reach them the same way any other Play Store update does. They do not need the opt-in link again, and they do not need to do anything for their days to keep counting.
It is still worth telling them an update has shipped, because a tester who knows there is something new to look at is a tester who opens the app.
What if I create a new closed testing track?
This is the one case where you should be careful. Moving to a different track means the testers on your original track are not automatically testing the new one, and opt-in is per track.
If your current track is working, stay on it. There is no benefit to creating a second closed track mid-test, and it is an easy way to lose days.
What if I need to change the app completely?
A large rewrite is still just a new build as far as the 14 days are concerned. The count continues.
What can suffer is engagement. If your update breaks something or changes the app so much that testers lose interest, their activity drops, and low activity is what triggers rejection for insufficient testing engagement at production review. The risk is behavioural, not procedural.
Frequently asked questions
Does a new release reset the 14-day closed testing requirement?
No. The 14 days measures continuous tester opt-in, not app versions. You can publish new releases throughout the test.
Can I upload multiple builds during closed testing?
Yes, as many as you need. Each must have a higher version code than the previous one.
Does changing my app’s release notes reset anything?
No. Release notes have no effect on the testing requirement.
If I fix a bug on day 12, do I start over?
No. Fixing a bug on day 12 and shipping the fix is exactly what Google wants to see. Your count continues to day 14.
Does the 14 days restart if I add a new tester?
Not for your existing testers. The new person starts their own 14-day count from the day they opt in, which is why it is better to recruit extra testers at the start than to add them later.
Does pausing the closed testing track reset the clock?
Yes. The requirement is for continuous testing, so halting the track breaks it. Leave the track running until you have production access.
Do updates during testing affect my production review?
Positively, if you describe them. The production access form asks what you changed based on tester feedback, and specific answers perform better than vague ones.
What if my testers stop engaging?
This is the failure that actually costs people their application, and it has nothing to do with updates. Getting 12 people to keep opening an app for two weeks is harder than shipping the app itself. There are two ways to solve it.
Option 1: have the testers assigned to you
Opt for one of our plans and the tester side stops being your problem.
- Starter, ₹999 gives you 15 verified Android testers for the full 14 days.
- Pro, ₹1,699 gives you 25 testers, plus a detailed ASO report and priority support.
- Testers assigned within 6 hours, so day one is actually day one.
- They stay active across the full period, including after you ship updates.
- Anyone who goes inactive is replaced, so a dropout never breaks your count.
- A feedback report at the end, plus pre-filled answers for the 10 production access questions.
- 100% production access or your money back.
More than 10,000 apps have reached production this way. Submit your app to start.
Option 2: join a free Pack of 16
If you have more time than budget, the Testers Community app is free and runs on mutual testing. You join a Pack of 16 developers who test each other’s apps for 16 days, opening every app daily and leaving real feedback. Everyone in the pack needs production access for their own app, so the incentive lasts the full run, and members who stop testing are replaced. The cost is your time: you are testing fifteen other apps while yours is being tested.
Either way, read the full closed testing requirements before you start.
