Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
romtsn opened this issue May 4, 2023 · 0 comments

Comments

@romtsn
Copy link
Member

romtsn commented May 4, 2023

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!

@getsentry getsentry locked and limited conversation to collaborators May 17, 2023
@romtsn romtsn converted this issue into discussion #2716 May 17, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
Archived in project
Development

No branches or pull requests

1 participant