Support ANRWatchdog (ANRv1) alongside ApplicationExitInfo (ANRv2) for ANR detection

[romtsn]

Description

Problem

New ANR implementation is based on the official Android's ApplicationExitInfo API. This implementation completely replaces the old one (based on a watchdog) on devices running Android 11 and above.

While the new implementation is more precise and allows us to be on-par with Google Play Console/Firebase Crashlytics with regards to ANR rate and also capture a thread dump with some additional information like held locks, the old approach also has some advantages. For example, it can capture screenshots at the moment of ANR or send auxiliary information which is only available at the moment of ANR happening, such as battery level or currently available memory. It can also show us potentially slow code running on the main thread, even if an ANR hasn't been triggered by the system.

Moreover, we can have a linked transaction with the corresponding profile to investigate the issue for ANRv1. We don't know yet, if it's possible to do for ANRv2 (most likely not for profiles).

Thus we're creating this issue to collect feedback if we have to provide support for both approaches working alongside each other on Android 11 and above.

Proposal

It is, however, unclear how exactly we should approach this. We could keep capturing ANR events for both approaches, but then it will mess up the ANR rate and we'll diverge with Google Play Console again. We could also keep the new approach for only tracking ANR rate, and the old approach for capturing ANR events; but again, the rate and the corresponding number of events will diverge, because the watchdog approach captures many false positives.

Perhaps, we should turn the watchdog approach into something like capturing App Hangs without affecting ANR events or rate for Android 11 and above. We could decrease the default timeout to something like 2s (to align with iOS), and then we'd show customers where they have slow code with all of the information we have (screenshots, memory contexts, transaction and profiles). The downside is that it can increase a number of reported events significantly and exceed users quota.

Worth noting, that for older API levels (Android <11), the watchdog approach should still work the same way (capturing ANR events + affecting ANR rate).

---

Please, upvote this issue and share your use-case/ideas on how we should approach this, if you're interested in the above proposal. Thank you!

[wangpeiming110]

It seems that if user click the “wait” button in the system ANR dialog and then the App exit for another reason, then the Sentry's ANRv2 will ignore this ANR case, while the old ANRv1 will not ignore. Am I right?

If so I upvote for both approaches working alongside each other on Android 11 and above, because I think the ANR should also be collected even when the "wait" button is clicked.

[romtsn]

Yes, ANRv2 only reports ANRs that resulted in application exit. In this case it will be a false positive if the user clicked "Wait" and the app unhung, because this one does not contribute to ANR rate. But I agree, this will be still useful to know about, that's where turning ANRv1 into AppHang detector makes the most sense.