Editor’s Note: This post was originally posted on Sep. 21, 2020 and was republished on Mar. 8, 2023 to ensure all content and links are up to date and accurate.

Application Not Responding (ANR) is a type of error on Android that occurs when a user is unable to take action in an app for a prolonged period of time. The user is presented with a pop-up window after about 5 seconds asking if they would like to close the app or continue waiting. Understandably, neither of these options are particularly inviting to a user who simply wants to engage with your app. Thus, ANRs create poor user experiences that lead to force quits and app uninstalls, so they are very important to address when you come across them in your applications. In this post, we’ll cover several areas about ANRs:

  • What ANRs are and how they are triggered
  • Why ANRs produce a poor user experience
  • How Google Play Store underreports ANRs
  • How ANRS reduce app ranking and discoverability
  • How you can solve ANRs
  • Choosing the best tool for identifying and solving ANRs

What ANRs are and how they are triggered

ANRs are the Android OS’s attempt to notify developers and users when an app is suffering from bad performance. There is no analogue on iOS other than the system killing an app for exceeding resource limits. According to the Android documentation, an ANR will be triggered for your app when one of the following conditions occur:

  • While your activity is in the foreground, your app has not responded to an input event (such as key press or screen touch events) or BroadcastReceiver within 5 seconds.
  • While you do not have an activity in the foreground, your BroadcastReceiver hasn’t finished executing within a set amount of time. (Note: Reading the Android source code reveals the actual threshold to be 10 seconds.)
  • If a service declared by your app cannot finish executing Service.onCreate() /Service.onStartCommand()/Service.onBind()
  • If your app doesn’t callstartForeground() within 5 seconds after it’s used Context.startForegroundService() to start a new service in the foreground.

In this post, we’ll focus on ANRs as they relate to the inability to respond to user input. What they boil down to in this regard is that a user is unable to tap, swipe, scroll, or in any way interact with an application.

ANRs are the result of blocking the application’s main thread. Since on Android the main thread is responsible for updating the UI, when it is blocked, the user is stuck facing a frozen screen.

Here are the three most common ways the main thread can be blocked:

  • Networking or storage – Parsing heavy payloads on the main thread will block the UI. Likewise, the storing or retrieving of data from a database can take a long time and lead to ANRs.
  • Processor-heavy activity – This can be anything that involves a lot of CPU, such as data transforms like sorting, manipulating, or parsing data. It can also be things like processing images or videos.
  • A bug involving looping or recursion – Bad code that runs for too long can block the main thread.

There are other reasons why ANRs can happen that are device-related. For example, if the hardware cannot keep up with the demands of the app, then the duration to complete tasks slows. Thus, even when on the same app version, users might encounter ANRs selectively depending on their devices and OSs.

Why ANRs produce a poor user experience

ANRs present themselves to users as frozen screens and stutters. If you have ever tried to scroll in an app and been unable to or tried to rage tap a button that won’t respond, you have interacted with a blocked main thread.

The problem is that people have little patience for a lack of interactivity. If your app frequently hangs, they:

  • Won’t use it as much.
  • Complain about it in app reviews.
  • Uninstall it and replace it with a competitor’s app.

It’s incredibly important to not rely on crashes alone when monitoring your app. The end-user experience is vital to remain competitive when users can easily switch to an app that offers better performance.

How the Google Play Store underreports ANRs

Users can opt-in to share usage and diagnostic information about the apps they use to the Google Play Store. If they do, their Android device logs various metrics that Google can share with app developers.

Google only reports ANRs if the user cannot interact with the application for 5 seconds. This is an arbitrary threshold chosen by Google, and your application may suffer from a significant number of ANRs that affect the user experience but do not reach the 5-second limit.

And many users will not wait 5 seconds on a frozen screen before force quitting the app. Developers lose insight into just how long users are willing to tolerate slow parts of their app. What if the vast majority of users choose to quit your app if it is frozen for 3 seconds? You won’t know why you are losing users because you do not have a broad enough coverage of ANR intervals.

In other words, if an app is frozen for 5 seconds, it is probably too far gone and it will not respond again. But the app might hang or freeze for a couple seconds and then recover. What is the user impact of these freezes? What if your app has several short freezes instead of long ones?

