Walk through the Play Store release process — tracks, staged rollout, App signing
Four tracks, a signing model split into two keys, and a rollout percentage that can be halted but never quietly undone.
LEARN BY DOINGPut your intuition to work3 steps
Walk through the Play Store release process — tracks, staged rollout, App signing
Use the lesson’s examples and explanation to check your idea.
Personal reflection. Nothing is sent to an AI service.Getting an Android build in front of users runs through a pipeline with four tracks, a signing model that's easy to misunderstand, and a rollout mechanism inside the last track. Walking through it cleanly — in the right order, using the right names — is itself a signal that you've actually shipped apps through Google Play, not just built one in isolation.
#The four tracks
Internal testing is the fastest lane: up to 100 testers, added by email, with no Google review at all, so a build can be available within minutes of upload. It exists for smoke-testing yourself and your immediate team before anyone outside the company sees it.
Closed testing — what most teams still call "alpha" — is opt-in through an email list or a Google Group, does get a (usually light) review, and is where you run a real QA pass with a wider group: support staff, stakeholders, an early access cohort. Since late 2023, Google requires new personal developer accounts to run a closed test with at least 12 testers opted in continuously for 14 days before they can even apply for production access, so this track isn't optional for a new account no matter how confident you are in the build.
Open testing ("beta") is public: anyone with the opt-in link can join without you managing a list, and it scales to thousands of testers. It's the track for a genuine beta program, where you want real-world device and network diversity before production.
Production is the listing everyone else sees, and it's the only track where a staged rollout percentage applies.
#App signing: upload key vs. app signing key
Play App Signing splits the one signing key you used to manage yourself into two: an upload key, which you hold and use to sign the AAB you send to Google, and an app signing key, which Google holds and uses to actually sign the APKs installed on devices. That split is what lets Google recover your account if you lose the upload key — you request a reset, prove ownership, and get a new upload key without touching the app signing key or breaking updates for existing users — and it's what lets Google re-optimize the signing key format over time without asking you to re-sign anything. It's also mandatory in practice: Android App Bundles have been the required publishing format since August 2021, and an AAB can only be published through Play App Signing.
#Staged rollout, and what halting it actually does
Inside the production track, a staged rollout releases the new version to a percentage of users who check for an update, then lets you ramp it — 5, 10, 20, 50, 100 — while watching Android vitals: crash rate, ANR rate, and the pre-launch report Google runs automatically against a matrix of real devices before your build even reaches testers.
The detail that trips people up in interviews: halting a staged rollout stops the percentage from climbing and stops new users from receiving the update, but it does not roll back the update on devices that already installed it. If you need those devices back on the previous version, you publish a new release with a higher version code than the bad one, containing the previous version's code — a genuine rollback release, not a pause.