What's the difference between a crash and an ANR?

A crash is when the app terminates unexpectedly and closes, usually from a fatal error, leaving a stack trace. An ANR (Application Not Responding) is when the app hangs, becoming unresponsive for too long without terminating, usually because the main thread is blocked by a long-running or deadlocked operation, and the mobile OS flags it. A crash ends the process; an ANR gets stuck in it. Both ruin the experience but need different fixes.

What causes an ANR in a mobile game?

An ANR is typically caused by the main thread being blocked for too long, by a long-running operation (heavy computation, slow file or network I/O run on the main thread), or a deadlock. Because the main thread can't respond to input during this time, the mobile OS flags the app as Not Responding. The fix is usually to move the blocking work off the main thread, so the app stays responsive, distinct from fixing a crash's fatal error.

Are ANRs as serious as crashes?

Yes, both ruin the player's experience, an ANR makes the game unresponsive and frozen, which feels just as broken as a crash and often leads the player to force-quit or uninstall. They're technically different (an ANR hangs while the app keeps running; a crash terminates the process), and they need different fixes (offloading blocked main-thread work versus fixing a fatal error). But both deserve attention as serious mobile failure modes that drive away players.

Crashes vs ANRs

Quick answer: A crash is when the app terminates; an ANR (Application Not Responding) is when the app hangs, becoming unresponsive without terminating, usually because the main thread is blocked. Both ruin the experience.

On mobile, crashes and ANRs are two distinct failure types that both make your game unusable, but they're technically different and require different fixes. Here's the comparison.

What a Crash Is

A crash on mobile is when the app terminates unexpectedly, the process ends and the game closes, usually from a fatal error like an unhandled exception or a memory access violation. The defining trait is termination: after a crash, the app is gone, and it typically leaves a stack trace at the point of failure.

Bugnet captures mobile crashes automatically with stack traces and device context. Crashes are abrupt but often diagnosable thanks to the stack trace, which points at where in the code the fatal error occurred, giving you a clear lead to investigate.

What an ANR Is

An ANR (Application Not Responding) is a mobile OS signal that the app has become unresponsive for too long, a hang, not a crash. The app hasn't terminated; it's stuck, typically because the main thread is blocked by a long-running or deadlocked operation, so the app can't respond to input and the OS flags it.

Unlike a crash, an ANR doesn't terminate the process and may not leave a clean single-point stack trace, the app is stuck, not failed. Diagnosing an ANR means finding what blocked the main thread, often a long operation (heavy work, slow I/O) that should have been off the main thread.

Why the Distinction Matters

They need different debugging. A crash points to a fatal error with a stack trace to follow. An ANR points to a blocked main thread, you investigate what long or deadlocked operation is preventing the app from responding, often moving heavy work off the main thread to fix it. The causes and fixes are distinct.

Bugnet captures crashes with stack traces and helps surface unresponsiveness patterns. Both ruin the mobile experience and deserve attention, so treat crashes and ANRs as distinct mobile failure modes: a crash terminates with a trace (find the fatal error), an ANR hangs from a blocked main thread (find and offload the blocking operation).

A crash terminates the app (leaving a stack trace); an ANR hangs the app, becoming unresponsive without terminating, usually from a blocked main thread. Both ruin the experience but need different fixes.