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
| Gate | Example evidence |
|---|---|
| Technical stability | No new severe crash/ANR cluster |
| Core flow | Login, save, checkout or gameplay remains functional |
| Backend | Error rates and capacity remain within agreed limits |
| Support | No unresolved high-severity user reports |
| Recovery | Corrective build can be produced and signed |
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.
Look for failures among users who actually upgraded
Suppose a release changes the local database while adding a new search screen. Clean installations work, but a subset of upgraded accounts cannot open saved records. Segment the reports by previous version and migration path. An overall successful-launch count can hide the failure if many observed sessions came from fresh installations.
Keep the previous production baseline and candidate observations comparable. State the time window, affected cohort and denominator alongside any rate. Do not compare raw counts from a large old release with a small new cohort and conclude that the new build is safer merely because fewer events arrived.
Treat a halt as a distribution action with follow-up work
When a stop condition is reached, use the available release controls and confirm the resulting state. Halting further rollout does not repair data already migrated on devices that received the update. Preserve their reports and plan the corrective path for those users.
Reproduce the failure with a copy of synthetic data created by the affected previous version. Verify the correction both for users still on the old release and for users who already attempted the failed migration. Those two starting states can need different recovery handling.
Review any server mitigation for compatibility with both cohorts. Disabling a feature remotely might reduce immediate exposure, but removing a field required by an older supported client can create another failure. Record the configuration change and its observation window so later diagnosis can distinguish it from the client fix.
Before resuming or releasing a correction, have the release owner inspect the actual evidence for the original stop condition. A new version number and a successful build do not show that the migration succeeded. Include the failed synthetic record, the expected recovered state and the observed result.
After expansion, watch for the same failure category as well as new symptoms. Keep the incident linked to the affected version range so support can provide accurate recovery instructions without telling every user to clear data and potentially destroy the records being repaired.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
