[PLAT-8019] Prevent reporting of hangs during background launches #1307
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.
Goal
Prevent reporting of hangs during background launches.
Design
Problem:
-[UIApplication applicationState]
always returnsUIApplicationStateBackground
during the launch ofUIScene
based apps, which means if we rely only on this to detect foreground app launches then we would not report fatal app hangs indidFinishLaunching
.The workaround in #1263 went too far because a hang detected during prewarming or other background launch could be reported as a fatal if iOS subsequently terminated the (backgrounded) apps without warning to reclaim resources (which is quite likely.)
iOS sets a process's
TASK_CATEGORY_POLICY
to different values depending on the type of launch, in order to control its priority for resources such as CPU and disk. Querying this using thetask_policy_get()
API lets us query the category and infer the launch type.TASK_CATEGORY_POLICY definition
Testing on various iOS versions has confirmed that
TASK_FOREGROUND_APPLICATION
is a reliable indicator that the process is a foreground app.Note that this is not a suitable replacement for querying
UIApplicationState
at arbitraty times because the system does not update a task's policy immediately upon state transitions.Changeset
Moves all application foreground state logic into
BSG_KSCrashState
and uses the task's category policy to detect foreground state at initialisation on iOS.Removes the "runloop not yet ticked" workaround from
BSGAppHangDetector
, since that was allowing too many background hangs to be reported as fatal.Removes
isActive
fromBugsnagSystemState
since the removal of[BSG_KSSystemInfo currentAppState]
makes it awkward to capture this data, and it is not actually necessary for the OOM logic - ifisActive
is true, so isisInForeground
.BugsnagSystemState
is now initialised later, since it requiresBSG_KSCrashState
to be ready.Testing
Manually tested launching in foreground, for a background fetch, and prewarming (by rebooting the device.)
All app hang E2E scenarios have passed on CI - https://buildkite.com/bugsnag/bugsnag-cocoa/builds/5050