Shipping a New Build During a Google Play Closed Test: Version Codes, Review Time and What to Tell Testers

Disclosure: 12Testers14Day publishes this article and sells Google Play closed-testing help.

A closed test is meant to find problems, so it is common to ship at least one fix before the test ends. That's normal, and Google encourages it. The risky part is the mechanics: a version code that won't upload, a review that takes longer than you planned, or testers who never get the fixed build. This guide covers what Google documents about each one, and what it doesn't.

Does Google want you to update during the test?

Yes. Google's testing requirements article says: "Continue running closed tests while resolving user-reported issues and bugs. Updating your app in closed testing before releasing to production helps minimize low ratings and negative reviews."

It also matters later. If your personal developer account was created after November 13, 2023, you need a closed test with at least 12 testers opted in continuously for at least 14 days before you can apply for production access. The application then asks you to "Describe any changes made to your app or game based on what you learned from your closed test." A fix you shipped during the test, and the feedback that led to it, is exactly what that question is looking for. (Our guide to applying for production access covers the full form.)

Does a new build restart the 14 days?

Google's requirement is written in terms of testers, not builds: at least 12 testers "opted in continuously for at least 14 days." The same article explains that testers who opt out before 14 days don't count, and that a tester who opts out and back in needs 14 consecutive days.

We couldn't find any Google statement that publishing a new build to the closed track restarts that count, and none that says it can't. So don't plan around either assumption. What clearly does affect the count is people leaving. A broken update that makes testers give up and opt out costs you more than the bug it was meant to fix. See how the 14-day window works for how to track each tester's continuous days.

Step 1: Raise the version code

Every upload needs a new, higher versionCode. Android Developers' versioning guide says you can use any positive integer, "However, make sure that each successive release of your app uses a greater value." It also says "You can't upload an APK to the Play Store with a versionCode you have already used for a previous version," and that the greatest value Google Play allows is 2100000000.

A few practical points:

• versionCode is the internal number Play uses to decide which build is newer. versionName (for example "1.0.3") is what users see. Changing only versionName isn't enough.
• If your CI sets the version code from a build number or timestamp, check it can't go backwards, for example after you switch branches or rebuild an old commit.
• Name the release in Play Console with something you'll recognise later, such as the version name plus "fix login crash". Google says the release name is only shown in Play Console, not to users.

Step 2: Publish to the same closed track your testers joined

Google's test setup article explains which build a device gets. Devices receive the version that "Contains the highest version code compatible with the device" and "Is published to a track the user is eligible to receive." To be eligible for a test track, a user has to be on that track's tester list and actively opted in.

That means the fix has to go to the track your testers are actually on. In Play Console, go to Test and release > Testing > Closed testing, click Manage track for that track, then Create new release. Google's release guide notes that you can't create a new release while you have outstanding releases, so finish or discard any earlier draft first.

Two things to avoid:

• Don't move closed testers to internal testing to get them a fix faster. Google says: "Users who opt into internal testing aren't eligible for open and closed testing, even if included as testers on those tracks. These users receive only the version code published on the Internal testing track." Internal testing is still useful for checking a fix with your own team first; just keep your closed testers out of it. Our internal vs closed testing guide explains the difference.
• Don't start a new closed track for the fix. Your testers opted in to a specific track. A build on a different track doesn't reach them unless they're on that track's list and opt in again.

Step 3: Plan for review and delivery time

A closed-testing update isn't instant. Google's publishing article says app changes need to be processed before they're published, and "Processing can take a few hours or up to seven days (or longer in exceptional cases)." The test setup article adds that after a test is first published, "Additional changes can also take several hours to become available."

Google also warns that the review turnaround "is counted from the last submitted change to an app," so submitting another change while one is in review can push your app to the back of the queue. In practice:

• Batch fixes into one release rather than sending several small ones in a day.
• Avoid sending store listing or app content edits at the same moment as an urgent fix, unless they need to go together.
• If your 14 days are nearly up, decide whether you want testers to use the fix before you apply, and allow for review time. A build that's still in review on the day you apply isn't one your testers have used.

Step 4: Tell testers what changed

Google says testers can't leave public reviews on test versions, so your own feedback channel does the work here. When the update goes live:

1. Write short release notes. Play Console allows up to 500 characters per language. Google says not to use release notes "for promotional purposes or to solicit user actions," so keep them to what changed.
2. Message testers through your feedback channel with the version name, what was fixed, and what you'd like them to check again. For example: "Version 1.0.3 is rolling out to the test now. It fixes the crash when saving a photo. Please update from the Play Store page and try saving a photo again."
3. Ask them to update, not uninstall and reinstall. Google's requirement counts testers who stay opted in, and one simple instruction (update from the app's Play Store page) makes it less likely that anyone leaves the test by mistake.
4. Ask them to confirm the version. If your app shows its version name on a settings or about screen, ask testers to check it so you know their feedback is about the new build.

A quick checklist for a mid-test update

Check	Why it matters
versionCode is higher than every earlier upload	Play rejects reused codes, and devices get the highest eligible code
Release is on the same closed track testers joined	Testers only get builds from tracks they're eligible for
No closed testers opted in to internal testing	Internal testers can't receive closed or open builds
Fix was checked with your own team first	A broken update can drive testers to opt out
Changes batched into one submission	Review time counts from the last submitted change
Release notes and a tester message are ready	Testers know what to retest and how to update
Fix and the feedback behind it are written down	You'll describe them in the production access form

Common questions

Can I upload a fix in the last few days of the test?
Google doesn't forbid it. Just remember the update may take hours or days to reach testers, so decide whether you want testers to try the fix before you apply.

What happens to testers who don't update?
They keep the version they have until their device updates. Google's documented rule is about which version a device is eligible to receive, so ask testers to update if you want feedback on the new build.

Should I pause the track while I fix a bug?
Pausing ends the test. Google's test setup article says that after a test ends, testers don't receive updates, though the app stays installed. Only do this if you mean to stop testing.

Does the 14-day count depend on how active testers are?
The requirement is about continuous opt-in, but Google also asks about tester engagement in the production access form and may ask for more testing if engagement was too low. See what useful tester activity looks like.

If you'd rather not recruit and coordinate testers yourself

12Testers14Day provides Google Play closed-testing help: about 14 testers for about 16 days, as a buffer around Google's 12-tester, 14-day requirement. Packages are one-time: $15 Basic for one app or $29 Premium for two, per the pricing page on October 19, 2026. During a run you share changes in your workspace when you publish a new build (how a run works). Note that the delivery and refund policy excludes broken builds and unusable installs, so check each update before you publish it. Google decides production access.

---

Official references: App testing requirements for new personal developer accounts · Set up an open, closed, or internal test · Prepare and roll out a release · Control when app changes are reviewed and published · Version your app