Updating your app during a closed test: version codes and new releases

Yes, you can and usually should ship updates while your closed test is running. Increase your app's version code, upload the new app bundle as a new release on the same closed testing track, and send the change for review. Once it's approved, your testers get it as a normal update from Google Play.

The rest of this article walks through each step and the mistakes that most often block a mid-test update.

Why update during the test at all

Google's own best-practice advice for the testing period is to "continue running closed tests while resolving user-reported issues and bugs", and it notes that updating your app in closed testing before production "helps minimize low ratings and negative reviews."

There's also a practical reason. When you later apply for production access, one part of the form asks what you changed based on the closed test. Shipping updates isn't an official requirement, but a test where you fixed real problems is far easier to describe honestly than one where nothing happened.

Version code vs version name

Every Android build has two version values, and they do different jobs:

• Version code (versionCode): a whole number that Google Play uses to tell builds apart. Each bundle you upload must have a version code that hasn't been used before for that app, and it should always go up. Play Console refuses an upload that reuses a version code.
• Version name (versionName): the text users see, such as 1.0.3. Play doesn't use it to order builds, so it can be anything you like.

In a Gradle project both live in the defaultConfig block of your app module's build file. A typical bump looks like this:

defaultConfig {
    versionCode = 7      // was 6
    versionName = "1.0.3" // was 1.0.2
}

A simple habit that avoids trouble: increase the version code by one for every build you upload anywhere, including internal testing. Version codes are per app, not per track, so a number you burned on an internal build can't be reused on the closed track.

Step by step: shipping an update to your closed track

1. Bump the version code (and the version name if you want) and build a new signed Android App Bundle (.aab). Sign it with the same upload key you used before. If you're unsure how keys work, read Play App Signing explained.
2. In Play Console, open Testing > Closed testing and choose the track your testers are already on (for many apps this is the default closed track). Click Manage track.
3. Click Create new release and upload the new bundle. Our article on uploading your first app bundle covers this screen in more detail.
4. Write short release notes. Testers see them, and they're a good place to say what changed and what you want people to try.
5. Save, review the release and fix any errors or warnings Play Console shows.
6. Go to Publishing overview and click Send for review. Until you do this, the release sits under "Changes not yet sent for review" and nobody receives it.
7. Wait for the review. Google says reviews of testing releases can take "a few hours or up to seven days (or longer in exceptional cases)."

When the release is approved and live, testers who have the app installed get the update through Google Play like any other app update.

Mistakes that block or confuse updates

Uploading to a different track

Your testers are attached to a specific track through its tester list. If you create a new closed track for the update, the people on your original track won't get it. Keep updates on the track your testers already joined.

Changing the tester list or countries while updating

When you edit a release, you're in the same Manage track area where the Testers and Countries/regions tabs live. Don't remove an email list or Google Group, and don't unselect a country your testers are in. Testers who lose access mid-test can break the continuous 14 days the requirement depends on. If your testers are based in Indonesia (ours are), Indonesia must stay selected.

Forgetting to send the change

This is the same mistake that stops tester invites from working. It's covered in why your tester invite isn't approved, and it applies to every release, not just the first one.

Using managed publishing without noticing

If managed publishing is turned on, an approved update doesn't go live until you publish it yourself. That's useful when you want control over timing, but easy to forget. See managed publishing explained if your update was approved and testers still don't see it.

Expecting the update to appear instantly

After approval, Play distributes the update the normal way. Some testers will see it quickly, others only when their Play Store checks for updates. Mention in your tester channel that a new version is out and ask people to update.

Should you ship many small updates or a few larger ones?

Every release you send goes through review, and each review takes time you can't predict exactly. For most apps, one or two meaningful updates during the 14 days work well: one after the first few days of feedback, and possibly one more near the end. Group several fixes into one build rather than sending a new bundle for every typo.

Before each upload, check the pre-launch report from your previous build. Google generates it automatically when you upload an app bundle, and it often catches crashes before your testers do.

If a release review seems to drag on, the article on releases stuck "In review" lists what to check.

Quick checklist

• Version code higher than any build you've uploaded before
• Signed with your registered upload key
• Uploaded to the same closed track your testers joined
• Tester lists and countries unchanged
• Release notes written for testers
• Change sent for review in Publishing overview
• Managed publishing status checked after approval

If you're still gathering your 12 testers, GoPlayTester can run the 14-day test with real testers on real devices while you focus on the updates. The setup guide shows the Play Console steps, and you can order here.