Android app crash and ANR logs: how to read them

Android apps fail in two main ways. A crash is when the app closes because of an error it did not handle. An ANR, short for Application Not Responding, is when the app freezes long enough that Android steps in. Each leaves a different record, and knowing which one you have tells you what to look for.

Crash or ANR: what is the difference?

Android's developer documentation defines a crash as "an unexpected exit caused by an unhandled exception or signal." Android then ends the app's process and tells you the app has stopped.

An ANR happens when the app's main thread, the one that draws the screen and handles taps, is blocked for too long. If the app is in the foreground, Android shows a dialog that lets you close it. The documentation lists the usual triggers, including:

• The app has not responded to a tap or key press within 5 seconds.

• A background service has not finished starting within a few seconds.

• A broadcast receiver, code that reacts to system events, has not finished in time. Android gives 5 seconds if the app has an activity in the foreground.

In short: a crash is the app tripping over an error, an ANR is the app getting stuck.

Where the logs live

• Logcat: Android's system log, viewed in Android Studio or with the adb tool on a computer. This is where developers usually see crashes as they happen.

• Bug report: a zip file from the phone itself. Google's documentation says it "contains device logs, stack traces, and other diagnostic information."

• ANR traces: Android stores trace files when an ANR occurs, in /data/anr on the device. Getting them directly requires developer access over adb, so most people get them inside a bug report instead.

• Android vitals in Play Console: if you publish the app, crash and ANR reports from users' devices appear here with stack traces.

How to capture a bug report on the phone

Google's steps:

1. Enable Developer options. On a Pixel, go to Settings, then About phone, then tap Build number seven times until you see "You are now a developer!" The location differs by maker; on recent Samsung Galaxy phones it is under About phone, then Software information.

2. Open Developer options and tap Take bug report.

3. Choose the report type and tap Report. A notification appears when it is ready.

4. Tap the notification to share it.

Be careful where you send it. Google notes the main file includes system logs with messages "from all apps", and the zip copies files from the device's file system. Treat it as personal data and share it only with someone who needs it.

How to read a Java or Kotlin crash

A crash from an app written in Java or Kotlin looks like this in Logcat (synthetic sample, fictional Northgate Fitness app):

FATAL EXCEPTION: main

Process: com.northgate.fitness, PID: 8812

java.lang.NullPointerException: Attempt to invoke virtual method on a null object reference

at com.northgate.fitness.WorkoutActivity.showSummary(WorkoutActivity.kt:142)

at com.northgate.fitness.WorkoutActivity.onResume(WorkoutActivity.kt:88)

at android.app.Activity.performResume(Activity.java:8422)

Google's documentation says a stack trace has two critical pieces of information: the type of exception thrown and the section of code where it was thrown. Read it in this order:

1. FATAL EXCEPTION: main says the crash happened on the main thread.

2. Process names the app's package, so you can confirm which app crashed.

3. The exception line gives the type (here, NullPointerException) and often a message.

4. The first "at" line from the app's own package is usually where to look. Lines starting with android. or java. are system code that was running too.

If the trace includes "Caused by:", the cause listed last is often the real origin. Our guide to reading a stack trace explains that pattern in detail.

How to read a native crash

Apps with C or C++ code crash with a signal instead. Google's sample shows lines like these (synthetic version):

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0

Cause: null pointer dereference

backtrace:

#00 pc 0000000000042f89 /data/app/com.northgate.fitness/lib/arm64/libtracker.so

The signal line names the failure, the Cause line (when present) gives a plain description, and the backtrace lists the code in order, with the frame numbered 00 being where it stopped. If you see only addresses and no function names, Google says the developer may need to generate a native debug symbols file and upload it to Play Console.

How to read an ANR trace

An ANR trace is a snapshot of every thread at the moment the app froze. Find the main thread and read the top of its list. That shows what it was doing instead of responding to you: often reading a file, waiting on the network or waiting for another thread to finish.

What to do if you are not the developer

1. Update the app and Android, then try again.

2. Note exactly what you did before it crashed or froze, and whether it happens every time.

3. Capture a bug report right after it happens, while the logs are fresh.

4. Contact the app's support with the app version, phone model, Android version and the steps. Offer to send the bug report privately rather than posting it publicly.

Get the log explained before you send it

EasyToDecode is launching soon. You will be able to paste a Logcat excerpt or an ANR trace and get the lines that matter quoted back, a plain-English explanation of the crash or freeze, and a short note to send the developer. See how it works or join the waitlist to hear when it opens.