Use a Google Play Staged Rollout with Measurable Stop Conditions

Establish a baseline by version

Compare the candidate with the previous production release using crashes, ANRs, startup failures and the app's core transaction metrics. Segment by device, OS and geography where sample size permits.

A low overall crash rate can hide a severe failure on one architecture. Conversely, a handful of reports in a tiny cohort should be investigated without pretending the rate is statistically stable.

Choose explicit expansion gates

Select thresholds appropriate to the product and baseline. Do not copy an arbitrary rollout percentage and assume it provides sufficient coverage.

Manage the release state deliberately

Use the production release controls under Test and release and inspect the rollout state before changing it. Review current Console documentation for available halt or resume actions. Do not confuse unpublishing the app with halting an update's distribution.

If a serious problem appears, preserve the artifact and diagnostic evidence, stop expansion where supported, and prepare the corrective version. A server-side mitigation should be reviewed for data and compatibility consequences rather than used as an untracked emergency patch.

Remember upgrade state

Test migration from the last production version and recovery from interrupted operations. A candidate that works after clearing all app data may still fail for the users receiving the update.

APKLint's release checklist helps organize the evidence but does not monitor the live cohort or change rollout percentages. Use Play release management and Android vitals, alongside your product monitoring, to decide when expansion is justified.