Google Play staged rollout and release notes from the CLI

Uploading an .aab to Play Console by hand means opening the track, creating a release, pasting notes into language tags and typing a rollout percentage. VibeView does that part from one command or one dialog. It uses a Google Play service account key you store once (a service account is a Google Cloud account that a tool uses to publish for you). This guide covers the release choices: which track, and whether the release goes out at once, as a draft or to a share of users.

It assumes the one-time Google Play setup is done: the app exists in Play Console, a service account key is stored in VibeView, and you have a signed production build. Build an Android app in the cloud walks through all three.

What a staged rollout is

A staged rollout sends an update to a percentage of your users first. According to Google’s staged rollouts help page:

It works on production and on the testing tracks, for app updates only. The first release of an app can’t be staged.
Users are chosen at random for each release, and they aren’t told they’re in a rollout.
The percentage won’t increase automatically. You raise it in Play Console with Manage rollout → Update rollout.
Halt rollout stops new users from getting the version. People who already have it keep it.

So the rollout has two halves. VibeView does the first: the upload, the release, the notes and the starting percentage. The second half, deciding when to widen or stop it, happens in Play Console.

Tracks and release choices

A track is the audience a release goes to, from internal testers to every user (Google Play tracks). The dashboard and the CLI name them differently:

Track	CLI `--track`	Default release
Internal testing	`internal`	Release now
Closed testing	`alpha`	Release now
Open testing	`beta`	Release now
Production	`production`	Save as draft

The Release choice, or --release-status, says what happens after the upload:

Release now (completed): everyone on the track gets the release, after any review Google does.
Save as draft in Play Console (draft): the release waits in Play Console until you start it there.
Staged rollout (inProgress): a share of users gets it. In the dashboard, enter a Rollout percentage from 1 to 99. In the CLI, pass --rollout as a fraction between 0 and 1, so 0.1 is 10%. The dashboard offers it on every track except Internal testing.

Production starts on a draft, so a release to every user is never the default. If you choose Production with Release now, the button turns into Release to all users. A warning then says every user gets the build as soon as the upload finishes. A staged rollout on Production gets the same warning for its share of users.

The CLI checks the pairing before it sends anything: --rollout needs --release-status inProgress, and inProgress needs a --rollout.

Release notes

Google allows release notes of up to 500 characters per language (prepare and roll out a release). With VibeView, --release-notes or --release-notes-file sets the note in your Play listing’s default language, and --notes-dir adds other languages. In the dashboard, write them under Release notes, by language. Release notes and What to Test in many languages covers the rules, the folder layout and the language codes.

Start a staged rollout from the CLI

Check that Google Play knows the app. Replace com.example.myapp with your package name. No build is needed, and nothing changes in Play Console:
```
vibeview submit --check --platform android --package com.example.myapp
```
Optional: write the notes. Put the default language’s note in its own file, and other languages in a folder next to it:
```
release-notes.txt     the default language (for example English)
notes/
  de-DE.txt
  fr-FR.txt
```
Upload and start the rollout. --rollout 0.1 is 10% of users; change it to the share you want. Drop the two notes flags if you skipped step 2:
```
vibeview submit --platform android --latest --track production \
  --release-status inProgress --rollout 0.1 \
  --release-notes-file release-notes.txt --notes-dir notes/
```
--latest takes your newest succeeded production build. Pass --build <id> to choose one. When the upload succeeds, the command prints vibeview submissions status <id>. That command shows the release as VibeView sent it and how to change it in Play Console.

To skip the flags next time, set defaults in the submit block of vibeview.json, next to the build config: "submit": { "track": "production", "releaseStatus": "draft" }. The block also takes rollout, and flags always win.

In the dashboard

On the Builds page, choose Submit to store on the build, then Google Play. Choose the Track, Staged rollout under Release, and the Rollout percentage. Write any notes, then choose Upload to Google Play.

