How do I fix an ANR in my Android game?

Keep the main thread free to respond by moving long or blocking work off it: run heavy computation, file and network I/O, and asset loading in the background so the main thread stays responsive within Android's limit. Also fix any deadlocks and reduce excessive per-frame work. Since players rarely report ANRs (they just freeze and force-quit), capturing the conditions around unresponsiveness from real sessions helps you locate the blocking operation to offload.

Why are ANRs bad for my game?

Because they make the game freeze and unresponsive, which players experience as the game being broken, often leading them to force-quit or uninstall without reporting why. ANRs can also affect your app's standing on the platform. Like crashes, they happen on players' devices invisibly unless captured, so a widespread ANR can hurt your retention and reputation while staying hidden from you, which is why finding and fixing the blocked-main-thread cause matters.

What Causes ANRs on Android?

Q: What causes ANRs on Android?

ANRs (Application Not Responding) happen when your app's main (UI) thread is blocked for too long, so it can't respond to input within Android's time limit. The causes are long operations on the main thread (heavy computation), slow or blocking I/O (synchronous file, network, or storage access), deadlocks (the main thread waiting on a lock that never frees), synchronous loads of large assets, and doing too much work per frame. Android flags the app as not responding.

Quick answer: ANRs on Android happen when the main (UI) thread is blocked for too long, so the app can't respond to input. The causes are long operations on the main thread, slow I/O, deadlocks, and heavy work that should be backgrounded.

An ANR (Application Not Responding) is Android's way of flagging that your game has become unresponsive, and they can hurt your standing on the platform. They have a specific, fixable cause. Here's what causes ANRs on Android and how to address them.

Why Android Flags an ANR

Android monitors whether your app's main thread (the UI thread) responds to input within a time limit. When the main thread is blocked too long, Android declares an ANR, the app isn't responding. So every ANR comes down to the main thread being blocked, from a few common causes.

Long operations on the main thread, heavy computation or processing that takes too long
Slow or blocking I/O, reading files, accessing the network, or querying storage synchronously on the main thread
Deadlocks, the main thread waiting on a lock or resource that never frees
Synchronous loads, loading large assets or data on the main thread
Doing too much per frame, work that exceeds the frame budget repeatedly until the app stops responding

In each case, the main thread can't process input in time, so Android flags the app as not responding, an ANR.

Why ANRs Matter and Go Unreported

ANRs ruin the player experience, the game freezes, and players often force-quit or uninstall, frequently without reporting why. Like crashes, ANRs that happen on players' devices are invisible to you unless captured, and they can affect your app's standing on the platform.

Bugnet captures crashes and helps surface unresponsiveness from real sessions, so ANR-causing problems don't stay hidden. Since players rarely report an ANR (they just quit), capturing the conditions is how you find what's blocking the main thread.

Fixing ANRs

The fix for ANRs is consistent: keep the main thread free to respond by moving long or blocking work off it, run heavy computation, I/O, and asset loading in the background so the main thread stays responsive. Fixing deadlocks and reducing per-frame work also helps.

Bugnet captures the context around unresponsiveness, helping you locate the blocking operation. So ANRs on Android are caused by the main thread being blocked too long, and the fix is offloading the blocking work so the main thread can always respond to input within Android's limit.

ANRs on Android happen when the main (UI) thread is blocked too long, by long operations, slow I/O, deadlocks, or synchronous loads. The fix is offloading blocking work so the main thread always responds.