If you're shipping native C++ on Android through the NDK, the crash story is different from anything in the managed Java or Kotlin world. A crash in your native layer doesn't give you a tidy Java stack trace. It gives you a native signal and a minidump, and turning that into something readable means dealing with per-architecture symbols, the NDK's build quirks, and the fact that Android will quietly ignore your crash handler if you ship it wrong.
BugSplat handles the native side properly. Crashes in your C++ code get captured, uploaded, and symbolicated into call stacks with function names and line numbers, grouped and versioned in one dashboard, the same way they would be on desktop.
The Android-specific sharp edges
A few things about Android crash reporting that catch people out, all worth knowing before you start.
You build Crashpad once per ABI you support, arm, arm64, x86, x64. Each architecture gets its own set of Crashpad libraries, and you link the right ones per ABI in your CMakeLists.txt. This is the most fiddly part, and it's why our docs ship a reference my-android-crasher project with pre-built libraries: you adapt working setup instead of fighting the build from zero.
The one that surprises everyone: you have to rename crashpad_handler to libcrashpad_handler.so. If you don't, the APK bundler ignores it, because it only packages files matching the library naming convention, and your crash handler silently never ships. Your app builds fine, runs fine, and reports nothing. Rename it and the handler gets packaged and made available at runtime.
Symbols are a two-machine job on Android. You generate .sym files with dump_syms from your .so files, but dump_syms for Android needs to run on Linux. You can use a Linux machine, or a compatible emulator on macOS or Windows; our AndroidCrasher repo has examples for both. And a Windows note worth saving someone an afternoon: symupload won't upload Android .sym files from Windows, so do the upload from macOS or Linux.
Why bother with all this?
Because native Android crashes are exactly the ones you can't reproduce. Different chipset, different driver, different OEM skin, a device you've never held. The user uninstalls and leaves a one-star review, and you never find out why. Getting native crash reporting wired up is how you turn "the app crashes on some Android phones" into a specific line of code on a specific build.
It's setup-heavy up front, no point pretending otherwise. But it's a one-time cost paid by one person, and after that the whole team can read native Android crashes without owning an NDK toolchain.
Full Android NDK and Crashpad setup is in the docs: docs.bugsplat.com
Want to see native Android crashes symbolicated? Start a free trial and send your first one.