Skip to content
7 min read Guides Android

Staged Rollouts on Google Play: Percentages, Halts and Countries

Every Android team eventually ships an update that works on every phone in the office and crashes on a model nobody owns. A staged rollout limits the damage: the update goes to a slice of your users, you watch what happens, and you widen the slice when you are confident. This guide covers how staged rollouts work on Google Play as of 26 September 2026, how to halt one, how country targeting behaves, and how it differs from Apple's approach.

If you also ship on iOS, see phased release on the App Store.

The short version

  • Staged rollouts are for updates. A brand-new app can't use one.
  • You choose the percentage, and it stays there until you raise it. Play doesn't follow a schedule for you.
  • Halting stops new users getting the update. People who already have it keep it.
  • On production you can start with chosen countries, but you can't remove a country once the rollout has started.
  • Watch Android vitals, reviews and in-app feedback by app version while the share is small.

How a staged rollout works

Google's help page Release app updates with staged rollouts describes the rules. As of 26 September 2026:

  • You can use a staged rollout on production and on testing tracks, for app updates. It isn't available when you publish a new app.
  • New and existing users are eligible, chosen at random for each release.
  • If you halt and then resume, the same set of users is affected.
  • If you start a new staged release before the previous one finished, the new release uses the same group of users, depending on the percentage.
  • The update becomes available to that percentage, but it can take time for the whole group to receive it.
  • Users aren't told that they received a version through a staged rollout.

Choosing and raising the percentage

You set the percentage when you roll out the release, in the Staged rollout section of the release page. Google is explicit that the percentage won't rise by itself. To widen it, go to the Production page (or the Open testing or Closed testing page), open the Releases tab, choose Manage rollout and then Update rollout, enter the new percentage and click Confirm update. You need the permission to manage production releases to do this for production.

Google doesn't prescribe a schedule. A pattern that suits a small team is a low share for a day or two, then a few steps up over a week, each raise after a look at the signals below. Something like 5%, 20%, 50% and then 100%, with at least a day between steps, gives each step a fair sample. Go slower for an update with a data migration or a new backend endpoint, and faster for a small fix.

Halting and resuming

If something goes wrong, choose Manage rollout and then Halt rollout on the same Releases tab. Google's page spells out what that means: no additional users receive the version, and users who already received it remain on it. Halting doesn't roll anyone back.

If the build turns out to be fine, choose Manage rollout, then Resume rollout, set the percentage and confirm. The Play Console app on your phone can resume a rollout too. If the build does have a problem, Google's advice is to create a new release with a fixed app bundle rather than resume the old one. Our post on Google Play review time covers how long that new release may wait for review.

You can halt a release after it has reached 100% as well. Google's APKs and Tracks guide explains the effect through the API: the halted release stops being offered to new users and as an upgrade, and the previous completed release on that track serves in its place. That is possible when the track already has an earlier completed release.

Country-targeted rollouts

For a production release, you can start a staged rollout in a limited set of countries or regions. As of 26 September 2026:

  • By default, the rollout's country availability matches your production track's countries.
  • To narrow it, edit the release, go to the Staged rollout section, and under Country availability choose Select specific countries/regions. These options exist for production releases, not testing tracks.
  • Once the rollout has started, you can't remove any countries. Start small and add, rather than the other way round.
  • Users get the update when their Google Play account is in one of the chosen locations.

Country targeting suits an update with a regional risk, such as a new payment method or a translation, or a team that wants an opening wave in its own time zone so someone is awake when the reviews arrive.

Doing it through the API

A pipeline can run the whole thing. In the Tracks API, a release with status inProgress and a userFraction such as 0.05 is a staged rollout. Raising the fraction widens it, halted halts it, setting it back to inProgress resumes it, and completed releases it to everyone. Our guide to setting up a Google Play Developer API service account covers access.

One more tip from Google's page: if the update needs store listing changes, Google recommends updating the listing after the release reaches 100% of users.

How it differs from Apple's phased release

Google Play staged rolloutApp Store phased release
ScheduleAny percentage you choose, raised by handFixed over 7 days
Who gets itA random set of new and existing usersA random sample of users with auto-updates on
StoppingHalt, with no time limit on Google's page; resume at a percentage you setPause for up to 30 days in total; resumes where it left off
CountriesCan start in chosen countries on productionApple's page describes no country option
Testing tracksAlso available on open and closed testingFor App Store version updates
Manual downloadNot described on Google's pageAnyone can download the update by hand from the App Store

The Apple column is from Apple's page Release a version update in phases, as of 26 September 2026. The practical difference is control. Apple gives you a fixed week and a pause button. Google gives you a dial, and expects you to turn it.

What to watch while it rolls out

Google's own tip for live staged rollouts is to closely monitor crash reports and user feedback, and to remember that users in the rollout can leave public reviews. Three places cover that.

Android vitals

Google's help page on Android vitals lists user-perceived crash rate and user-perceived ANR rate among the core vitals, and notes that apps over Google's bad behaviour thresholds can be less discoverable on Google Play. Every vitals view can be broken down by artifact, the version of your app the issue happened on, so you can compare the new release with the one before it. As of 26 September 2026, vitals data is updated daily and comes from users who opted in to share usage and diagnostics data, so a 5% rollout of a small app may take a few days to show a clear signal.

Reviews

Filter the Reviews page in Play Console by app version to see what people on the new build say. Our guide to testing feedback on Google Play covers the private feedback testers send before a release reaches production.

Your own feedback channel

Crash rates tell you something broke. They don't tell you that the new trail filter hides the trails people walk most, or that a button moved somewhere nobody can find it. People tell you that themselves, if there is somewhere in the app to say it.

How FeedbackKit fits in

With FeedbackKit in your app, through the Kotlin SDK or the Flutter and React Native SDKs, users can post a request, vote and comment on the board without leaving the app. During a rollout, that board is worth watching. Your team gets a push notification in the FeedbackKit admin app for every new request and every new comment, on every plan, so a cluster of complaints about the new version on day one doesn't wait until someone opens a dashboard. The early days of a rollout are when a halt is cheapest, which is when you want those pushes most.

The other half is closing the loop. FeedbackKit's statuses are Pending, Approved, In Progress, TestFlight, Completed and Rejected. FeedbackKit's beta status is called TestFlight, after Apple's service, and Android users see that same label. Many teams use it to mean "in testing", whichever store's beta it is, so a request can sit at TestFlight while it is on your closed or open testing track.

Our suggestion is to move a request to Completed when the rollout reaches 100%. Before then, most of the people who asked may not have the update yet, and an email saying it is out would confuse them. When you do, FeedbackKit emails the person who submitted it, on every plan, if they left an address and Completed is on the project's list of statuses that send email. Choosing that list needs Pro, and emailing voters who opted in needs Team; see pricing.

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

While it rolls out

FeedbackKit can post to Slack and email the people who asked when a request moves to Completed. Your team gets push notifications for new requests and comments in the FeedbackKit app.

For setup, our Android feedback board guide walks through the Compose screens.

If you want to hear from users while the rollout is still small enough to halt, start free.

Keep reading

Collect feedback in your own app

FeedbackKit ships SDKs for Swift, Kotlin, React Native, Flutter and JavaScript, and syncs what your users ask for into the tracker your team already uses.