Publishing an Android app is not a single action. Google Play organises releases into tracks, and a build moves through them in sequence. Understanding that sequence before starting saves weeks, because several of the gates involve fixed waiting periods that cannot be shortened by working harder.
There are four tracks. Internal testing distributes to a small list of addresses almost immediately and is intended for the developer's own devices and close colleagues. Closed testing goes to a defined tester list, either individual email addresses or a Google Group, and is where most pre release work happens. Open testing produces a public beta anyone can join from the store listing. Production is the public release. A build is promoted from one track to the next rather than uploaded separately, which keeps version codes consistent across the sequence.
The gate that surprises most first time publishers applies to personal developer accounts created after November 2023. Those accounts must run a closed test with a minimum number of testers who stay opted in continuously for a set period, currently twelve testers across fourteen consecutive days, before production access is granted. The requirement is measured on continuous opt in rather than on installs or activity, so a tester who joins and later leaves resets their contribution. Recruiting more testers than the minimum is the only sensible hedge. Organisation accounts are not subject to this particular requirement.
Review itself mixes automated and manual checks and applies to every release, updates included. The pieces that most often need attention are declarative rather than technical. The Data safety form must describe exactly what the app collects and shares, and it is checked against the app's actual behaviour, so a form that omits an analytics SDK is a mismatch rather than an oversight. Apps with any login gated content must supply working credentials under App access, and this is the single most common cause of a stalled review for apps with accounts. If sign in is protected by a captcha, or by a one time code sent to a device, a plain username and password will not let a reviewer in, and the app is rejected for content the reviewer could not reach. Providing a dedicated demo account that bypasses those protections, and saying so in the notes, is the reliable fix.
Other frequent rejection causes are worth checking before submitting rather than after. Permissions the app requests but does not visibly use require a declaration or removal. A privacy policy URL must be live and must actually describe the app in question. Target API level requirements advance every year and a build below the current floor will not be accepted. Screenshots and descriptions showing functionality the app does not have are treated as misrepresentation rather than marketing.
Once production access is granted, releases are usually rolled out in stages. A staged rollout releases to a percentage of users and can be halted if crash rates rise, which is considerably better than discovering a regression after full distribution. Version codes must increase monotonically and can never be reused, so a build that is rejected consumes its number permanently. Leaving a gap in the numbering costs nothing and avoids awkwardness later.
Timelines vary. Internal testing is effectively instant. Review of a first production submission commonly takes several days and can run longer, and updates are usually faster without being guaranteed to be. The fixed fourteen day testing window is the one part of the schedule that is genuinely immovable, so it belongs at the front of a release plan rather than the end.
References:
Google. Play Console Help: Prepare and roll out a release.
Google. Play Console Help: Set up an open, closed, or internal test.
Google. Play Console Help: Provide information for Google Play's Data safety section.