Repository navigation
fix: app hang detection on android when uaal - #2920
Merged
Merged
Conversation
bitsandfoxes
requested review from
a team,
jpnurmi,
limbonaut and
tustanivsky
October 30, 2026 09:54
mujacica
approved these changes
Oct 30, 2026
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.
Follow-up to #2895. On Android with Unity as a Library, game hangs were never detected when the game attaches to the app's sentry-android (Unity in the app's main process).
sentry-native's app hang detection only watches a thread that sends heartbeats (
sentry_app_hang_heartbeat), and it does nothing until one arrives. sentry-android only passesenableNdkAppHangTrackingon to native init and never sends heartbeats itself; downstream SDKs are expected to. When attached, the game skipped its heartbeat, so detection was never armed. The app's JVM ANR detection watches the UI thread, not the game thread.Now, when attached, the game sends the heartbeat if the app's SDK has
isEnableNdk()andisEnableNdkAppHangTracking()on. The app's options decide, as for all native options when attached. Unity'sEnableAppHangTracking/AppHangTimeoutcan't apply there, because the app'ssentry_initalready set up the watchdog. As before, the C# watchdog is removed only when the heartbeat runs.Unload/reload false app hang (both Android UaaL layouts)
Testing this turned up a false app hang after the app unloads and reloads the game, also in the
:Unitylayout. On reload Unity restartsTime.frameCountandTime.realtimeSinceStartup. The heartbeat coroutine was suspended across the unload, so it only resumed once the new clock caught up with the old one: on the device, ~27 s later, about as long as the game had run. Meanwhile the beat on resume had already re-armed detection, so a hang was reported ~5 s after the reload. The heartbeat coroutine now restarts on resume.Verified on a Pixel 6 (Android 16, local UaaL host on sentry-android 8.59.0 with
setEnableNdkAppHangTracking(true)):UnityApplication.Unload(), reload, then a hangBefore this change, a 10 s hang in the main-process layout produced no event.
#skip-changelog: #2895 isn't released yet.
🤖 Generated with Claude Code