Skip to main content
New Participant
June 17, 2026
Question

Bug: Native crashes not reported as REASON_CRASH_NATIVE in ApplicationExitInfo

  • June 17, 2026
  • 0 replies
  • 80 views

## Issue summary

On Quest 2 (Horizon OS, build `UP1A.231005.007.A1`, Android 14), native app crashes are not surfaced correctly through the `ApplicationExitInfo` API. A full tombstone is written to disk by `debuggerd`, but the framework fails to associate it with the process exit, so `ApplicationExitInfo` reports the wrong reason and no trace. This breaks any crash-reporting SDK that relies on `ApplicationExitInfo.REASON_CRASH_NATIVE` + `getTraceInputStream()` (e.g. the Sentry Android SDK, and AOSP's own documented native-crash flow).

## Observed behavior

`debuggerd` handles the crash and writes a valid tombstone to `/data/tombstones/`:

```
F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 26718 (GameThread), pid 26590
F DEBUG : Diagnostic-Collection-Type: Tombstone Proto
F DEBUG : pid: 26590, tid: 26718, name: GameThread >>> [redacted package name] <
```

`NativeTombstoneManager` then rejects the tombstone because of non-standard filenames:

```
W NativeTombstoneManager: unexpected tombstone name: /data/tombstones/tombstone_09.lock.pb
W NativeTombstoneManager: unexpected tombstone name: /data/tombstones/tombstone_09.pb.lock.pb
```

These `.lock.pb` / `.pb.lock.pb` names do not match AOSP's expected `tombstone_NN[.pb]` pattern. (Horizon OS is creating `tombstone_NN.lock` and `tombstone_NN.pb.lock` lock files in the tombstone directory, which the manager mis-parses.)

The crash is routed to a custom DropBox tag instead of the standard one, and the framework cannot determine the exit reason:

```
I DropBoxManagerService : add tag=SYSTEM_TOMBSTONE_PROTO_WITH_HEADERS
I ActivityTaskManager : captureExitReasonForRootTask: unknown app exit reason, defaulting to crash
```

The resulting `ApplicationExitInfo` record is wrong:

```
dumpsys activity exit-info [redacted package name]: reason=2 (SIGNALED) subreason=0 (UNKNOWN) status=11 ... trace=null
```

It should be `reason=5 (REASON_CRASH_NATIVE)` with a non-null `getTraceInputStream()`.

## Expected behavior

A native crash (SIGSEGV) that produces a tombstone should be recorded in `ApplicationExitInfo` as `REASON_CRASH_NATIVE` with the tombstone available via `getTraceInputStream()`, matching AOSP and stock Android devices.

## Impact

Crash-reporting SDKs cannot retrieve native crash traces on Quest at all. `/data/tombstones/` is system-owned and unreadable from the app sandbox, so `ApplicationExitInfo` is the only sanctioned path, and it returns no usable data. The tombstone data exists on disk but is inaccessible to apps.

**Reproducibility:** 100% on Quest 2 (`UP1A.231005.007.A1`). The same app build on a stock Android phone correctly reports `REASON_CRASH_NATIVE` with a trace.

## Repro steps

1. Install an app that triggers a native SIGSEGV (null deref on a worker thread).

2. Crash it, then relaunch.

3. Run `adb shell dumpsys activity exit-info` → most recent entry is `reason=2 (SIGNALED) trace=null` instead of `reason=5 (CRASH_NATIVE)`.

4. In `adb bugreport`, see the `NativeTombstoneManager: unexpected tombstone name` warnings, while the tombstone file itself exists in `/data/tombstones/`.