firebase / firebase/firebase-android-sdk

[Crashlytics] Native stack not symbolicated for armeabi-v7a builds on 64-bit devices running in compatibility mode

Open
#8,325 3 comments 0 reactions 1 assignee Claimed by @mrober View on GitHub
api: crashlytics
Dominant language
Java
Stars
2.6k
Forks
710
Avg merge
2d 23h
Merged PRs (30d)
34

Description

### Describe your environment

- **Firebase Component:** Crashlytics
- **SDK Version:** `com.google.firebase:firebase-crashlytics-ndk:19.2.1`
- **Gradle Plugin Version:** `com.google.firebase:firebase-crashlytics-gradle:2.9.9`
- **Firebase CLI Version (for manual upload): 15.21.0**
- **Android Gradle Plugin (AGP): 8.10.1**
- **NDK Version: 29.0.14206865**
- **Device: Samsung SM-S911B (Android 16)**

### Describe the problem

Native crash stacks are not symbolicated in the Firebase Crashlytics console for `armeabi-v7a` (32-bit) builds when running on a 64-bit device in compatibility mode. The same build works correctly on a native 64-bit (`arm64-v8a`) APK on the same device.

#### Steps to reproduce:

1. Build an APK containing native libraries **only** for the `armeabi-v7a` ABI.
2. Install and run the APK on a 64-bit ARM device (e.g., Samsung SM-S911B).
3. Trigger a native crash (e.g., via `SIGABRT` or a deliberate null pointer dereference).
4. Observe the crash report in the Firebase Crashlytics console.

**Expected result:**
The crash report is successfully received, and the native stack trace is fully symbolicated (showing function names and line numbers).

**Actual result:**
The crash report is successfully received, but the native stack trace is **not symbolicated**. Only memory addresses or raw function offsets are shown.

#### Additional investigation and findings

1. **The symbols themselves are delivered.**
* Repeated manual uploading of symbols using the Firebase CLI (`firebase crashlytics:symbols:upload`) did not resolve the issue, ruling out a CI/upload problem.

2. **The minidump is valid and can be symbolicated locally.**
* A raw minidump file (from the device path `.../native/pending`) from a crash on the `armeabi-v7a` build was extracted and processed locally using `minidump_stackwalk` with the corresponding symbol files.
* The local symbolication was **successful**, producing a fully readable stack trace.

3. **The issue is specific to `armeabi-v7a` on a 64-bit host.**
* The same device (SM-S911B) running the **`arm64-v8a`** version of the same APK produces a symbolicated stack trace in the Crashlytics console without any issues.
[arm-v7a stacktrace from Crashlytics](https://github.com/user-attachments/files/29133980/not_symbolicated.txt)
[arm64-v8a stacktrace from Crashlytics](https://github.com/user-attachments/files/29133981/symbolicated.txt)

#### Key Question

The local symbolication test confirms that the minidump and symbols are valid. The problem therefore appears to be specific to the backend processing of minidumps generated from a 32-bit (`armeabi-v7a`) process running on a 64-bit device. Is this a known limitation or bug?

#### Suggested hypothesis

The local symbolication test confirms that the minidump and symbols are valid. The problem therefore appears to be specific to the backend processing of minidumps generated from a 32-bit (`armeabi-v7a`) process running on a 64-bit device.

While the issue is unlikely to be related to 16KB page alignment (as this is not a strict requirement for `armeabi-v7a`), it may be caused by differences in how the 32-bit unwind data is interpreted by the backend, or a bug in the backend's minidump processing for this specific scenario.

#### P.S

We are considering updating the Firebase Gradle plugin to `3.x.x` and the Firebase BoM to `34.x.x`, but would appreciate guidance before doing so.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.