PeerPlay
A surprising number of developers freeze their app for two weeks once a closed test starts. They find a bug on day 3 and sit on the fix until day 15, because they are afraid a new build will restart Google Play's 14-day clock.
That fear costs them the most useful part of the test. Here is what an update actually changes, what can really break your count, and the small version code details that trip people up.
What the 14 days actually count
For newer personal developer accounts, Google asks for a closed test with at least 12 testers who stay opted in for 14 days in a row before you can apply for production. The requirement is about your testers, not about a single frozen build.
The production application asks what you learned from testing and what you changed. Shipping fixes during the test is exactly what that question expects. As far as Google documents, uploading a new build to the same closed track does not restart the 14 days by itself. Google does not publish every detail of how it counts, so watch the tester numbers in Play Console after each release rather than assuming.
What can really break your count
The update is rarely the problem. What happens around it can be.
A build that crashes on launch is the big one. Testers who cannot open the app tend to uninstall it or stop caring, and if enough of them opt out, you drop below 12. Test every build yourself on a real device before it goes to the track.
Moving to a different track is the second. If you start a new closed track, or switch testing to another one, testers on the old track are not automatically on the new one. Keep the same track and the same tester list for the whole 14 days.
Editing the tester list is the third. Removing an email address or a Google Group from the track removes those people from the test. Double check before you save.
Version codes: the details that trip people up
Every upload needs a higher version code than the last one on that track. Play Console rejects a bundle that reuses or lowers it. In Flutter that is the number after the plus sign in pubspec.yaml, in a native project it is versionCode in your Gradle file.
Bump the version name too, so testers and you can tell builds apart in feedback. "It crashes on 1.0.3" is far more useful than "it crashes".
Expect a review delay. Updates to a closed track can go through Google's review before testers see them. Ship early in the day and do not plan a fix for the last hours of day 14.
Testers do not always update right away. Play Store auto-update may take a while, so tell testers in your feedback channel that a new build is out and what changed.
What updating mid-test looked like in a real campaign
PeerPlay's first paid campaign, for a cycle tracking app called Nada, ran from September 16 to October 6, 2026. Testers sent 14 feedback items and the developer marked 8 as solved during the test, from a schedule switch that did nothing to cycle tracking that stopped around the 19th cycle.
At least 12 testers were active every day from September 17 to October 1, and Google granted Nada production access. Fixing bugs while the test was running did not stand in the way, and it gave the developer real changes to describe in the production application.
A simple update routine for the 14 days
Collect feedback for a few days, fix the most important issues, bump the version code and name, test the build on your own phone, upload it to the same closed track, and post a short changelog where your testers will see it. Then check Play Console the next day to confirm your tester count did not move. One or two updates like this during a test is plenty.
FAQ
Does uploading a new build reset Google Play's 14-day closed testing period?
As far as Google documents, no. The requirement is 12 testers opted in for 14 days in a row on your closed test. Keep the same track and tester list, and check your tester count after each release.
Why does Play Console reject my new bundle?
Most often because the version code is not higher than the last upload. Each new build on a track needs a higher version code.
Can I switch to a new closed testing track during the 14 days?
Avoid it. Testers on the old track are not automatically added to a new one, so your opted-in count can drop.
How often should I update during a closed test?
One or two updates that fix real tester feedback are usually enough, and they give you concrete changes to describe when you apply for production.