Add Firebase Crashlytics to Your Closed Test Build
Set up Firebase Crashlytics before testers arrive: Gradle plugin, R8 mapping files, custom keys for context, and your Data safety declaration.
Short answer
Add the Firebase project config to your app, apply the Crashlytics Gradle plugin and SDK, make sure mapping files upload for release builds, then force a test crash to confirm reports arrive. Declare crash logs and diagnostics in your Data safety form, because Crashlytics collects them.
Why before testers arrive
Testers rarely send stack traces. A crash reporter turns “it closed when I tapped save” into a file, line and device. Most of your fixes during a 14-day test will come from it.
Setup outline (native Android)
- Create a Firebase project and add your Android app with the exact applicationId.
- Download google-services.json into app/.
- Apply the Google services and Crashlytics Gradle plugins, and add the Crashlytics SDK (via the Firebase BoM).
- For release builds with R8, leave mapping-file upload enabled so stack traces are readable.
- Build a release, trigger a test crash, reopen the app, and check the Firebase console.
Flutter (firebase_crashlytics), React Native (React Native Firebase) and Unity all have Crashlytics plugins with equivalent steps. Follow the official Firebase docs for your framework.
Add context testers can’t give you
- Custom keys: current screen, feature flags, build channel (“closed-test”).
- Logs of the last few actions before the crash.
- User ID: only a pseudonymous ID, never emails, so you respect privacy and your Data safety answers.
Data safety and privacy
Crashlytics collects crash logs, diagnostics and device identifiers. Declare them in your Data safety form (typically for app functionality and analytics purposes) and mention them in your privacy policy.
Using it during the test
| Day | Action |
|---|---|
| Daily | Check new issues and velocity alerts |
| After each update | Confirm the fixed issue stopped occurring |
| Before applying | Summarise crashes found and fixed for your application |
Combine with Android vitals, which shows Google’s view of your stability, and with tester notes via in-app feedback.
Frequently asked questions
Should I disable Crashlytics in debug builds?
Many developers do, so development crashes don’t clutter reports. Keep it on for the builds testers use.
Why are my stack traces obfuscated?
R8 mapping files weren’t uploaded for that build. Check the Crashlytics Gradle settings for release builds.
Can I report non-fatal errors?
Yes. Log caught exceptions as non-fatal events to see problems that don’t crash the app.
Sources and how we keep this accurate
- Play Console Help: Provide information for Google Play’s Data safety section
- Firebase docs: Get started with Firebase Crashlytics
Policy facts are checked against Google's own documentation on the date shown above. Google can change requirements at any time, so confirm in your Play Console. Where we give advice or estimates rather than Google's rules, we say so. TestersZone is independent and not affiliated with Google. Drafts are AI-assisted and reviewed by our team.
Need 12 testers? Get them free.
Test 3 apps, earn 60 credits, and list your app for up to 20 real testers with verified daily check-ins.
Start freeKeep reading
Using Android Vitals During Your Closed Test
How to Collect In-App Feedback From Closed Testers
How to Fill Out the Google Play Data Safety Form
How to Test In-App Purchases With License Testers
How to Write Release Notes for Closed Test Builds
Browse all guides, or see the quick answers, guides and comparisons.