Reproduce the official test path
Use the test-crash procedure on a controlled build. Trigger the crash, relaunch as instructed and allow a working network path for delivery.
Do not test only while a debugger changes process or exception behavior. Follow the documented test conditions before concluding that the SDK is broken.
Check identity and initialization
Confirm application ID, Firebase app configuration, selected flavor and the Crashlytics integration. A report arriving in staging while you watch production is a configuration issue, not necessarily a transport failure.
Inspect redacted SDK logs for initialization or upload errors. Never publish raw user data from crash attachments or logs.
Follow the pipeline in order
| Stage | Evidence |
|---|---|
| Build integration | Correct module plugins and SDK dependency |
| Runtime initialization | Expected Firebase app active |
| Collection | Consent/settings allow the intended test |
| Crash recording | Controlled fatal crash actually occurs |
| Upload | App restarts and network is available |
| Display | Correct project/app and relevant filters |
Do not change several stages at once. One controlled correction produces much clearer evidence than a complete dependency reset.
Distinguish crash types
A handled exception recorded as non-fatal is not the same as a fatal crash. ANRs and native crashes have their own collection and symbol requirements. Search the appropriate report category.
Verify the release separately
After the development test works, confirm the optimized distributed test build and readable mapping. APKLint's Crash / ANR Analyzer can help explain a trace, but it cannot confirm Firebase delivery. Retain a test report identifier and the exact build that produced it, then remove any deliberately crashing test interface before public release.
Create one traceable test event
Use a nonproduction build with a test-only action that causes a recognizable fatal exception. Record the build identifier and approximate test time, trigger the action once, then restart the app under the official test conditions. Keep the device connected through an allowed network path. Do not repeatedly crash a real user's session while trying to make a dashboard update.
Check the configured Firebase app and the dashboard's time, version and event-category filters. A test event sent to staging will remain absent from the production view regardless of how long you wait. Similarly, an exception explicitly recorded as non-fatal belongs to a different observation than process termination. Describe the event you actually generated. Preserve the installation and its local state between the crash and restart; clearing app storage or reinstalling during that interval can discard evidence needed by the delivery test.
Find the first stage lacking evidence
Inspect safe diagnostic logs for initialization, collection state and upload status. If collection is disabled by the application's consent logic, test the permitted path deliberately instead of permanently changing the default. If the SDK reports a network failure, investigate the actual connection and approved proxy configuration. If it reports successful upload, focus on destination, filtering and documented processing behavior before rebuilding the entire integration.
Compare one working development build with the failing release candidate. Record differences in application ID, Firebase configuration, signing/distribution path, optimization and collection settings. Change one relevant cause and repeat the same controlled event. Broad dependency changes can make the symptom disappear while leaving the original configuration mistake unidentified.
When the event finally appears, retain its report identifier and the associated artifact record, then verify readable frames using the correct mapping or symbols. A delivered but unreadable event is progress, not completion of the diagnostic setup. Remove or gate the crash trigger so it cannot be invoked accidentally by public users. Keep reports and logs redacted: user content, tokens and personal identifiers are unnecessary for proving that a synthetic crash traversed the pipeline. The repair evidence should explain which stage failed and what observed change demonstrates that it now works.
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
