What is ANR and How it Can be Prevented in Android?

ANR stands for Application Not Responding. An ANR will occur if you’re running a process on the UI thread which takes an extended time, usually around 5 seconds. During this point, the GUI (Graphical User Interface) will lock up which can end in anything the user presses won’t be actioned. After the 5 seconds approx. has occurred, if the thread still hasn’t recovered then an ANR dialogue box is shown informing the user that the appliance isn’t responding and can give the user the choice to either wait, in the hope that the app will eventually recover, or to force close the app. This is how the ANR dialog displayed to the user.

A crash is when an exception within the app has been thrown which has not been handled. For example, if you are trying to set the text of an EditText component, but the EditText is null and there’s no try-catch statement to catch the exception then your app will crash and can be force closed. The user won’t see what caused the crash, they’re going to be shown a dialogue telling that the app has force closed unexpectedly and can give them the choice to send a bug report. For example, an error caused by java.lang.NullPointerException is an ANR. An ANR happens when some long operation takes place in the “main” thread. This is the event loop thread, and if it’s busy, Android cannot process any longer GUI events within the application, and thus presents an ANR dialog. Now, within the trace you posted, most thread seems to be doing fine, there’s no problem. It is idling within the MessageQueue, expecting another message to return. In your case, the ANR was likely a longer operation, rather than something that blocked the thread permanently, so the event thread recovered after the operation finished, and your trace went through after the ANR.

How to prevent an ANR?

Stop doing heavy tasks on the main thread. Instead use worker threads such as IntentService, AsyncTask Handler, or another Thread simply. Detecting where ANRs happen is straightforward if it’s a permanent block (deadlock acquiring some locks for instance), but harder if it’s just a short-lived delay. First, re-evaluate your code and appearance for vulnerable spots and long-running operations. Examples may include using sockets, locks, thread sleeps, and other blocking operations from within the event thread. You should make sure these all happen in separate threads. If nothing seems the matter, use DDMS and enable the thread view. This shows all the threads in your application similar to the trace you have. Reproduce the ANR, and refresh the most thread at an equivalent time. That should show you exactly what’s happening at the time of the ANR. An ANR is going to be triggered for your app when one among the subsequent conditions occur:

1. While your activity is within the foreground, your app has not fed with an input event or BroadcastReceiver (such as key press or screen touch events) within 5 seconds.
2. While you aren’t doing an activity within the foreground, your BroadcastReceiver hasn’t finished executing within a substantial amount of your time.

If your app is experiencing ANRs, you’ll use the guidance during this article to diagnose and fix the matter.

Android vitals

Android vitals can help improve your app’s performance by alerting you, via the Play Console, when your app is exhibiting excessive ANRs. Android vitals considers ANRs excessive when an app:

1. Exhibits a minimum of one ANR in a minimum of 0.47% of its daily sessions.
2. Exhibits 2 or more ANRs in a minimum of 0.24% of its daily sessions.
3. Exhibits 3 or more ANRs in a minimum of 0.17% of its daily sessions.
4. Exhibits 3 or more ANRs in a minimum of 0.14% of its daily sessions.

Diagnosing ANRs

The ANRs could be solved easily as the Android Interface Provide Efficient Tools to remove them! Finding them may include (but are not limited to):

1. The app is doing slow operations which involves the I/O operation of the operating system.
2. The main thread is doing a synchronous binder call to a different process, which another process is taking an extended time to return.
3. The main thread is during a deadlock with another thread, either in your process or via a binder call. the most thread isn’t just expecting an extended operation to end but is during a deadlock situation.
4. The app is doing an extended calculation on the basic thread.

Using the Android Strict Mode (API Level > 9)

Starting API Level 9 using StrictMode will help you discover certain accidental I/O operations on the most thread while you’re developing your app. you’ll use StrictMode at the appliance or activity level. Read more about how to use StrictMode here.

Moreover, you can also find about the ANRs by pulling a Traces File from Android ADB as Follows:

adb root
adb shell ls /data/anr
adb pull /data/anr/<filename>

But if your users are still experiencing ANRs, you are bound to check out the status of the prime a.k.a. main thread in Android Device Monitor. Usually, the main thread is in the RUNNABLE state if it’s ready to update the UI and is generally responsive if everything is fine!

An Example

Java

@Override
public void onClick(View view) {
    // This task works on the
    // main thread and will cause an ANR.
    MergeSort.sort(data);
}

In the above-mentioned case what we need to do is to remove the sorting process from the main thread and place it into another class or thread, so that the system can handle it asynchronously.

A Tip

When an ANR occurs and your app crashes out of nowhere, Android Studio logs some info related to the case in a text file on the device itself. You can use ADB to gather logs and have a look. You can also add Crashlytics from Firebase to catch hold of ANRs when they occur in your app, and get their frequency, and event the activity thread on which it happened! View More Details about ANR by visiting Here.