Google Play testing tracks and releases, without the confusion

Testing tracks and releases are two different things. A track is the audience. A release is the build you give that audience.

Most confusion comes from mixing them up.

The track is the audience

• Internal: a small, chosen group.
• Closed: a specific group you invite.
• Open: anyone who opts in within the limits.
• Production: the public.

Each track can have its own release. You can run more than one track at the same time.

The release is the build

A release contains:

• an Android App Bundle;
• a version code and version name;
• release notes;
• a rollout status;
• country and device targeting.

The version code must increase with every upload. You cannot reuse a version code, even on a different track.

A typical sequence

1. Upload build 1 to internal testing.
2. Test it with your team.
3. Promote or upload build 2 to closed testing.
4. Run the closed test for the required period.
5. Apply for production access.
6. Create a production release with build 3.
7. Roll out gradually.

You do not have to use every track. You do have to keep version codes increasing.

Promoting vs uploading

Play Console lets you promote a release from one track to another. This is convenient, but check the version code and release notes. A promoted build is the same binary; if you need changes, upload a new build with a higher version code.

Staged rollout

A staged rollout releases the app to a percentage of users. It is useful for catching crashes and device-specific issues before everyone gets the update.

Start with a small percentage, monitor Android vitals and reviews, then increase. You can halt a rollout if something goes wrong.

Common mistakes

• Uploading a build with a lower version code.
• Assuming testers automatically move to a new track.
• Forgetting to roll out a release after creating it.
• Sharing the production link instead of the testing opt-in link.
• Changing the tester list after the test starts without checking the effect.
• Running an internal test and assuming it counts for the closed-test requirement.

A note on tester lists

Each track has its own tester setup. Moving from internal to closed does not automatically add internal testers to the closed track. You need to add them and share the new opt-in link.

The short version

• Tracks are audiences; releases are builds.
• Version codes must increase.
• Promoting is not the same as uploading a new build.
• Staged rollouts reduce risk.
• Check tester lists when you change tracks.

Next: internal vs closed vs open testing or how to add testers.