The Most Common Wrong Answer in Android Interviews: “What Is ANR?

While interviewing Android developers, I noticed an interesting pattern.

When asked:

“What exactly is an ANR?”

The answers usually fell into a few categories:

• “The app crashed.”
• “The app became slow.”
• “Memory leak happened.”
• “The UI froze.”

While some of these symptoms can be related, they don’t actually explain what an ANR is.

To understand ANRs, we need to stop thinking about Activities and start thinking about how Android processes events.

Every Android application process starts from:

ActivityThread.main()

During initialization, Android creates:

• The Main Thread
• A Looper
• A MessageQueue

From that moment, the Main Thread enters an infinite event-processing loop.

Conceptually:

MessageQueue ↓ Looper.loop() ↓ Main Thread executes next event

Everything eventually reaches this queue:

• Touch events
• Lifecycle callbacks
• Broadcast callbacks
• UI updates
• Activity launches

The Main Thread processes them sequentially.

Now imagine the following situation:

A touch event arrives.

The system expects the application to process it.

But the Main Thread is currently busy performing:

• A synchronous database operation
• A long Binder transaction
• Lock acquisition
• Heavy initialization
• An infinite loop

The event remains unprocessed.

At this point something interesting happens.

The system doesn’t immediately show an ANR.

Instead, InputDispatcher waits.

Why?

Because Android assumes the application may simply be busy for a short period.

The Input pipeline looks roughly like this:

Touchscreen ↓ InputReader ↓ InputDispatcher ↓ Application Window ↓ Main Thread

After dispatching the event, InputDispatcher expects acknowledgement that the event has been handled.

If that acknowledgement never arrives within the timeout window, Android begins treating the application as unresponsive.

This is where many developers misunderstand ANRs.

The problem isn’t:

“Main thread is blocked.”

The real problem is:

“The system is waiting for a response to a critical event and that response never arrives.”

Once the timeout expires, the ANR path begins.

Depending on the situation, different components may trigger ANR handling:

• InputDispatcher (input timeout)
• Broadcast timeout mechanisms
• Service timeout mechanisms
• Content provider timeouts

Eventually ActivityManagerService (AMS) becomes involved.

AMS:

• Collects stack traces
• Captures process state
• Generates ANR diagnostics
• Presents the ANR dialog

The famous popup is actually one of the last steps in the process.

The real failure happened much earlier when the application stopped making forward progress on a critical event.

This is why ANRs are often misunderstood.

They are not fundamentally:

❌ Crash problems ❌ Memory problems ❌ Performance problems

They are primarily:

✅ Responsiveness problems

The next time you investigate an ANR, don’t start by asking:

“Why is the app slow?”

Start by asking:

“Which event is waiting for a response, and what is preventing that response from being delivered?”

That’s usually where the real root cause is hiding.

Before reading another article on ANRs, try this experiment yourself.

Create a simple Android application and add the following line at the end of onCreate():

Thread.sleep(10000)

Now launch the application.

Does an ANR appear immediately?

If yes, why?

If not, why not?

What exactly is Android waiting for before deciding that your application is no longer responding?

Understanding Android internals rarely comes from memorizing framework classes or reading documentation alone.

The real learning begins when you intentionally make the system misbehave and then investigate why.

Sometimes a 10-second Thread.sleep() can teach more about Android's event processing model than hours of reading.