---
title: "Debugging native crashes on Android just got easier with Crashlytics"
description: "Debugging native crashes on Android just got easier with Crashlytics"
published: "2025-11-14"
last_updated: "2025-11-14"
authors:
  - "Matthew Robertson (Software Engineer)"
categories:
  - "Crashlytics"
  - "Android"
  - "App Quality"
  - "C++"
canonical_url: "https://firebase.blog/posts/2025/11/crashlytics-android-ndk-tombstones"
---

# Debugging native crashes on Android just got easier with Crashlytics

*Published November 14, 2025 by Matthew Robertson (Software Engineer)*

---
Debugging native crashes on Android is easy! Just kidding, it's hard. A large
part of what makes it hard is the lack of symbolicated system frames, especially
in the more complicated cases. Luckily, Crashlytics has made improvements to
provide a richer view of both system and application frames to make debugging
these situations easier.

If you've spent enough time in native Android, you most likely have encountered
stack traces that include unsymbolicated system frames from libraries such as
`libc.so` and `libart.so`. 

![ ](https://firebasestorage.googleapis.com/v0/b/first-class-blog.appspot.com/o/posts%2F2025-11-13-crashlytics-1_1600x800.webp?alt=media&token=dae43c0b-5529-4545-9135-c0668dd0acca)

While Crashlytics gives you a high fidelity view of application frames, the
system frames show up as raw pc addresses not suitable for human consumption.

Crashlytics achieves high fidelity within app frames by collecting native crash
data as _minidumps_. A minidump is a lightweight snapshot of the app state that
the Crashlytics NDK SDK captures using the
[Crashpad](https://crashpad.chromium.org/) client. The minidumps are processed
and unwound on the Firebase backend and your app's frames are symbolicated using
the symbols files that were uploaded using the Crashlytics Gradle plugin at
build time.

Unfortunately, the uploaded symbol files only contain the application symbols.
This creates a critical problem: we don't have symbols for every version of
every system library used across all Android devices. To symbolicate these
frames perfectly would require a massive, comprehensive repository containing
every version of every system library from every device build. The combination
of all versions is too intractable to support.

We have taken advantage of core Android functionality to fill this gap and make
your life easier - this is where **Tombstones** come in.

![Before: The minidump stack trace, with system symbols missing](https://firebasestorage.googleapis.com/v0/b/first-class-blog.appspot.com/o/posts%2Fcrashlytics_tombstones_before_resized.png?alt=media&token=e52e0594-ea06-4b97-96bc-8229f09db76b)

![After: The tombstone, symbolicated by the Crashlytics pipeline](https://firebasestorage.googleapis.com/v0/b/first-class-blog.appspot.com/o/posts%2Fcrashlytics_tombstones_after_resized.png?alt=media&token=88f9495c-c765-450e-a71d-5191d4432125)

Now, the minidump and tombstone give you a more complete picture of the problem
making it easier to debug and fix native crashes in your Android app.

### What are tombstones

Tombstones are crash reports generated directly on the device when a native
crash occurs. Starting in
[version 18.3.6](https://firebase.google.com/support/release-notes/android#crashlytics_v18-3-6),
the Crashlytics NDK SDK collects tombstones on devices running Android 12 (API
level 31) and higher.

An interesting property of tombstones is that they include on-device
symbolication. Unlike minidumps, which are processed on our backend, tombstones
include symbols for system libraries. Android ships system libraries with
embedded debug symbols that facilitate symbolication right out of the box. 

Symbolicated system frames oftentimes provide the critical insight into the
actual cause of the crash, especially in highly optimized use cases like games
or media apps.

When a native crash occurs, we now collect and process both the minidump and the
tombstone. Crashlytics will display both stack trace views side-by-side on the
Crashlytics dashboard, and export both views to BigQuery (if enabled).

![ ](https://firebasestorage.googleapis.com/v0/b/first-class-blog.appspot.com/o/posts%2F2025-11-13-crashlytics-4_1600x800.webp?alt=media&token=a7857e65-413a-40c7-9e7a-1101f4698a86)

Tombstones come with a tradeoff in that they don't contain app symbols. In the
majority of cases, release builds have symbols stripped out of the binary. In
cases of highly optimized code, tombstones lack the necessary fidelity within
app frames that enable effective debugging of the problem.

![Snippet of a raw tombstone showing symbolicated system frames, but lack of application symbols and missing application frames likely due to inlining)](https://firebasestorage.googleapis.com/v0/b/first-class-blog.appspot.com/o/posts%2F2025-11-14-crashlytics-5_1600x800.webp?alt=media&token=b54cac70-f5f7-4b60-8c61-794b85ca3ae8)

### How we made tombstones more readable

Before this update, getting a complete picture of a native crash meant extra
work. You may have needed to couple the Crashlytics console with the raw
tombstones using the
[`ApplicationExitInfo#getTraceInputStream()`](https://developer.android.com/reference/android/app/ApplicationExitInfo#getTraceInputStream())
API to get a full view of the crash context. Or, if you are an advanced user,
symbolicate it yourself to get app frames. While possible, this is not the best
workflow. Crashlytics now just does this for you for free!

Instead of the Crashlytics dashboard showing you a raw tombstone with
application symbols missing, we run it through our symbolication pipeline (the
same one we use for minidumps) to fill in your app frames with symbols, file
names, and line numbers. The result is a rich, symbolicated stack trace, both
for your app code and system libraries.

![Example of new symbolicated tombstone (processed by the Crashlytics pipeline)](https://firebasestorage.googleapis.com/v0/b/first-class-blog.appspot.com/o/posts%2F2025-11-14-crashlytics-6.png?alt=media&token=7ac101d6-bc38-4874-93e7-a90730672bc4)

Harness the power of both minidumps and tombstones for comprehensive crash
analysis. While minidumps often provide clearer stack traces, tombstones are
crucial for uncovering deeper system-level issues, ensuring you never miss a
critical detail.

### What's next

We're continuing to invest in improving the quality of service of native crash
reporting in Crashlytics to give you the best possible experience. Stay tuned
for more improvements, and
[let us know](https://firebase.uservoice.com/forums/948424-general?category_id=464887)
what you want to see next!