Quick answer: ANR stands for Application Not Responding, an Android condition where the app fails to respond to input for too long (around five seconds), because its main thread is blocked. The OS detects the freeze and shows a dialog letting the player force-close the game. ANRs are effectively freezes that the system penalizes.
An ANR is one of the most damaging problems a mobile game can have, and one developers often overlook because it is not technically a crash. The game does not die; it freezes, and Android steps in to tell the player the app is not responding and offer to kill it. To the player, a frozen game that the OS flags is as bad as a crash, often worse, and on Android it directly hurts your store standing. Understanding ANRs is essential for mobile stability.
What Causes an ANR
Android (and similar logic on other platforms) expects your app's main thread, the one handling UI and input, to stay responsive. If that thread is blocked for too long, around five seconds, the system concludes the app has hung and raises an ANR. The cause is almost always something heavy running on the main thread that should not be: a long file operation, a synchronous network call, a big computation, or a lock waiting on another thread.
The defining characteristic is that the main thread is stuck. Whatever it is doing, loading, computing, waiting, it is not returning to process input, so from the system's and player's perspective the game has frozen. Unlike a crash, the process is still alive; it just cannot respond.
Why ANRs Matter So Much on Mobile
On Android specifically, ANRs are tracked by the Play Store and count against your app's quality metrics, a high ANR rate can hurt your store ranking and visibility, independent of crashes. So ANRs carry a direct business cost beyond the player frustration. And the player experience is severe: a frozen game with a system dialog offering to close it reads as broken, and many players will force-close and not return.
Because ANRs are not crashes, they can hide from crash-focused monitoring. A game with a great crash-free rate can still be plagued by freezes that the developer is not measuring. This is why mobile stability tracking has to include ANRs and hangs, not just hard crashes, the freeze that triggers an ANR hurts you even though no exception was thrown.
Diagnosing and Preventing ANRs
The fix for ANRs is architectural: keep heavy work off the main thread. File I/O, network requests, asset loading, and large computations should run on background threads, leaving the main thread free to stay responsive. Diagnosing which operation is blocking requires capturing the main thread's state at the moment of the freeze, the stack trace of what it was stuck doing.
This is where reporting that captures hangs as well as crashes is valuable. Bugnet's reporting captures the context around a problem, device, logs, and state, so a freeze that triggers an ANR arrives with the information you need to see what the main thread was doing when it locked up. Tracking ANRs alongside crashes gives you the full picture of mobile stability, both the failures that kill the app and the freezes that make the system kill it for you.
An ANR isn't a crash, it's a freeze the OS punishes you for. On mobile, keep heavy work off the main thread or pay for it in rankings.