fix: pause app hang detection when going on the background

[bitsandfoxes]

Relies on getsentry/sentry-native#1928

To prevent false positives like reporting an app hang event because the game went on the background.

[cursor]

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 1e1ac54. Configure here.}

[sentry]

Bug: A data race exists on AppHangHeartbeatFunc and AppHangPauseFunc as they are accessed from multiple threads without atomic or mutex protection, leading to undefined behavior.
_{Severity: MEDIUM}

Suggested Fix

Protect the reads and writes to AppHangHeartbeatFunc and AppHangPauseFunc within ResolveAppHangFunctions(). This can be achieved by using a FCriticalSection to lock around the check and subsequent dlsym calls. Alternatively, convert the function pointers to TAtomic<TFunction<...>> or a similar atomic type.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: plugin-dev/Source/Sentry/Private/Android/AndroidSentrySubsystem.cpp#L624-L656

Potential issue: A data race exists on the non-atomic function pointers
`AppHangHeartbeatFunc` and `AppHangPauseFunc`. The function `ResolveAppHangFunctions()`,
which reads and writes these pointers, is called from the game thread via
`PumpAppHangHeartbeat()` and potentially from a different thread via
`PauseAppHangTracking()`. This concurrent access without a mutex or atomic operations is
undefined behavior. The initial check `if (AppHangHeartbeatFunc && AppHangPauseFunc)` is
a racy read. While the practical impact might be limited to redundant `dlsym` calls on
some hardware, a torn pointer read could theoretically lead to a crash when the garbage
pointer is called.

[tustanivsky]

Here are several findings about Unreal's app‑lifecycle delegates that are worth considering here:

1. On Android, the ApplicationWillDeactivateDelegate/ApplicationHasReactivatedDelegate and ApplicationWillEnterBackgroundDelegate/ApplicationHasEnteredForegroundDelegate delegate pairs are always broadcast together back‑to‑back in the same suspend/resume callback so subscribing to both isn't necessary.

2. On desktop (Win/Linux/Mac), none of these delegates are broadcast by the engine so the subscriptions are effectively no‑ops there.

3. On consoles, behavior may vary per platform:

• PS5 - only ApplicationWillDeactivateDelegate/ApplicationHasReactivatedDelegate are used for app‑state changes (WillEnterBackground is never broadcast).
• Xbox - both pairs fire, but for different scenarios: deactivate/reactivate maps to constrained (lost focus but still ticking, just throttled, the main false‑positive case), while background/foreground maps to suspend/resume. Subscribing to both makes sense here.
• Switch - both pairs are used, but the engine restores state based only on the immediately previous focus state, so on resume it fires only the single matching counterpart which means some sequences can leave one delegate unpaired. For example,
  overlay appears → app deactivated (WillDeactivate) → user presses Home → app backgrounded (WillEnterBackground) → user reopens → Unreal sees previous state = background and fires only ApplicationHasEnteredForegroundDelegate.
  The earlier deactivation is never matched by HasReactivated, so the corresponding flag stays "paused" and hang tracking may not resume for the rest of the session.

Given these differences, I'd suggest reshaping the generic‑platform implementation so that downstream plugin extensions can control which delegates they subscribe to and how they map to pause/resume, e.g. a virtual ConfigureAppHangTracking() where console extensions override it as needed (PS5 → single pair; Xbox → both pairs, Switch → custom handling that avoids the stuck‑flag case).

Also, for Xbox and Switch we should probably validate this behavior on actual devkits and see whether hiding/resuming the app actually produces false‑positive hangs since it's something hard to confirm only by looking into engine sources.

[tustanivsky]

Superseded by #1523