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/