Handling App Crashes During Closed Testing

Your app crashes on day 3 of a 14-day closed test. The first question every developer asks is whether shipping a fix restarts the clock.

It does not. Here is the reasoning, and then everything else you need to handle it properly.

Do not panic-upload

The most expensive mistake here is not the crash. It is uploading three fixes in a row.

Every release on a closed track goes through review, and Google's documentation warns that the review clock "is counted from the last submitted change to an app. This means that if you submit a change while there are changes in review, your app may be pushed to the back of the app review queue."

In practice, uploading a second build while the first is still in review means the first is discarded and you restart the queue. Upload faster than review completes and nothing ever ships.

Diagnose fully, fix once, submit once, wait. Processing takes a few hours to seven days, and new personal developer accounts, exactly the people subject to the 12-tester rule, are the most likely to see the longer end.

Where to find the crash

Android vitals will probably show you nothing, and that is expected

This is the part that confuses people most. Android vitals does collect data from closed testing testers. Google's reporting API has a dedicated app-testers cohort for exactly this. But vitals also only reports when there is enough data to stay anonymous.

With 12 testers, of whom only some have usage and diagnostics sharing enabled, you will very often fall below that threshold and see an empty page. An empty vitals page during a closed test does not mean zero crashes. It means not enough users to report on.

Path if you want to check anyway: Monitor and improve, then Android vitals, then Crashes and ANRs. Data updates daily, not in real time, and you can filter by artifact to isolate a specific build.

Pre-launch reports are the underrated one

Every time you publish a bundle to a test track, Google automatically runs your app on real devices in its lab and generates a pre-launch report. When it finds a crash you get device information, the full crash detail, the Logcat from the device, and a video of the error.

For a developer with 12 testers and no vitals data, this is frequently the highest-signal crash source available, and most people never open it. It is under Test and release, then Testing, then Pre-launch report.

Crashlytics is what you actually want during a small test

Firebase Crashlytics reports per-session and in near real time, which is what you need when you have a dozen users and a two-week deadline. You can also link your Play app to Crashlytics to see Play track information there, which is how you tell closed-test crashes apart from everything else.

Expect the numbers to disagree with vitals, and know why before it alarms you: vitals counts issues per daily active user while Crashlytics counts per session. One user who opened your app three times and crashed once shows as a 100% crash rate in vitals and 33% in Crashlytics. Vitals also catches crashes that happen before your SDK initialises, and ANRs on Android 10 and below, which third-party tools cannot see at all.

Getting readable stack traces

If you ship an app bundle and use Android Gradle plugin 4.1 or later, there is nothing to do. Google pulls the deobfuscation file out of the bundle automatically. This is the single most common piece of outdated advice in this area.

You only need to upload mapping files manually if you are shipping APKs, or if automatic pickup fails. That is under Test and release, then App bundle explorer, pick the artifact, Downloads tab, Assets section.

Two things worth knowing:

• Only ReTrace-compatible mapping files work for Java and Kotlin, the format R8 and ProGuard produce. Native C++ code needs a debug symbols file instead.
• You need the file for each version of your app. That matters here, because you are about to ship several builds in two weeks.

For Crashlytics, the Gradle plugin uploads mapping files automatically by default.

The crash rates that actually matter

Google publishes bad-behaviour thresholds for Android vitals:

"User-perceived" means the crash was likely noticed, meaning one that happened while the app was in the foreground or running a foreground service. For ANRs, only "input dispatching timed out" is counted.

Exceeding these makes your app less discoverable on Google Play, and can put a warning on your store listing. Google generally evaluates the last 28 days.

Be clear about what these thresholds are and are not: they govern store discoverability, not production access approval. Google has published no crash-rate figure that gates production access.

Do crashes affect the production access review?

Indirectly, and the honest answer has two parts.

Google does name stability as something to check before applying, since "ensure your app is stable and free from broken functionality, crashes, or missing screens" is on the pre-application checklist. But the two reasons it names for sending you back to more testing are fewer than 12 opted-in testers and insufficient tester engagement. Crash rate is not named.

The real risk is the second-order effect. An app that crashes on launch produces testers who stop opening it, and low engagement is an explicitly documented rejection reason. The crash does not fail you; the disengagement it causes does.

There is an upside worth taking seriously. The application asks you to describe what you changed based on tester feedback. A crash found by a real tester, diagnosed from a real stack trace, and fixed in a dated build is the single strongest thing you can put in that answer. Handled well, a crash on day 3 makes your application better than a flawless run would have.

Shipping the fix

1. Reproduce it, or get enough from the stack trace and Logcat to be confident about the root cause
2. Fix it, bump the version code, and upload one build to the closed track
3. Submit for review and leave it alone
4. Tell your testers a fix is coming and roughly when

Once approved, testers who already have the app installed update automatically. Google's documentation says "their app automatically updates to the test version within a few minutes." Devices always receive the highest version code they are eligible for.

The caveat Google does not mention: that assumes auto-update is enabled on the tester's device. Someone with auto-update off, or restricted to Wi-Fi, may sit on the broken build indefinitely. Ask testers to open the Play Store and update manually after a fix rather than assuming it landed.

Keeping testers from uninstalling

Uninstalling is not the same as opting out, and Google's requirement is written around opt-in rather than installation. So an uninstall probably does not break your continuity, but Google has never published a statement either way, and someone who uninstalled is contributing nothing to the engagement half of your review.

Do not gamble on the technicality. The practical version:

• Tell testers what happened before they hit the crash again. Silence is what makes people uninstall.
• Give them a time frame. "Fix submitted, live within 48 hours" keeps people waiting. "Sorry, looking into it" does not.
• Ask them to report rather than remove. A bug report costs you an hour. An uninstall can cost you the window.

How Closed Test Pro handles this

Two things matter when your app crashes in a reciprocal community.

Testers who hit a crash report it from inside Closed Test Pro rather than silently uninstalling, and the app tells them to wait 20 to 30 seconds and mark the test done so their streak survives. That is deliberate, because a crash should not cost the tester anything, because testers who get punished for your bug stop testing your app.

Once you have the fix live, post an App Update task in the Task Hub. Your existing testers get told to pull the new build instead of sitting on the broken one. That closes the loop the production access application asks about: a tester found it, you fixed it, testers verified the fix, with dates.

Frequently asked questions

Related guides

• Preparing your app for production approval
• What to do if testers uninstall your app
• Debug closed testing issues step by step