feat(errortracking): capture native ndk crashes from tombstones - #659
Draft
cat-ph wants to merge 4 commits into
Draft
feat(errortracking): capture native ndk crashes from tombstones#659cat-ph wants to merge 4 commits into
cat-ph wants to merge 4 commits into
Conversation
This was referenced Jul 28, 2026
Contributor
posthog-android Compliance ReportDate: 2026-07-28 17:02:56 UTC ✅ All Tests Passed!46/46 tests passed Capture Tests✅ 29/29 tests passed View Details
Feature_Flags Tests✅ 17/17 tests passed View Details
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
💡 Motivation and Context
Native (NDK) crashes kill the process before any JVM handler runs, so today they are invisible to error tracking. This adds capture for them without shipping any native code in the SDK: on startup, the SDK reads the crash records the OS kept via
ApplicationExitInfo(REASON_CRASH_NATIVE, Android 12+), parses the attached tombstone protobuf, and captures one$exceptionevent per crash using the native stack frame contract PostHog already resolves for the Rust and Go SDKs.Per crash, the event carries:
platform: "native",instruction_addr,image_addr, optional client-resolvedfunction/symbol_addr) in canonical bottom-up order$debug_imagesentries derived from the tombstone's per-frame GNU build ids, so the server matches frames to.sosymbols uploaded withposthog-cli symbol-sets uploadSIGSEGV/SEGV_MAPERR at 0x..., abort message when present),$exception_level: fatal, and the original crash timestampDesign notes:
instruction_addris biased by +1: tombstone pcs are already the correct lookup address (the leaf is the faulting instruction and libunwindstack rewinds caller pcs to the call instruction), so the bias cancels the server's uniform -1 return-address adjustment. This is pinned by a cymbal fixture test on the server side.errorTrackingConfig.captureNativeCrashes, additionally gated on the project's exception autocapture remote toggle. A persisted timestamp watermark prevents duplicate capture across launches, advancing per record so dying mid-scan cannot re-capture./data/are in-app;/system,/apex,/vendorand unknown mappings are not.Known limitations (draft): events are associated with the identity at next launch, not at crash time;
$exception_stepsrecorded in the new process may attach to the previous run's crash; API 31+ only (tombstone protos attach from Android 12).💚 How did you test it?
PostHogAndroidTestconscrypt failures on that box reproduce onmain(arm64 environment issue, no conscrypt aarch64 linux artifact) and are unrelated.📝 Checklist
If releasing new changes
pnpm changesetto generate a changeset file