How ANRs reduce app ranking and discoverability

ANRs are one of the Google Play Store’s two core vitals:

  • User-perceived ANR rate
  • User-perceived crash rate

While there are other vitals you should pay attention to as well, bad behavior in the core vitals directly affects your ranking and discoverability. This means you risk your app’s positioning in search results and whether it can even be qualified to be featured.

For the core vitals, there are two bad behavior thresholds to pay attention to — overall and per device. The overall bad behavior threshold measures all sessions on all devices, while the per device threshold evaluates per individual phone.

When considering devices overall, you’ll need to keep your ANR rate below 1.09% for user-perceived crash rates and below .47% for user-perceived ANR rates. For device-specific thresholds, you’ll need to keep your ANR rate below 8% for both user-perceived crash and ANR rates.

If you want to leverage organic app store traffic, you should closely monitor your ANRs.

How you can solve ANRs

The biggest barrier to solving ANRs is discovering them. Developers won’t catch all ANRs in testing because they simply cannot account for all the variables their users experience. And ANRs are not exclusively bugs in code, which makes them impossible to completely eradicate. They can stem from:

  • Starting a library on the main thread (which many libraries require)
  • A CPU-intensive load, like parsing a very complex response from a network request on the main thread
  • Heavy view rendering
  • Expensive database calls or writing to files
  • A user losing network connectivity during a video upload

Preventing ANRs is not as simple as “move everything to a background thread.” If that was the solution, we wouldn’t have ANRs. In reality, developers face a constant struggle between maximizing app performance and minimizing system resource usage. For example, creating background threads and moving data between them and the main thread does have a cost. Also, heavy UI updates might incur lag simply due to hardware constraints on older devices.

If you discover an ANR in testing, you can reproduce it by recording a system trace and viewing the resulting heat map.

But how do you discover ANRs once the app is in production?

  • ANRs don’t always happen in a reliable, repeatable manner.
  • Users might not report them, and if they do, there’s not enough information to reproduce them.
  • ANRs can stem from unpredictable variables in the device and user.

In short, you need tooling in place that shows you when ANRs start, how long they last, if they recover, and if they end in app failure. You can learn more about how to leverage the right data and tooling in our eBook.

Choosing the best tool for identifying and solving ANRs

Your mobile team needs a solution that alerts them to issues faster and gets them to the sources of problems efficiently. These features are vital to increase your ranking in the Google Play Store and satisfy users. The Embrace approach is to provide your mobile team with comprehensive data quickly.

For example, Embrace starts capturing ANRs as soon as the main thread is blocked for 1 second. This means you can review stack traces that are much closer to the initial conditions that caused the app freeze.

User session with first ANR stack trace expanded.

We provide data on ANR Intervals (when the app hangs but eventually recovers) as well as ANR Exits (when the user quits the app).

In addition, we capture multiple stack traces during the entire ANR lifecycle so you can gain insight into what code your app was executing and how that evolved during the duration of the ANR.

This allows you to better pinpoint the root cause. For example, if the main thread was blocked because of a slow-running event like a network call, that is relatively easy to diagnose.

But if the main thread was blocked while doing heavy processing, the stack trace will constantly change throughout an ANR, making it difficult to know where to investigate if you were only given the final stack trace.

flame graph of organized by code thread.

Solving ANRs becomes much easier with flame graphs. The ability to see ANR data grouped by package rather than stack trace similarity shows which sections of code are more likely to contribute to ANRs and allows your mobile team to prioritize and solve the problem fast.

Final thoughts

Embrace is a unified mobile monitoring platform that provides high-fidelity data to empower teams to prioritize, understand, and resolve issues. If your mobile business goal is app growth, then creating satisfying user experiences through the fast resolution of ANRs is vital.

With Embrace, your team can:

  • Eliminate the need to cobble together scattered data that lacks context to understand the cause of ANRs.
  • Understand the downstream impact of ANRs on your mobile business through clear correlations across devices, OSs, packages, and regions.
  • Improve your Google Play Store ranking by solving the ANRs that matter, with earlier detection and high-level prioritization with flame graphs.

Interested in learning more about solving ANRs? If you’d like to see how complete mobile visibility can revolutionize how you deliver incredible mobile experiences, get started with a free trial today.