TL;DR
- Android error tracking has six requirements that cross platform posts ignore: ProGuard/R8 mapping upload, ANR monitoring, NDK (native C/C++) crash support, Play Console integration, Gradle plugin quality, and OEM fragmentation handling.
- Crashlytics handles five of six out of box with zero configuration beyond adding Gradle plugin. The gap is two way Jira sync and ownership based ticket routing.
- Sentry handles all six but requires sentry-cli for mapping upload instead of a Gradle plugin (Gradle plugin exists but is less mature than Crashlytics'). The advantage is two way Jira/Linear sync, suspect commits, and ownership routing.
- Google Play Console's Android Vitals is not a replacement for an error tracking SDK. It shows crash free and ANR free rates but has a 24-48 hour data delay and no stack trace grouping or alerting.
Where Drizz fits:
- Drizz runs E2E tests on real Android devices in CI, catching crash inducing regressions before build ships to production.
- The Jira/Linear integration creates tickets from failed test runs with device model, OS version, video recording, and PDF report prefilled.
- Drizz doesn't replace production crash monitoring. It's upstream gate that reduces volume Crashlytics and Sentry have to handle.
Android specific comparison
What does Firebase Crashlytics handle for Android?
Crashlytics is path of least resistance for Android crash reporting. Here's what it covers for six Android specific concerns:
- ProGuard/R8: Gradle plugin (com.google.firebase:firebase-crashlytics-gradle) auto uploads mapping files on every release build with no CI scripting or manual upload step required
- ANR monitoring: automatic on Crashlytics 18.3.0+, captures frozen thread's stack trace when main thread is blocked for more than 5 seconds, groups by blocking call
- NDK crashes: requires adding firebase-crashlytics-ndk dependency, then captures SIGSEGV and SIGABRT from C/C++ code and symbolicates using .so files uploaded via uploadCrashlyticsSymbolFileRelease Gradle task
- Play Console: native integration, Crashlytics data feeds directly into Firebase console and links to your Play Console app
- Jira: one way only (creates Bug type tickets), no custom field mapping, no ownership routing, no Linear support
- Price: $0, no event limits, no seat limits, no paid tiers
OEM fragmentation is where Crashlytics shows its limitation. The cluster key groups crashes by stack trace similarity, but Samsung, Xiaomi, OnePlus, and Pixel sometimes produce different stack signatures for same root cause.
A thread on r/androiddev about 22K crashes concentrated on a single device model illustrates problem: OEMs inject custom framework classes into view hierarchy (like Samsung's custom window manager), altering stack trace lines enough that Crashlytics creates separate groups for what is one bug. Teams use setCustomKey to tag crashes with Build.BRAND, Build.MODEL, and Build.VERSION.SECURITY_PATCH to filter OEM specific variants in dashboard.
For teams that need automated triage, one way Jira limitation is gap that pushes them to Sentry or a webhook based workaround via Cloud Functions.
What does Sentry handle for Android?
Sentry is strongest option for Android teams that need automated triage, cross platform consistency, or Kotlin Multiplatform support. The Android SDK captures Java/Kotlin exceptions, ANRs, and NDK crashes natively.
- ProGuard/R8: upload via sentry-cli releases files upload-sourcemaps in CI or via Sentry Gradle Plugin (io.sentry.android.gradle). The Gradle plugin auto uploads on release builds but is less battle tested than Crashlytics'; teams with flavor based or multi module builds sometimes fall back to sentry-cli for reliability
- ANR monitoring: Android SDK 6.0+ captures frozen main thread stack trace plus breadcrumbs leading up to freeze, groups ANRs separately from crashes for independent ANR free rate tracking
- NDK crashes: handled by sentry-android-ndk, symbolicates using debug symbols uploaded via sentry-cli. Requires uploading native .so debug files separately from ProGuard mappings, adding a CI step
- OEM fragmentation: configurable fingerprinting rules let you group crashes by exception type + top 3 non vendor frames instead of full stack, which merges OEM variant stack traces that Crashlytics would split into separate groups
- Jira: two way sync with custom field mapping, ownership routing via codeowners, suspect commits linking crashes to PR that introduced them, auto assignment to developer who owns file. Linear, GitHub Issues, and Asana also supported
- Price: free tier at 5K errors/month (1 seat, 30 day retention), Team at $26/seat/month (50K errors, 90 day retention)
The Kotlin Multiplatform SDK (sentry-kotlin-multiplatform) covers Android, iOS, JVM, and native targets from a single dependency. Crash reporting is configured once in shared module rather than separately per platform.
A developer on r/androiddev building a unified crash reporter for KMP found that Crashlytics' stack traces from commonMain code appear garbled on non Android targets. Sentry's KMP SDK translates native Apple NSException events and Android JVM crashes into readable line numbers from shared code, with one caveat: SDK embeds a hardcoded version of sentry-cocoa for Apple targets, so version mismatches between Android app module and shared KMP module can cause build failures.
What does Bugsnag handle for Android?
Bugsnag's Android SDK captures Java/Kotlin exceptions and ANRs with auto detection. The stability score is its strongest Android differentiator.
- ProGuard/R8: Gradle plugin (com.bugsnag:bugsnag-android-gradle-plugin) auto uploads mapping files on release builds, similar to Crashlytics
- NDK crashes: available via native plugin, captures SIGSEGV and SIGABRT and symbolicates using uploaded .so files
- Stability score: crash free session percentage per release version, tracked across adoption curve. Maps directly to Google Play's Android Vitals thresholds (crash rate below 1.09%, ANR rate below 0.47%). Configure alerts to fire when a new release drops below your target
- OEM grouping: groups by error class and surrounding context, which handles OEM variants better than Crashlytics' cluster key but without Sentry's configurable fingerprinting. Manual merge in dashboard when automatic grouping splits incorrectly
- Jira: two way with Bugsnag Team ($22/seat/month) and above. Free tier (7,500 events/month, 1 seat, 7 day retention) doesn't include Jira
- No Kotlin Multiplatform SDK, no Linear support, no ownership routing or suspect commits
What does Instabug handle for Android?
Instabug's differentiator for Android is in app feedback loop during beta and early launch. The pre crash recording shows exactly what user did in 60 seconds before crash.
- Shake to report: automatic device metadata capture (OS version, device model, network logs) attached to every user submitted bug report
- Pre crash recording: 60 second screen recording before crash, helping reproduce issues that stack traces alone can't explain
- ProGuard/R8: mapping file upload is manual (via dashboard or API), not handled by a Gradle plugin
- ANR: captures ANRs but grouping and thread level detail is less granular than Crashlytics or Sentry
- NDK crashes: not supported
- Jira: two way via Atlassian Marketplace add on with custom field mapping. No free tier; pricing starts at $100+/month
Developers on r/reactnative caution against making shake to report only trigger mechanism: it conflicts with system shortcuts (like flashlight activation) on some OEM skins and fails to register on others. Include a backup feedback button in app settings alongside shake trigger.
What does Embrace handle for Android?
Embrace is built specifically for mobile observability, not adapted from a web first platform. ANR handling is its strongest Android capability.
- ANR monitoring: groups ANRs by blocking call, shows frozen thread's stack trace alongside user's session timeline, tracks ANR free rate per release. Starts capturing stack traces at 1 second of main thread blocking and continues every 100ms until recovery
- Session level context: every network call, foreground/background transition, memory pressure event, and user action leading up to failure, reconstructed as a structured timeline (not video) without privacy concerns
- ProGuard/R8: handled by Embrace Gradle plugin, auto uploads on release builds
- NDK crashes: included
- Flame graphs: visualize exactly which methods and third party SDKs contributed to blocked thread over time
- Jira: not native, wire via webhooks or a middleware layer. Alerting integrates with PagerDuty and Opsgenie
- Price: free tier at 1M sessions/month, paid plans are contact us
Developers on r/androiddev dealing with ANRs note that Play Console's reports often point to unactionable system cues like nativePollOnce. Embrace fills that gap with continuous 100ms stack sampling, which prevents misleading late stage captures that make most ANR reports useless.
What does Google Play Console's Android Vitals tell you?
Android Vitals is free, requires no SDK, and reports crash free rate, ANR free rate, and startup time for every app on Google Play. But it's a health check, not a debugging tool.
- Thresholds: crash free rate warning at 1.09% (user perceived), ANR free rate warning at 0.47%. Apps below these risk reduced Play Store visibility
- Data delay: 24-48 hours, no real time spike detection
- No stack trace grouping, no deduplication, no alerting, no Jira integration
- Coverage: all users on Google Play including those who opted out of third party analytics, which makes it ground truth for your crash free rate vs SDK reported rates
Use Android Vitals as executive dashboard and your error tracking SDK as engineering debugging tool. If two numbers diverge, your SDK integration is missing crashes (usually NDK crashes or crashes during SDK initialization).
How do you set up ProGuard/R8 mapping upload in CI?
Every Android release build strips class and method names via R8 (or ProGuard on older projects). Without uploading mapping file, your crash reports show obfuscated names like a.b.c() instead of com.myapp.checkout.PaymentProcessor.processCard().
Crashlytics (automatic via Gradle)
Add Firebase Crashlytics Gradle plugin and set firebaseCrashlytics { mappingFileUploadEnabled true } in app level build.gradle. The mapping file uploads automatically on every assembleRelease or bundleRelease task with no CI scripting needed.
Sentry (CLI or Gradle)
Option 1: sentry-cli releases files [version] upload-sourcemaps --strip-prefix in a CI post build step. Option 2: add Sentry Gradle Plugin, which auto uploads on release builds.
The CLI approach is more reliable for complex build configurations (multiple flavors, dynamic feature modules). The Gradle plugin is simpler for single flavor projects.
Bugsnag and Embrace (automatic via Gradle)
Both provide Gradle plugins that auto upload mappings on release builds, similar to Crashlytics. Configuration is a single block in build.gradle.
If your CI pipeline runs assembleRelease or bundleRelease, mapping upload happens as part of build. Verify it works by checking tool's dashboard for mapping file version after first CI build.
A thread on r/androiddev about unreproducible crashes traces root cause to missing mapping files: crash report shows obfuscated frames, developer can't determine which class or method is involved, and crash sits unresolved. Uploading mappings on every release build via Gradle plugin is fix, but teams that build locally and push to Play Console without CI often miss this step.
How does Drizz complement Android error tracking?
Every tool above detects crashes after real users encounter them. Drizz catches crashes before build ships by running E2E functional tests on real Android devices as a CI gate.
When a test encounters an unhandled exception or ANR on a real Samsung, Xiaomi, or Pixel device, Drizz captures device model, OS version, failing step, video recording, and PDF report. The Jira/Linear integration creates a ticket with all context prefilled.
The OEM fragmentation angle matters here: a crash that only reproduces on Xiaomi MIUI or Samsung One UI won't appear in your emulator based CI tests. Drizz runs on real devices from these OEMs, so OEM specific crash surfaces before release.
The honest scope: Drizz catches crashes in flows your tests cover, and crashes in user paths you haven't automated still need Crashlytics or Sentry in production. The mature stack uses both: Drizz as pre release gate and production monitoring as safety net.
Choose by scenario
FAQ
What is best error tracking tool for Android apps?
Firebase Crashlytics is best default: free, auto uploads ProGuard/R8 mappings, monitors ANRs, supports NDK crashes, and integrates natively with Play Console. Sentry is better choice for teams that need two way Jira sync, ownership routing, suspect commits, or Kotlin Multiplatform support.
Does Crashlytics support ANR monitoring on Android?
Yes, Crashlytics 18.3.0+ automatically detects ANRs when main thread is blocked for more than 5 seconds. It groups ANRs by blocking call and reports frozen thread's stack trace.
Which Android error tracking tools support NDK (native) crashes?
Crashlytics (via firebase-crashlytics-ndk), Sentry (via sentry-android-ndk), Bugsnag (via native plugin), and Embrace all support NDK crash capture and symbolication. Instabug does not support NDK crashes.
What crash free rate does Google Play require?
Google Play's Android Vitals flags apps with user perceived crash rates above 1.09% and ANR rates above 0.47%. Apps below these thresholds risk reduced Play Store visibility and a warning in Console.
How do you upload ProGuard/R8 mapping files for crash reporting?
Crashlytics, Bugsnag, and Embrace provide Gradle plugins that auto upload mappings on every release build, while Sentry supports both a Gradle plugin and sentry-cli for manual upload in CI. Add plugin, enable mapping upload in build.gradle, and verify mapping appears in tool's dashboard after first build.
Which error tracking tool handles OEM fragmentation best?
Sentry's configurable fingerprinting rules let you define custom grouping logic for crashes that split across Samsung, Xiaomi, and Pixel stack traces. Crashlytics' cluster key sometimes splits same crash into separate groups that require manual merging.
Does any error tracking tool support Kotlin Multiplatform?
Sentry is only error tracking tool with a dedicated KMP SDK (sentry-kotlin-multiplatform), covering Android, iOS, JVM, and native targets from a single dependency. Other tools require separate SDK integration per platform.
How does pre release testing on real Android devices reduce production crashes?
Running E2E tests on real Samsung, Xiaomi, Pixel, and OnePlus devices in CI catches OEM specific crashes that emulators miss. Crashes caught at this stage never appear in Crashlytics or Sentry because failing build doesn't ship.
