Crashlytics Not Reporting Crashes: Diagnose the Delivery Path

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

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.