Repository navigation
Conversation
jpnurmi
requested review from
0xadam-brown,
adinauer,
markushi,
romtsn and
runningcode
as code owners
October 21, 2026 13:08
Contributor
|
📲 Install BuildsAndroid
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
4 tasks
romtsn
reviewed
Oct 29, 2026
romtsn
reviewed
Oct 29, 2026
romtsn
reviewed
Oct 29, 2026
romtsn
requested changes
Oct 29, 2026
Contributor
There was a problem hiding this comment.
Almost looks good to me, nice work! My clanker found a couple of more things that are worth addressing I believe:
And down there there's also a proposal for how we could restructure and simplify the build. Let's discuss it internally if you've got questions!
Member
|
Let's please also extend the docs here: https://docs.sentry.io/platforms/android/configuration/using-ndk/ |
Run the NDK crash daemon from an isolated Android service process so it can release the crashing app, merge the resulting tombstone, and send the enriched envelope before shutdown.
Replace the broad `Throwable` catches in `SentryNdkCrashService` with the exceptions the guarded code can throw, and restore the interrupt flag when the service bind is interrupted.
The service was started with `startService` but never stopped, so its process kept running after `Sentry.close()` or after the app process died. Call `stopSelf` with the start ID that was current when the worker started, so a newer start from a relaunched app is not stopped.
A new service process receives `onBind` before `onStartCommand`, so a worker started from the binder configuration could capture a stale start ID and never stop the service. Tag each start with its shared memory path and stop only when the latest start belongs to the exiting worker.
The marker was written as soon as the merged envelope existed. If the send then failed with a network error, the daemon discarded the envelope and the next launch skipped the tombstone as already reported, so the crash was lost. Write the marker only once the send succeeds.
`startService` throws when the app starts in the background, and the started service stopped about a minute after the app left the foreground, so a later crash found no daemon. Native init then fell back to fork/exec, which cannot exec `libsentry-crash.so` from inside the APK with default packaging, and stalled startup for 10 s. Bind the service with `BIND_AUTO_CREATE` and keep the binding until `SentryNdk.close()`, so the service process keeps the app's importance and is not frozen. Let crash processing continue after `onDestroy`, which runs as soon as a crashed app's binding goes away. Fail NDK init instead of falling back to fork/exec when the service is unavailable: below API 30, without a context, or when binding or configuring fails. Move the inproc `SentryNdkTest` to inproc-only test sources, since outproc init now requires a context.
The crash service picked the native crash exit info closest to the event's timestamp and ignored its pid. In a crash loop, the first poll can run before the current crash has an exit info, and the previous crash's tombstone was merged instead. Skip exit infos of other pids. The worker captures the pid when it starts, so a later configure call cannot change it.
When the app relaunched while the previous daemon was still sending its crash, or before it noticed that its process was gone, the new config was stored but no worker started, and the old worker's cleanup then cleared it. The relaunched app's next crash waited 10 s in the handler and was lost, and its descriptors leaked. Keep the per-app daemon state in a config owned by its worker, and start a worker for each config right away. The old daemon is past crash processing or only waiting for its process to go away, so the two share only process-wide native state such as the logger.
`sentry-android-ndk-outproc` depends on `io.sentry:sentry-native-ndk-outproc`, which is not on Maven Central yet. Build it from the sentry-native feature branch and publish it to Maven Local so the Build job can resolve it. TODO: Revert. This is temporary until sentry-native publishes the artifact.
The tombstone wait and the send shared `shutdownTimeoutMillis`, so a slow tombstone left the send no time at all. Wait for the app's exit info instead. The app exits right after debuggerd writes its tombstone, so the wait ends when the tombstone is there, capped at the 30 s match tolerance. Stop early when the app did not crash natively or the tombstone does not parse. Give the send the full `shutdownTimeoutMillis`, and write the marker for a merged envelope that was sent or kept for the next launch.
Name the shared-memory file after the app pid and delete leftovers whose process no longer runs when the crash service starts. A setup that fails before the daemon attaches would otherwise leave the file behind, while other processes of a multi-process app keep theirs.
With a context, NdkIntegration only looked up `SentryNdk.init(Context, SentryAndroidOptions)`. An older sentry-android-ndk without it disabled NDK. Fall back to `SentryNdk.init(SentryAndroidOptions)` and log a warning.
sentry-native-ndk-outproc no longer reads it, because it always sends native crash envelopes without a minidump. The crash service still gets the tombstone flag through its configure call.
The crash service runs in its own `.sentry_ndk_crash` process, which runs the app's `Application.onCreate`. Apps that call `SentryAndroid.init` there started a second SDK on every launch, with the tombstone, ANR and outbox senders working on the same cache directory as the app process. Return early from `SentryAndroid.init` in that process.
SentryAndroid.init now returns early in the `.sentry_ndk_crash` process, so SentryNdk.init is no longer called there.
Crash service workers for processes that crash close together can finish out of order. A worker that wrote an older tombstone timestamp let `TombstoneIntegration` report the newer crash again on the next launch. Write the marker only when it is newer than the current one, and serialize the workers.
The publish step left its 4 GB Gradle daemon running alongside the 8 GB daemon used by `make preMerge`. The job was killed about 12 minutes into the tests, most likely because the runner ran out of memory.
Without `BIND_IMPORTANT`, a foreground app raises its bound crash service process only to the visible oom adj (100), so lmkd would kill the service before the app under memory pressure. The flag gives the service the app's own adj (0) while the app is on top, without lowering the app's priority the way `BIND_ABOVE_CLIENT` would.
Co-authored-by: Roman Zavarnitsyn <rom4ek93@gmail.com>
jpnurmi
force-pushed
the
jpnurmi/feat/native-android
branch
from
November 3, 2026 11:00
7b356cb to
7d92170
Compare
The outproc module shares NdkScopeObserver with the inproc module, which gained setEnvironment on main (#5772).
When the crash service process died while the app was bound, Android restarted it and called `onServiceConnected` again, but the connection had already closed the descriptors it configured with, so the app ran without a crash daemon. Configure the restarted service with new pipes and the app's shared memory file, then reattach the native crash IPC. Bind again when the binding dies, and log a lost connection at ERROR.
sentry-android-ndk-outproc compiled sentry-android-ndk's sources through extra source folders, shared its namespace and borrowed its ProGuard rules, so the same files belonged to both modules, and the deprecated `BaseExtension` wired it up. Depend on sentry-android-ndk instead, without its `sentry-native-ndk`, and keep only the crash service and the `SentryNdkOutproc` entry point in the `io.sentry.android.ndk.outproc` namespace. `NdkIntegration` now loads that entry point first and falls back to `SentryNdk`.
The native side keeps the envelope for the next launch until it is sent, so the crash is delivered whatever the send result. Write the marker before the send, so that a send that a frozen service finishes late no longer races TombstoneIntegration on the next launch.
`configureDaemon` left the file descriptors of a binder transaction open until garbage collection when it rejected the configuration. Close them before returning.
The crash service polled for a matching tombstone until a wall clock deadline, so a clock step backward delayed the crash send by the size of the step. Use `SystemClock.uptimeMillis()`, which also drives `Thread.sleep()`.
The library loader thread swallowed every `Throwable`, including fatal errors. Catch only the `UnsatisfiedLinkError` of a missing or broken library, which `init()` reports later. `ExceptionUtils.rethrowIfFatal` does not fit, because it rethrows `LinkageError` and would turn a missing library into an app crash.
A missing or broken native library surfaced only in `initCrashDaemon`, after the crash service was bound and the IPC fds were detached. The `UnsatisfiedLinkError` left the service bound with `BIND_IMPORTANT` and the fds open for the app's lifetime. Load the libraries first, so the failure leaves nothing behind.
When the crash service matched the app's native crash exit but could not merge its tombstone, because it stayed unavailable until the deadline or the merge threw, it sent the native event without writing the marker. On the next launch, `TombstoneIntegration` then reported the same crash again as a standalone tombstone event. Write the marker for a matched tombstone, merged or not.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 77bc81d. Configure here.
jpnurmi
added a commit
to getsentry/sentry-docs
that referenced
this pull request
Nov 3, 2026
Document the opt-in out-of-process backend of the NDK integration, which captures native crashes in a separate crash service process and sends them right away. Cover enabling it with and without the Sentry Android Gradle Plugin, the API 30+ requirement, and what the separate process means for the app. Ref: getsentry/sentry-native#1725 Ref: getsentry/sentry-java#6347 Ref: getsentry/sentry-android-gradle-plugin#1474
3 of 6 tasks
romtsn
reviewed
Nov 4, 2026
| uses: gradle/actions/setup-gradle@8da46b539cd8fe6ab27ca75128919a18d757604c # v6.4.1 | ||
|
|
||
| # TODO: remove once sentry-native publishes sentry-native-ndk-outproc | ||
| - name: Checkout sentry-native |
Contributor
There was a problem hiding this comment.
don't forget to drop this :)
The `ndkBackend` option of the Gradle plugin is parked for now, so the outproc package is selected through its dependency only.
2 of 9 tasks
The NDK now backs the crash IPC with a memfd instead of a file, because the sparse file could raise `SIGBUS` on a full disk. Create the memfd before configuring the service and send it over Binder, which reattaching already does. This removes the file path from the protocol, and the cleanup of stale files.
This branch has not been deployed
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.
📜 Description
Adds
sentry-android-ndk-outprocas an experimental, opt-in alternative tosentry-android-ndk. The existing inproc integration remains the default.The new package starts the native crash daemon in a separate, non-exported Android service process on API 30+. When tombstone reporting is enabled on API 31+, the service enriches the native crash event with a matching tombstone before sending it. If enrichment is unavailable, it sends the native crash envelope without it.
NdkIntegrationnow passes the application context needed to configure the service, while retaining the existing initialization entry point. Both NDK variants share scope synchronization and debug-image support, and are declared mutually exclusive through Gradle capabilities.💡 Motivation and Context
Provides the Android SDK integration for the native backend:
It allows native crash processing and tombstone enrichment to run outside the main application process. Fully enriched crash reports are delivered at the time of the crash.
See also:
💚 How did you test it?
Covered by the Android E2E tests in getsentry/sentry-native#1725, which build this Java feature branch and verify crash delivery to Sentry with tombstone enrichment enabled and disabled, without restarting the app.
📝 Checklist
sendDefaultPIIis enabled.🔮 Next steps
Publish
sentry-native-ndk-outproc.