GOOGLE PLAY CONSOLE GUIDE
How to Manually Roll Out an App Update in Google Play Console: Staged Release Guide
A safe Android release is not always a 100% launch. Google Play lets you start with a small, manually controlled percentage, watch real-world signals, then decide when to increase, halt or fully release the update.
Quick answer
To manually roll out an Android update, create or edit a production release in Play Console, select a staged rollout percentage, submit it for review, then start the rollout when it is approved and ready. Google Play does not automatically raise that percentage. You decide when to increase it, and you can halt the rollout if you find a problem.
What is a manual rollout in Google Play Console?
A manual rollout is a staged release where you choose what percentage of eligible users can receive a new app version. Instead of exposing a new Android App Bundle to everyone immediately, you can begin at a smaller percentage—such as 5% or 10%—and manually expand it after reviewing real usage.
For a Flutter or Android app, this is especially valuable when an update changes login, payments, subscriptions, database migrations, notifications, location, background tasks, a critical SDK or an API contract. Internal and closed testing are essential, but a production rollout exposes combinations of real devices, networks and user data that test environments cannot fully reproduce.
Who receives it? Google says both new and existing users are eligible in a staged rollout, and users are chosen at random for each new release. The percentage is not a hand-picked list of “first users,” and it can take time for the full selected group to receive the update.
Staged rollout vs managed publishing: do not confuse them
| Control | It answers | Example |
|---|---|---|
| Staged rollout | “How many users receive this version?” | Release build 42 to 10%, then manually increase to 25%, 50% and 100%. |
| Managed publishing | “When do approved changes go live?” | Send the release and store listing for review now, then publish them together at a time you choose. |
They can work together, but they solve different problems. Staged rollout reduces exposure to a version. Managed publishing gives you control over the timing of approved changes. Google notes that managed publishing is available only after an app is already available; it cannot be used for the first publication of an app.
Before you start a production rollout
- Test the exact release candidate. Run the same AAB through internal and closed testing where possible.
- Confirm versioning. The new Android
versionCodemust be higher than every version already uploaded to Play Console for that app. - Review pre-release reports and warnings. Check device exclusions, policy declarations, Data safety, permissions and any Play Console errors.
- Prepare observability. Ensure Crashlytics, Android vitals, server logs, payment dashboards and support channels are ready before you release.
- Know your recovery path. Have a tested fixed build ready or know which previous version is safe. A halt stops additional distribution; it does not remove a bad version from devices that already updated.
- Check account permissions. You need the appropriate permission to manage production releases. New personal accounts may also need to complete Google Play testing requirements before production access is enabled.
How to manually roll out an app update in Play Console
- Sign in to Google Play Console and select your app.
- Go to Test and release → Production.
- Open the Releases tab and choose Create new release, or edit the release you prepared.
- Upload/select the signed
.aabwith the correct higher version code. - Add clear release notes. Describe user-facing improvements, not internal commit messages.
- Resolve blocking errors and review all included changes.
- Choose the Staged rollout percentage in the review/release area.
- Send the changes for review if required. If managed publishing is enabled, wait until the changes appear under Changes ready to publish.
- When it is ready, select Start rollout to production or publish the approved changes through Publishing overview.
- Record the version code, rollout percentage, start time and release owner in your release notes or team channel.
Screen names can change slightly as Play Console evolves, but the core route remains the Production track’s Releases tab and its rollout controls.
What rollout percentage should you choose?
There is no universal percentage. Start smaller when an update touches high-risk functionality, your app has a large active user base, or your monitoring is still maturing. Start larger only when the change is small, well-tested and easy to recover from.
| Change type | Conservative starting point | Why |
|---|---|---|
| Text, minor UI fix, low-risk analytics change | 10–25% | Still watch crashes and startup behavior, but exposure is limited. |
| New screen, common Flutter package update, feature flag | 5–10% | Different devices and paths can reveal issues that tests missed. |
| Authentication, payments, subscriptions, database migration, deep links | 1–5% | Failure can block core user journeys or create data/billing problems. |
| Major rewrite, target-SDK jump, large architecture or backend change | 1–2% | Keep the initial blast radius very small and allow more observation time. |
These are operational recommendations, not Google requirements. Use the percentage that fits your risk, daily active users, support capacity and ability to issue a quick fix.
Example manual rollout plan
Day 1: 5% → verify crashes, login, payments, backend errors
Day 2: 15% → check new device/Android-version signals and reviews
Day 3: 35% → recheck metrics after a larger sample
Day 4: 75% → watch core conversion and support tickets
Day 5: 100% → finish only when signals remain healthyWhat to monitor before increasing the rollout
- Crashes and ANRs: compare the new version’s Android vitals and Crashlytics signals against the previous stable release.
- Startup and authentication: check app-launch errors, sign-in success, session creation and account recovery.
- Payments and subscriptions: for apps using Play Billing, RevenueCat or a backend payment flow, verify real purchase, restore and entitlement events.
- Backend health: watch error rate, latency, API validation failures, unusual traffic and database exceptions.
- Critical feature funnels: for example: search → place details in a nearby-places app, or add-entry → balance calculation in a ledger app.
- Ratings, reviews and support: users in a staged rollout can leave public reviews. Read new feedback, not just automated dashboards.
- Device and Android-version spread: a release that works on one phone can fail with a particular manufacturer, ABI, language, screen size or Android version.
Do not increase simply because a few hours passed. Increase when the sample size is meaningful for your app and the core journeys are healthy.
How to increase, halt or resume a staged rollout
Increase the percentage manually
- Open Production → Releases.
- Find the active release.
- Select Manage rollout → Update rollout.
- Enter a higher percentage.
- Confirm the update, then continue monitoring.
Google explicitly states that staged rollout percentages do not increase automatically. You must update them yourself.
Halt when you find a problem
- Open the active release in the track’s Releases tab.
- Select Manage rollout → Halt rollout.
- Stop investigation, communicate the issue, and decide whether to fix or resume.
For a staged release, halting means no additional users receive that version. Users who already received it remain on it, so a real fix often requires a new release with a higher version code.
Resume only when the same bundle is safe
If investigation shows the bundle is not the cause, use Manage rollout → Resume rollout, choose the desired percentage and confirm. If the bundle has a real defect, do not resume it—create and release a corrected AAB instead.
What happens after a 100% rollout?
Reaching 100% makes the update available across the release’s eligible audience, but distribution still takes time. Continue monitoring critical metrics after full rollout; some problems only appear later with less common devices or usage paths.
Google Play now also allows you to halt a fully rolled-out release on eligible tracks. If a critical problem appears, halting prevents new and existing users from installing or updating to that affected version, and the previous fully rolled-out version can become available to new and eligible users. This is a mitigation tool—not a replacement for an urgent fixed release.
Limits of a full-release halt: you cannot halt the first release on a track because there is no prior version to serve. It may also be less effective if most users have already updated, and a prior release with a policy violation cannot be used as the replacement.
Common manual rollout mistakes
Expecting 10% to become 100% by itself
It will not. Google Play requires you to manually increase the staged rollout percentage.
Using a small rollout to skip testing
Staging reduces risk; it does not make untested payments, migrations or policy changes safe. Use internal and closed testing first.
Thinking a halt downgrades everyone
A halt stops further distribution. It does not uninstall or downgrade users who already have the affected version.
Changing the store listing too early
Google recommends updating the store listing after the release reaches 100%, when the listing describes what all users can actually receive.
Publishing release and metadata at the wrong time
If timing matters, use Publishing overview and managed publishing deliberately. Allow review time; Google notes processing can take hours, up to seven days or longer in exceptional cases.
Google Play manual rollout FAQ
Can I manually roll out an app update on Google Play?
Yes. Use a staged rollout from the Production track (or a testing track) and choose the percentage of users who can receive the release.
Are users selected in order?
No. Google says new and existing users are eligible and selected at random for each new staged release.
Can I target countries in a staged rollout?
For a production update, Play Console lets you select specific countries/regions. Once a staged rollout starts, Google says you cannot remove countries from it.
Can I stop a 100% rollout?
Google Play supports halting a fully rolled-out release on eligible tracks, with important limitations. A previous fully rolled-out version can be made available to new and eligible users.
Should I use managed publishing for every update?
Use it when timing and coordination matter—for example, a launch campaign or simultaneous store-listing update. For routine low-risk maintenance releases, it may add process without much benefit.
Release owner checklist
- Build and test a release candidate from a clean branch.
- Verify version code, signing, permissions, Data safety and release notes.
- Start with a percentage appropriate to the release risk.
- Monitor technical and business signals before every increase.
- Halt immediately if a critical issue is confirmed.
- Release a fixed higher-version AAB if affected users need a repair.
- Update the store listing only once the relevant feature is broadly available.
Google Discover publishing checklist
- Use the supplied specific title, natural search description and relevant labels without keyword stuffing.
- Replace the image placeholder with an original 1200 × 630 px or larger featured image using the supplied alt text.
- Show author and update date, and revise this guide if Play Console terminology or behavior changes.
- Configure canonical URL, Open Graph image and
max-image-preview:largein the Blogger theme. - Keep the article mobile-friendly and people-first. Discover has no special application and placement is never guaranteed.
