Alter In foreground calculation

[fractalwrench]

Goal

We should update the collected value for app.inForeground to use the process importance rather than lifecycle callbacks. This is because if an ANR occurs on application startup, the activity may not enter the STARTED state due to its main thread being blocked, but the app process would still be considered in the foreground.

It's important to note that the inForeground value is still only updated in the NDK layer on initialisation, and when an activity lifecycle event occurs. If we wished to inform the NDK layer of each time the process importance altered, using something like ProcessLifecycleOwner would be a suitable API for doing so. However, this would require a migration to androidx and would add another dependency to our SDK, so has not been implemented in this PR.

Changeset

• Updated SessionTracker to calculate inForeground on initialisation, so that the value is accurate if an ANR occurs immediately on startup
• Created ForegroundDetector class which encapsulates the inForeground checks for process importance
• Updated BlockedThreadDetector to use ForegroundDetector exclusively
• Updated SessionTracker to use ForegroundDetector primarily and also the existing implementation as a secondary source of information

Tests

• Triggered a crash (JVM and native) in the foreground and background, and confirmed that inForeground was the correct value for each.
• Updated existing unit tests
• Ran in foreground mazerunner feature

[kattrali]

Why default rather than falling back to the old implementation?

[fractalwrench]

We made the decision when implementing ANR detection that we should prefer a false positive when we're unable to determine process importance. This is because otherwise the notifier might discard an actual error, since the old implementation can be inaccurate if the main thread is blocked and lifecycle callbacks cannot be invoked.

[kattrali]

I see. To rephrase, there are actually three states for whether the app is in the foreground, yes, no, and unknown. In the unknown case, ANR errors should still be reported, so this uses yes instead of unknown or an implementation based on main thread activity. Is that a fair assessment?

It would be clearer (and delineate responsibilities better) to actually return a value which indicates that the state is currently unknown and let the ANR reporter handle that appropriately, but barring that, the comment should state for future travelers why a potential false positive is preferable and how it affects reporting. "If this was false, some ANRs might get ignored" was not what I expected, and I can see how a future PR to tweak to how this value is computed could unintentionally break this.