ANR for TV
Description
When the UI thread of an Android app is blocked for too long, an “Application Not Responding” (ANR) error is triggered. If the app is in the foreground, the system displays a dialog to the user, as shown in the figure below.
ANRs are a problem because the app’s main thread, which is responsible for updating the UI, can’t process user input events or draw, causing frustration to the user.
Reasons for ANR
- Main thread Lock : If the main thread is locked for long.
- High CPU Utilization on Main thread : Big operation on Main thread.
- RAM: Low RAM causes the TV to hang and produce ANR
Android vitals
Android vitals can help you monitor and improve your app’s ANR rate. Android vitals measures several ANR rates:
- ANR rate: The percentage of your daily active users who experienced any type of ANR.
- User-perceived ANR rate: The percentage of your daily active users who experienced at least one user-perceived ANR. Currently, only ANRs of this type
Input dispatching timed out
are considered user-perceived. - Multiple ANR rate: The percentage of your daily active users who experienced at least two ANRs.
A daily active user is a unique user who uses your app daily on a single device, potentially over multiple sessions. If a user uses your app on more than one device in a single day, each device will contribute to the number of active users for that day. If multiple users use the same device daily, this is counted as one active user.
User-perceived ANR rate is a core vital meaning that it affects the discoverability of your app on Google Play. It is important because the ANRs it counts always occur when the user is engaged with the app, causing the most disruption.
Play has defined two bad behavior thresholds on this metric:
- Overall bad behavior threshold: At least 0.47% of daily active users experience a user-perceived ANR, across all device models.
- Per-device bad behavior threshold: At least 8% of daily users experience a user-perceived ANR, for a single-device model.
If your app exceeds the overall bad behavior threshold, it will likely be less discoverable on all devices. If your app exceeds the per-device bad behavior threshold on some devices, it is likely to be less discoverable on those devices, and a warning may be shown on your store listing.
Diagnose ANRs
There are some common patterns to look for when diagnosing ANRs:
- The app is doing slow operations involving I/O on the main thread.
- The app is doing a long calculation on the main thread.
- The main thread is doing a synchronous binder call to another process, and that other process is taking a long time to return.
- The main thread is blocked, waiting for a synchronized block for a long operation on another thread.
- The main thread is in a deadlock with another thread, either in your process or via a binder call. The main thread is not just waiting for a long operation to finish, but is in a deadlock situation.