Configure the build and runtime pieces
The Crashlytics setup guide distinguishes the runtime SDK from the Gradle plugin. The SDK records reports; build integration supplies release-related information such as mappings where applicable.
On 22 September 2026, the release notes list Crashlytics Gradle plugin 3.0.8 and Android SDK 20.1.1. Prefer the documented compatible setup, using the BoM for supported runtime dependencies rather than assuming plugin and SDK versions must match.
Apply configuration to the correct module
Check the application module, selected flavor, Google services configuration and Firebase app ID. A plugin applied only to a root project or a different module may not configure the artifact being distributed.
Keep development and production Firebase destinations explicit. Reports arriving in the wrong project can look like a delivery failure when the real issue is configuration selection.
Prove a controlled crash
Follow the official test-crash procedure. Use a development or internal test build, trigger the crash deliberately, relaunch as instructed and allow report delivery.
Do not ship a public crash button. If collection is controlled by consent or an application setting, test both enabled and disabled behavior instead of bypassing that logic to make the dashboard populate.
Check optimized-release readability
For an R8 release, confirm mapping upload and inspect a test crash from that exact build. Native crashes require the appropriate native integration and symbols; Java mapping does not cover arbitrary native frames.
| Observation | Next check |
|---|---|
| No report | Collection, initialization, network and app identity |
| Report in another app | Variant configuration |
| Obfuscated frames | Matching mapping upload |
| Native addresses only | Native symbol setup |
Keep evidence with the release
Record the test build identifier and report confirmation. APKLint's build and crash tools can support configuration and trace review, but they cannot prove that Firebase received a report. That last check must happen in the intended project's Crashlytics data.
Inspect the tasks generated for the intended variant
After applying the plugin to the Android application module, list that module's tasks and inspect the Crashlytics tasks associated with the distributed release variant. Record the installed plugin version and the Firebase app configuration selected for that variant. A root declaration using apply false makes a plugin version available but does not by itself apply the plugin to the application module.
Use the current setup guide for supported plugin placement and compatibility. Keep a task's actual outcome with the build log: executed, skipped, failed and absent are different states. If a mapping upload is skipped, establish why rather than interpreting the overall build's success message as proof that diagnostics were uploaded.
Follow a controlled release from build to report
For an internal test release, save the package ID, version code, source commit and artifact digest. Archive the mapping generated by that exact optimized build and preserve the relevant upload result. Install the artifact through the intended test distribution, trigger a recognizable synthetic crash and relaunch according to the test procedure. Then associate the observed report with the saved release record.
If the report appears under another Firebase app, inspect variant configuration before changing retry settings. If it appears correctly but remains obfuscated, compare the mapping/build association and upload outcome. If no event appears, investigate collection and runtime delivery separately. These branches keep a Gradle integration investigation focused on the stage that actually failed.
Test CI from its normal credential and network environment without exposing secrets in verbose logs. A developer machine may have local state that makes an upload work while the shared pipeline fails. Keep any source-context or native-symbol upload choices explicit because they involve different artifacts and disclosure boundaries. After fixing the integration, rerun the same release path and retain the evidence. Do not disable the failed task just to produce a green build unless the release decision explicitly accepts the resulting diagnostic limitation; a package that installs successfully can still be operationally difficult to support.
Sources and further reading
- Firebase: Get started with Crashlytics on Android
- Firebase: Test your Crashlytics implementation
- Firebase: Android SDK release notes
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