Use these settings next time saves the track and the release choice for the app’s next build. A staged rollout isn’t saved: you choose it for each release. Production always starts on Save as draft.

After the upload: raise, halt or complete it

VibeView doesn’t change a release after the upload. The build’s Store submissions card shows the release as VibeView sent it: the track, the rollout percentage, the version name and code, and the notes’ languages. Play Console shows its current state, so a change you make there later doesn’t show on the card.

Under How to change this release in Play Console, the card lists the steps for a staged rollout:

Raise the rollout: Manage rollout → Update rollout, enter the new percentage, then Confirm update.
Halt the rollout: Manage rollout → Halt rollout.
Resume a halted rollout: Manage rollout → Resume rollout.
Release to everyone: Manage rollout → Update rollout, enter 100%.
Promote to another track, on a testing track.

Each step starts from the app’s track page in Play Console (for example Test and release → Production → Releases). Open Play Console on the card opens Play Console.

Managed publishing and review

With managed publishing on, changes go live only after you publish them in Play Console (Publishing overview). The Store submissions card notes this, because it changes when a staged rollout starts. Google’s managed publishing page says it holds back full and staged rollouts. It lists a few exceptions, among them increasing an existing staged rollout to 100% and updating a release’s notes.

Two more review rules:

Don’t send for review (--changes-not-sent-for-review, CLI 0.56.0 or later) saves the release in Play Console without sending it for review. Use it when Google asks you to send changes from Play Console yourself, usually after a rejected update. Then send them from Publishing overview → Send for review. In the dashboard it is chosen for each release and never saved. From the CLI, pass the flag, or set "changesNotSentForReview": true in the submit block of vibeview.json to turn it on for every submit. See Changes not sent for review.
A review in progress starts over. When Google is already reviewing earlier changes to the app, VibeView sends the release the way Google does by default. That cancels the review and starts it again with this release, and the card and the log say so. To avoid it, wait until the review in Play Console finishes before you send.

One upload at a time per service account

Uploads that use the same Google Play service account run one at a time, even across apps. A phone app and its Android TV app that share one key are an example. A second upload waits its turn, and its card says “Waiting for another Google Play upload that uses the same service account to finish.” until it starts on its own.

In CI and for Android TV

A CI-only VibeView token can submit to any Google Play track with the key already stored in VibeView, so the same command runs in a pipeline. Pass --build <id> rather than --latest, so each run submits its own build. GitHub Actions to TestFlight shows the workflow shape.

An Android TV app uses the same flags with --platform androidtv. Fire TV apps go to the Amazon Appstore, which has no test tracks through its API, and the CLI refuses the Google Play flags with --store amazon. See Submit a Fire TV app to the Amazon Appstore. TestFlight builds for iPhone, iPad and Apple TV go out with the same vibeview submit command.

What stays in Play Console

Everything else stays in Play Console: raising, halting, resuming or completing a rollout, promoting a release, starting a draft and sending saved changes for review. So do the Play listing and screenshots, pricing and countries, and data safety. Done in the store’s console lists where each task lives.

Next: run vibeview submit --check --platform android for your app. Then send your next update to Closed testing with --release-status inProgress --rollout 0.1, and widen it in Play Console when it looks healthy.

Frequently asked questions

Can VibeView raise the rollout percentage for me?

No. VibeView sets the starting percentage and never changes a release after the upload. Raise, halt or complete the rollout in Play Console; the Store submissions card lists the steps.

Can I stage the first release of an app?

No. Google allows staged rollouts for app updates only, so the first release of an app goes out in full or as a draft.

Why is the Production track a draft by default?

So that a release to every user is never chosen by accident. Choose Release now or Staged rollout yourself, and the dialog warns you before it sends.

Do release notes have to be in every language?

No. See Release notes and What to Test in many languages for what is required.

Does the card show the rollout after I raise it?

No. The card shows the release as VibeView sent it. Play Console shows its current state.

Google’s pages referenced here were checked on 25 October 2026.