You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
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!
The text was updated successfully, but these errors were encountered: