Release Management & Rollouts on Google Play: A Developer's Guide

A release is the vehicle that carries your app from a built bundle to live users on Google Play. Release management is the practice of controlling that journey — creating the release, choosing where it goes, rolling it out gradually, catching problems before they scale, and fixing things when they go wrong. This guide is the operational map for that journey.

Where releases live: the four tracks

Releases are created the same way on every track: attach an Android App Bundle, add release notes, and roll out. The difference is who can see it and what gates stand between you and live users.

Creating a release

1. 1

   Open the track

   Go to Test and release > Production for a live release, or Testing > Internal / Closed / Open testing for a test track. Navigate to the Releases tab.

1. 1

   Clear outstanding releases first

   Create new release stays disabled while you have outstanding releases. Roll any staged release to 100%, or discard unpublished drafts on the Publishing overview page before starting a new release.

1. 1

   Attach your app bundle

   Upload an .aab signed with your current upload key. The release name auto-fills from the version name — override it with a meaningful identifier like the build version or an internal codename.

1. 1

   Add release notes

   Enter notes per supported language (up to 500 characters). Notes inform users what changed — not a marketing billboard.

1. 1

   Save, then review and roll out

   Save as draft first, then click Next to reach the Preview and confirm screen. Resolve any Errors — warnings can still publish, but Google recommends fixing them first.

Version codes drive everything

Google Play selects the build each user receives by version code: the highest code compatible with the device, among the tracks that user is eligible for. Production beats testing tracks — so if production carries a higher code than your test release, testers get the production build.

Staged rollouts

For app updates — not first releases — you can roll out to a percentage of users and increase over time. Staged rollouts let you catch issues at 1% before they reach everyone.

1. 1

   Choose an initial percentage

   Pick a small share — 1% or 5% — to limit blast radius. This is the starting point you monitor before deciding to expand.

1. 1

   Monitor the signals before increasing

   Watch the Release overview page for crashes, ANRs, and uninstalls. Check Play Console's Testing feedback and the pre-launch report. Only increase rollout when the metrics are clean.

1. 1

   Increase the rollout

   On the Releases tab, select Manage rollout > Increase rollout, choose the next percentage, and confirm. Google recommends raising in increments — 1%, 5%, 10%, 25%, 50%, 100%.

When to halt a rollout

If a critical crash, ANR spike, or data-loss bug surfaces during a staged rollout, you can stop the bleeding before the release reaches everyone.

1. 1

   Halt a staged rollout

   Go to the Production page, select the Releases tab, and under the release choose Manage rollout > Halt rollout. No additional users receive the affected version; users who already got it stay on it until a fix lands.

Halting a fully rolled-out release

If a release has already reached 100% and you discover a critical issue, Google Play offers a separate 'halt fully rolled-out release' feature. When you halt a complete rollout, the previous live version of your app automatically becomes available to new and eligible users.

Decision framework: what to do when a problem surfaces

The right response depends on how far the release has gone and how severe the issue is. The framework below is an AppsTestLab operational recommendation — not Google's official algorithm.

Shipping a fixed release to replace a bad one

When a halt stops the bad build from spreading, the fix is a new release with a higher version code. There's no shortcut — Play does not auto-downgrade, so the corrected version must reach users through a normal rollout.

1. 1

   Build the fix

   Increment the version code, fix the root cause, and attach the new bundle to a release on the same track.

1. 1

   Roll out the fix

   Start the fix at a low percentage if users are mid-update, then expand once crash and ANR signals confirm the fix works.

1. 1

   Track the transition

   The Rollout history on the Release details page shows when releases were halted, resumed, or served new percentages.

Managed publishing: holding changes for a planned moment

Standard publishing sends reviewed changes live immediately after approval. Managed Publishing lets you hold approved changes until you explicitly push them — useful when a release should go out at a specific time. Either way, changes first pass through the Publishing overview page.

After launch: the bridge to monitoring

Once your release is live — whether fully rolled out or at a monitored percentage — the Dashboard fills in with performance data: installs, uninstalls, ratings, crashes, and key insights over time.

Recommended release-management services from AppsTestLab

If you'd rather not manage this pipeline by hand, AppsTestLab handles release management, staged rollout monitoring, and rollback planning as part of ongoing Android app support.