Fixing Crashes and ANRs Before Google Play Review

Add a short pre-submit gate that blocks release candidates with new reproducible crash signatures or ANRs. This guide helps Android release owners, on-call mobile engineers, and CI/DevOps teams implement checks, automation, and a runbook you can wire in 1-3 days and run in 15-60 minutes per RC, with longer triage for tricky regressions. The practical result is fewer emergency rollbacks, fewer 1-star reviews, and lower review/rejection churn; tradeoffs include added release friction and maintenance cost.

These signals are directional and come from common internal telemetry patterns, not external benchmarks. What this means in practice: focus on API-level ANR deltas, prioritize Play pre-launch failures, and keep symbol/mapping uploads timely to reduce downstream cost and reviewer friction.

24-Hour Google Play Resubmission Checklist goes deeper on the ideas above and adds concrete next steps.

Should I block Google Play submissions for new crashes or ANRs?

A flow diagram specific to this article showing: Build candidate → Run Play pre-launch → Targeted Firebase Test Lab runs (device/API matrix) → Collect Crashlytics/grouping keys and adb bugreports → Decide (block/override). Each node lists recommended tools and timeboxes (e.g., Test Lab: 30 - 240 minutes).

Yes - block submissions for reproducible, version-specific regressions that exceed defined thresholds, because preventing broad user impact and rating damage usually outweighs the extra release friction. This is a judgment call: blocking helps when the regression is clearly tied to the RC and reproducible, and it hurts when the gate is noisy or poorly scoped.

Set an enforceable threshold and measurement sources

Enforce thresholds based on Crashlytics counts and API-level ANR deltas and make them explicit in your release runbook.

• Crash threshold: new Crashlytics signature with N >= 5 unique devices or sessions in the RC window; use 1-3 for very low-volume apps and scale N up for large apps.
• ANR threshold: API-level ANR increase of >1.0 to 1.8% that correlates with the RC; triage API 29-31 first.
• Pre-launch: treat Play pre-launch native crashes or missing mapping files as a hard stop.

These are starting points; tune thresholds as you collect false positives and misses.

Tradeoffs, maintenance, and who gets the override

Expect a 1-3 day setup cost to wire CI checks, upload mapping and native symbols, and create a minimal Test Lab matrix; after that plan for 15-60 minutes of checks per RC, and budget 30 minutes to 4 hours for difficult regressions. You will get false positives from intermittent flakes and device sampling gaps; document a fast triage path and a timebox for reproduction before override. Require a brief written justification plus two approvers - release owner and engineering manager - for emergency overrides, and log overrides for postmortem analysis.

A simple decision flow teams can adopt today

1. Detect

   CI or Play pre-launch flags a new crash/ANR signature; notify release owner and on-call via Slack or PagerDuty.

2. Reproduce

   Run a targeted Firebase Test Lab matrix matching reported API/device combos within 30-240 minutes; collect Crashlytics, adb logs, and Play pre-launch reports.

3. Decide

   If reproducible and above threshold, block submission; if intermittent, run 3 repeat Test Lab runs and only allow override after documented triage and two approvers.

When you move from outline to execution, Guide to publish a personal ai companion app android helps close common gaps teams hit here.

How do we reproduce, patch, and validate crashes with CI and Firebase Test Lab?

Use a reproduce, patch, validate cycle integrated with CI and a focused Test Lab matrix to minimize risk and create reviewable evidence. This pattern keeps fixes small, traceable, and reversible.

Reproduce: CI, Firebase Test Lab, and device/API selection

A compact, copyable checklist block tailored to this article that includes: Play pre-launch pass, Crashlytics no new signatures and symbols uploaded, Android Vitals ANR check, internal cohort (10 - 50 devices) validation, and staged rollout plan with hotfix ready.

Start by mapping device and API combos from Play pre-launch and Crashlytics grouping keys; pick the top 5 device models and API levels that match the signature, focusing on API 29-31 first. Run a targeted Firebase Test Lab matrix using Robo plus instrumentation limited to those 5-20 devices, re-run failing tests 2-3 times to rule out flakiness, and collect stack traces, native tombstones, mapping.txt, and adb bugreports.

Patch: minimal safe fixes and symbol/mapping hygiene

Apply the smallest safe change that removes the regression: add a defensive null check, move heavy work off the main thread using Executors or WorkManager, or revert the offending commit. If native or obfuscated, upload native symbols and mapping.txt to Crashlytics and Play Console immediately so traces are readable for reviewers. Create a hotfix branch and let CI run the same Test Lab matrix.

Validate: targeted Test Lab runs, Play pre-launch re-check, and internal track

Confirm zero occurrences across three targeted Test Lab runs and verify Play pre-launch for those devices. Deploy to an internal testing track with 10-50 devices or staff for 24 hours, monitor Crashlytics and Android Vitals for API-specific anomalies, and then use a staged rollout at 5-10% for 24 hours with rollback and feature-flag support ready.

Pre-submit checklist you can copy:

• Play pre-launch: pass for targeted devices
• Crashlytics: no new signatures above threshold; mapping.txt and native symbols uploaded
• Android Vitals: no API-level ANR spikes linked to the RC
• Internal cohort: 10-50 devices validated for 24 hours
• Staged rollout plan: 5-10% with rollback and hotfix branch ready

A complementary angle worth comparing lives in How to Publish a React Native App: Founder-Friendly Checklist.