Consider using a more accurate ANR tracking implementation

[vibin]

Hi, i'm currently evaluating Bugsnag and Sentry and one of the differences i've observed in the SDK is that Bugsnag uses a SIGQUIT signal handler to get called by OS when ANR occurs, as opposed to Sentry, which uses the watchdog approach.

I have used https://github.com/SalomonBrys/ANR-WatchDog in production before and while it's a useful library, I saw that it reports many false-positives compared to Play Console, especially in case of ANRs in BroadcastReceivers.

SIGQUIT approach is also not perfect, though. It doesn't track background ANRs: bugsnag/bugsnag-android#1377

There's a third approach to track ANRs and Crashlytics' Alpha version seems to be using it (tracks both foreground and background ANRs): getHistoricalProcessExitReasons on Android 11 and above only, sadly.

Any thoughts?

[bruno-garcia]

Thanks you for bringing this up. It makes sense and perhaps we should consider an approach for Android 11+ only and keep the current as-is. Additionally, there's the possibility of relying on SIGQUIT through our NDK support which will also require some discussions internally.

[marandaneto]

I've tested the 3rd option 2y ago and it worked really well, indeed, https://github.com/marandaneto/android-exit-reasons-api-sample
the approach we could take is, enable the watchdog when Android <= 10 and use the new API when Android >= 11.

the new API returns a InputStream tho, so it requires us converting this info into a SentryEvent https://developer.android.com/reference/kotlin/android/app/ApplicationExitInfo#gettraceinputstream

[marandaneto]

sample_anr.txt

[marandaneto]

Let's use the new API for Android >= 11 and keep the watch dog approach for back compatibility.

[marandaneto]

https://www.amanjeet.me/demystifying-the-anrs-puzzle/

[marandaneto]

Update the docs after doing this, the docs should state the behavior for older and newer OS versions.

[marandaneto]

For reference, that's how Android itself does it https://cs.android.com/android/platform/superproject/+/master:frameworks/base/services/core/java/com/android/server/am/AnrHelper.java
I suspect we can parse the output of the App Exit Info with https://cs.android.com/android/platform/superproject/+/master:development/tools/bugreport/src/com/android/bugreport/stacks/ThreadSnapshotParser.java and friends.

Check if this https://developer.android.com/reference/android/os/health/ProcessHealthStats helps with something as well

[marandaneto]

The current ANRWatchDog approach actually could be improved using the setMessageLogging method, right now we keep posting something to the main thread so we can check the delay of being executed.
setMessageLogging is a callback that calls the Printer interface before and after something is executed in the looper.

Example:

2023-04-17 11:20:16.125 27155-27155 Sentry io.sentry.samples.android D Printer ANR: >>>>> Dispatching to Handler (android.view.ViewRootImpl$ViewRootHandler) {f45b933} android.graphics.HardwareRendererObserver$$ExternalSyntheticLambda0@846f00e: 0
2023-04-17 11:20:16.125 27155-27155 Sentry io.sentry.samples.android D Printer ANR: <<<<< Finished to Handler (android.view.ViewRootImpl$ViewRootHandler) {f45b933} android.graphics.HardwareRendererObserver$$ExternalSyntheticLambda0@846f00e
2023-04-17 11:20:16.133 27155-27155 Sentry io.sentry.samples.android D Printer ANR: >>>>> Dispatching to Handler (android.view.Choreographer$FrameHandler) {b5bbc0} android.view.Choreographer$FrameDisplayEventReceiver@315a0f9: 0
2023-04-17 11:20:16.135 27155-27155 Sentry io.sentry.samples.android D Printer ANR: <<<<< Finished to Handler (android.view.Choreographer$FrameHandler) {b5bbc0} android.view.Choreographer$FrameDisplayEventReceiver@315a0f9

We could have a SentryPrinter interface that keeps track of how long it takes to execute each task and raise an issue if necessary individually, the stack trace will be more accurate most likely as well.
This approach has a side effect tho, in case you execute plenty of small tasks, one after the other, all in the main thread, we'd need to find a way to sum them up, because the main thread is still somehow blocked.