How to Handle Crashes Reported During a Closed Test

A tester says your app crashed. Don't panic, and don't push a quick guess to the closed track. Collect the same few facts every time, find the stack trace, reproduce the crash, fix it, and ship a new build to the same track. This post walks through that process.

Finding crashes is one of the main reasons a closed test exists. A crash in testing is far cheaper than the same crash in production.

Step 1: Ask for the same details every time

"It crashed" is not enough to act on. When a tester reports a crash, ask for:

• Device model and Android version (for example, a mid-range phone on Android 12)
• App version (the version name or build number shown in your app or in Play Store)
• What they were doing in the 30 seconds before the crash
• Whether it repeats or happened once
• Connection state: Wi-Fi, mobile data or offline
• A screenshot or short screen recording, if they can

Put these questions in a short template and paste it into your tester group or feedback form. If you want more on collecting useful written feedback in general, see our post on how to collect useful feedback from closed testers.

Step 2: Look for the stack trace yourself

Testers shouldn't have to find logs. Check these sources:

1. Play Console, Android vitals. Crashes and ANRs (app not responding) from your testers may show up in the Crashes and ANRs reports. Data can take a while to appear, and low volumes may show little or nothing, so don't rely on it alone.
2. A crash reporting library. If you've added one such as Firebase Crashlytics, check its dashboard. It captures the stack trace and device details automatically.
3. A tester's own logs. If you can't find anything, ask one tester to reproduce the crash with a cable-connected phone or a bug report. This is a last resort, because most testers won't want to do it.

Google's guide to crash rates in Android vitals explains how crashes are counted and what the reports show. Menu names in Play Console change from time to time, so check Play Console Help if something looks different from what's described here.

Step 3: Make the stack trace readable

If you build with R8 or ProGuard, your release stack trace will show scrambled class and method names. You need the mapping file for that exact build to translate it back.

• Keep the mapping.txt from every build you upload. Don't overwrite it with the next one.
• Upload it to Play Console with the release if you can, so reports are deobfuscated for you. The exact steps are in Play Console Help.
• If you use Crashlytics, check that its mapping upload is working. Otherwise you'll get unreadable traces there too.

A readable trace usually points to a file and line number. That is often most of the work done.

Step 4: Reproduce it

Try the tester's exact steps on your own device or an emulator with matching specs. If it doesn't crash, think about what differs between your setup and theirs. Common causes of "works on my phone" crashes:

• Different Android version. A permission, API or background-work rule behaves differently on older or newer versions.
• Low memory. Large images or leaks that a flagship phone absorbs can crash a budget phone.
• Process death. The system killed your app in the background and it restored with missing state. Turn on "Don't keep activities" in Developer options to test this.
• Screen rotation or split screen. Configuration changes can break screens that assume a single layout.
• No network or a slow one. Code that assumes a response always arrives.
• Locale and formatting. Number, date or text parsing that fails outside your own language setting.
• Permissions denied. The tester tapped "Don't allow" and your app never handled it.
• Fresh install vs upgrade. A database migration that only fails for people who had the previous build.

This is where real devices earn their keep. Emulators and your own phone cover a narrow slice of what people actually carry. TesterMob testers use their own Android phones, so they tend to surface exactly these device-specific problems.

Step 5: Triage before you fix

Not every crash deserves the same urgency. Sort them roughly like this:

• Fix first: crashes on launch, during onboarding, or in your core flow. Also anything several testers hit.
• Fix next: crashes in secondary screens that repeat reliably.
• Log and watch: one-off crashes you can't reproduce, especially on unusual devices. Add logging or a null check, ship it, and see if it returns.

Write each crash down with its device, version, stack trace and status. A simple spreadsheet is enough.

Step 6: Fix it and ship a new build to the same track

1. Fix the bug, ideally with a small test or a clear manual check so it doesn't come back.
2. Increase the versionCode. Play Console rejects an upload with a code it has already seen.
3. Build a signed AAB and keep its mapping file.
4. Create a new release on the same closed testing track, with release notes saying what you fixed.
5. Tell testers an update is available and ask them to try the specific flow that crashed.

Resist bundling a lot of unrelated changes into the fix. A small, focused update makes it easy to tell whether the crash is gone, and it avoids introducing new ones.

Will a crash or an update affect your 14-day count?

The closed test requirement is about having at least 12 testers opted in for 14 days in a row. A crash by itself doesn't change that. What can hurt is testers losing interest and opting out, so respond quickly and tell them their report led to a fix. Releasing a new version to the same track is normal and doesn't normally require testers to join again. Rules and counting details can change, so confirm in Play Console Help, and see our post on why the 14-day counter resets if you're worried.

How to reply to the tester

Testers who see their report acknowledged keep testing. A short reply is enough:

Thanks for reporting this. We found the cause and a fix is in build 1.0.3. Could you update and try the same steps again?

If a tester can't update yet, tell them roughly when the new version should appear. Updates can take some time to reach devices.

Keeping an eye on activity between reports

Silence doesn't mean everything works. A tester might hit a crash, give up and stop opening the app. If you use TesterMob, the optional Android SDK (an .aar file) shows daily tester activity in your dashboard, so you can notice when use drops off after a release. The developer page explains how the service works, and the FAQ covers common questions.

A quick checklist

• Ask for device, Android version, app version, steps and a screenshot.
• Check Android vitals and your crash reporting tool.
• Keep mapping files for every build.
• Reproduce on a matching device or emulator.
• Prioritize launch and core-flow crashes.
• Raise versionCode, upload to the same track, write release notes.
• Tell the tester what changed and ask them to retest.

Handling crashes calmly makes your closed test more useful and gives you a more stable app at launch. Nothing here can guarantee production approval, since that decision is Google's, but a stable build is the best starting point.