CN

Android ANR Series 2: ANR Analysis Methodology and Key Logs

Java Startup Memory Android Systrace ANR
Word count: 7.2kReading time: 44 min
2025/02/08
loading

This is the second article in the Android App ANR series, focusing on ANR analysis methodology and key logs. The series includes:

  1. Android App ANR Series 1: Understanding Android ANR Design Philosophy
  2. Android App ANR Series 2: ANR Analysis Methodology and Key Logs
  3. Android App ANR Series 3: ANR Case Studies

Version note (reviewed October 2026): Historical device logs and screenshots are retained. AOSP field explanations are checked against android-15.0.0_r1; the older ART enum is labeled Android 11. Vendor logs, thresholds, and field order must be matched to the device build. The quotation below dates from 2015: an ANR attributed to an app does not establish an app-side root cause, and ANRs are not limited to the main thread. A low occurrence rate alone does not justify ignoring an issue.

ANR (Application Not Responding) - a simple definition that encompasses much of Android’s system design philosophy.

First, ANR falls within the application domain. This differs from SNR (System Not Responding), which reflects issues where the system process (system_server) loses responsiveness, while ANR explicitly confines the problem to applications. SNR is ensured by the Watchdog mechanism (details can be found in Watchdog mechanism and problem analysis); ANR is ensured by the message handling mechanism. Android implements a sophisticated mechanism at the system layer to detect ANR, with the core principle being message scheduling and timeout handling.

Second, the ANR mechanism is primarily implemented at the system layer. All ANR-related messages are scheduled by the system process (system_server) and then dispatched to application processes for actual processing. Simultaneously, the system process designs different timeout limits to track message processing. Once an application mishandles a message, the timeout limit takes effect: it collects system states such as CPU/IO usage, process function call stacks, and reports to the user that a process is not responding (ANR dialog; some ROMs don’t display the ANR dialog but directly crash to the home screen).

Third, ANR issues are essentially performance problems. The ANR mechanism actually imposes restrictions on the application’s main thread, requiring it to complete the most common operations (starting services, processing broadcasts, handling input) within specified time limits. If processing times out, the main thread is considered to have lost the ability to respond to other operations. Time-consuming operations on the main thread, such as intensive CPU computations, heavy I/O, complex UI layouts, etc., all reduce the application’s responsiveness.

Finally, some ANR problems are very difficult to analyze. Sometimes due to underlying system influences, message scheduling fails, and the problematic scenario is hard to reproduce. Such ANR issues often require significant time to understand system behaviors, going beyond the scope of the ANR mechanism itself. Some ANR problems are hard to investigate because there are many factors causing system instability, such as memory fragmentation caused by Linux Kernel bugs, hardware damage, etc. Such low-level causes often leave ANR problems untraceable, and these aren’t application issues at all, wasting much time for application developers. If you’ve worked on entire system development and maintenance, you’ll deeply understand this. Therefore, I cannot guarantee that understanding all content in this chapter will solve every ANR problem. If you encounter very difficult ANR issues, I suggest talking to friends working on Framework, drivers, and kernel, or if the problem is just a one-in-a-hundred-thousand phenomenon that doesn’t affect normal program operation, I’d suggest ignoring it.

– From duanqz

ANR Analysis Methodology

Organize evidence by ANR type: use Android Vitals or your monitoring platform to identify Input dispatch, Service, Broadcast, JobScheduler, device versions, and impact. For a local incident, collect a bugreport, EventLog, and main/system logs promptly. Direct access to /data/anr/anr_* requires device permissions; adb pull is not universally available on production builds. Capture Perfetto/System Trace early enough to include the lead-up to the timeout when investigating scheduling, Binder, locks, I/O, or rendering.

Android 11 (API 30)+ provides ApplicationExitInfo, but these are historical exit records. The timestamp is the process exit time; traces may be overwritten, and an app that recovered from an ANR may attach its earlier trace to a later exit for another reason. See part one for these limits.

Check application logic and system dependencies, then trace the waits between them. System pressure can amplify an existing synchronous wait; high CPU usage in one process does not establish ownership of the fault.

General ANR Analysis Steps:

When you get an ANR trace, first ask: does it capture the original incident? Logs, CPU samples, and thread dumps may describe different moments. If those times do not line up, it is easy to follow the wrong clue.

  1. Match package, PID, user, device boot, and am_anr reason before using a trace. Distinguish operation start, timeout detection, CPU sampling, thread dumping, and log output. am_anr is not guaranteed to mark the beginning of the failure, and a dump may arrive after the blocking operation ended.
  2. Search for ANR in; record the affected process, reason, CPU sample interval, process/thread usage, Load, PSI, and page-fault counts. The log writer may be system_server, rather than the affected process.
  3. Align relevant launches, unlocks, process changes, slow messages, lock contention, and Binder events across the timeout window. Collect useful lines in one file and search them in VS Code or Notepad++: was this the first unlock after a reboot, or did several apps start in quick succession? Follow the critical thread to lock owners, Binder servers, scheduling delays, or I/O waits; check how much of the window the evidence covers.
  4. If evidence is insufficient, leave the cause unresolved and add focused logs and tracing in a reproducible environment. Account for collection overhead; a later stack snapshot cannot reconstruct an unobserved interval.

Distinguishing Between Application Problems and System Problems

First, Analyze Whether It’s an Application Problem

Start with what the user was doing and which part of that operation the app was handling. Then check:

  1. Slow work in component lifecycle callbacks that only becomes noticeable under system load. Logs in those callbacks can help.
  2. Unusual workloads, such as a large data import or too many concurrent threads. Check the app’s CPU and I/O activity.
  3. Possible deadlocks.
  4. Waits for Binder replies.
  5. Unexpected MainThread or RenderThread activity in the trace.
  6. Waits between the main thread and worker threads.

Analyze System State

  1. Check CPU usage, Load, and scheduling waits in relevant processes such as system_server, Audio, and SurfaceFlinger. HeapTaskDaemon is an ART GC-related thread inside an application process, not a separate system service.
  2. Check I/O latency and /proc/pressure/io. Minor/major faults count page faults, not memory accesses or I/O throughput; see below.
  3. Align dumpsys meminfo, memory PSI, reclaim/swap activity, kswapd, and process-kill records. Older devices may use the kernel lowmemorykiller; modern Android commonly uses userspace lmkd. Kernel OOM is another mechanism.
  4. For suspected freezing, inspect the device’s freezer state and unfreeze logs. D means an uninterruptible wait, not proof of freezing. An older kernel’s __refrigerator stack is a freezer clue, but still requires the trigger and timing. xxxHansManager is vendor-specific.
  5. Follow a suspected system-service dependency to its Binder server or lock owner and inspect its stack and scheduling. Explain how the observed pressure blocked this particular operation.

Continue Analysis: Can Application Resolve It or System Resolve It?

  1. When the wait leads into the system or another process, provide the build version, timeline, stacks, and trace to the team owning that dependency. Escalation does not mean the issue is unsolvable.
  2. Also assess whether the app can move work off the main thread, shorten lock scopes, or avoid synchronous waits. A possible app mitigation does not establish an app-side root cause.
  3. Attribute the incident only when evidence connects the timeout to a specific blocker. Missing system access or incident data means the cause remains unresolved.

ANR Log Content

Logs can be captured via test tools, obtained from online platforms, or captured manually:

1
adb bugreport log.zip

ANR Trace Log contains the following content:

Thread Details

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
"main" prio=5 tid=1 Native
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x72c8bbf8 self=0xb400007b0ec10800
  | sysTid=5991 nice=-10 cgrp=default sched=0/0 handle=0x7b95f61500
  | state=S schedstat=( 807053249 267562324 1494 ) utm=63 stm=17 core=3 HZ=100
  | stack=0x7fcccd9000-0x7fcccdb000 stackSize=8192KB
  | held mutexes=
  native: #00 pc 00000000000c6418  /apex/com.android.runtime/lib64/bionic/libc.so (__epoll_pwait+8)
  native: #01 pc 0000000000019a9c  /system/lib64/libutils.so (android::Looper::pollInner(int)+184)
  native: #02 pc 000000000001997c  /system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+112)
  native: #03 pc 0000000000114310  /system/lib64/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)+44)
  at android.os.MessageQueue.nativePollOnce(Native method)
  at android.os.MessageQueue.next(MessageQueue.java:339)
  at android.os.Looper.loop(Looper.java:198)
  at android.app.ActivityThread.main(ActivityThread.java:8142)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1006)

The image below explains some fields in the trace:

The image is an older field guide, with some values from a different example. Read the actual dump using its build’s format. In Android 15 ART:

  • tid=1 is an ART thread ID; sysTid=5991 is the Linux TID. prio, nice, and sched describe different scheduling layers.
  • sCount is the current ART suspend count, not a lifetime suspension counter or proof of app freezing. The image’s old dsCount explanation is not portable; Android 15 prints ucsCount instead. These values do not establish a history of debugger attachment.
  • schedstat contains cumulative CPU runtime (ns), run-queue wait time (ns), and timeslices run. These are not ANR-window totals. ART may print 0 0 0 when reading fails, so missing data must not be treated as measured zero.
  • utm/stm are user/kernel clock ticks, converted using the printed HZ (100 here). core is the last CPU used, not a permanent affinity.

Thread Stack

Below is the call stack corresponding to the thread:

1
2
3
4
5
6
7
8
9
10
11
native: #00 pc 00000000000c6418 /apex/com.android.runtime/lib64/bionic/libc.so (__epoll_pwait+8)
native: #01 pc 0000000000019a9c /system/lib64/libutils.so (android::Looper::pollInner(int)+184)
native: #02 pc 000000000001997c /system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+112)
native: #03 pc 0000000000114310 /system/lib64/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)+44)
at android.os.MessageQueue.nativePollOnce(Native method)
at android.os.MessageQueue.next(MessageQueue.java:339)
at android.os.Looper.loop(Looper.java:198)
at android.app.ActivityThread.main(ActivityThread.java:8142)
at java.lang.reflect.Method.invoke(Native method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1006)

The stack contains Native and Java frames. Here, nativePollOnce shows an event wait at dump time. It does not prove the thread was idle throughout the timeout, nor exclude an asynchronous broadcast or another thread involved in the ANR. Match the ANR type and dump timing first.

Thread State

Java Thread.State, ART state, and Linux scheduling state describe different layers. Java RUNNABLE or ART Native does not guarantee on-CPU execution; inspect state=S/R/D and scheduling tracks too. This older enum matches Android 11. Android 15 uses an enum class, with kRunnable=0; the older values and table are not a complete current-version contract.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// State stored in our C++ class Thread.
// When we refer to "a suspended state", or when function names mention "ToSuspended" or
// "FromSuspended", we mean any state other than kRunnable, i.e. any state in which the thread is
// guaranteed not to access the Java heap. The kSuspended state is merely one of these.
enum ThreadState {
  //                                   Java
  //                                   Thread.State   JDWP state
  kTerminated = 66,                 // TERMINATED     TS_ZOMBIE    Thread.run has returned, but Thread* still around
  kRunnable,                        // RUNNABLE       TS_RUNNING   runnable
  kTimedWaiting,                    // TIMED_WAITING  TS_WAIT      in Object.wait() with a timeout
  kSleeping,                        // TIMED_WAITING  TS_SLEEPING  in Thread.sleep()
  kBlocked,                         // BLOCKED        TS_MONITOR   blocked on a monitor
  kWaiting,                         // WAITING        TS_WAIT      in Object.wait()
  kWaitingForLockInflation,         // WAITING        TS_WAIT      blocked inflating a thin-lock
  kWaitingForTaskProcessor,         // WAITING        TS_WAIT      blocked waiting for taskProcessor
  kWaitingForGcToComplete,          // WAITING        TS_WAIT      blocked waiting for GC
  kWaitingForCheckPointsToRun,      // WAITING        TS_WAIT      GC waiting for checkpoints to run
  kWaitingPerformingGc,             // WAITING        TS_WAIT      performing GC
  kWaitingForDebuggerSend,          // WAITING        TS_WAIT      blocked waiting for events to be sent
  kWaitingForDebuggerToAttach,      // WAITING        TS_WAIT      blocked waiting for debugger to attach
  kWaitingInMainDebuggerLoop,       // WAITING        TS_WAIT      blocking/reading/processing debugger events
  kWaitingForDebuggerSuspension,    // WAITING        TS_WAIT      waiting for debugger suspend all
  kWaitingForJniOnLoad,             // WAITING        TS_WAIT      waiting for execution of dlopen and JNI on load code
  kWaitingForSignalCatcherOutput,   // WAITING        TS_WAIT      waiting for signal catcher IO to complete
  kWaitingInMainSignalCatcherLoop,  // WAITING        TS_WAIT      blocking/reading/processing signals
  kWaitingForDeoptimization,        // WAITING        TS_WAIT      waiting for deoptimization suspend all
  kWaitingForMethodTracingStart,    // WAITING        TS_WAIT      waiting for method tracing to start
  kWaitingForVisitObjects,          // WAITING        TS_WAIT      waiting for visiting objects
  kWaitingForGetObjectsAllocated,   // WAITING        TS_WAIT      waiting for getting the number of allocated objects
  kWaitingWeakGcRootRead,           // WAITING        TS_WAIT      waiting on the GC to read a weak root
  kWaitingForGcThreadFlip,          // WAITING        TS_WAIT      waiting on the GC thread flip (CC collector) to finish
  kNativeForAbort,                  // WAITING        TS_WAIT      checking other threads are not run on abort.
  kStarting,                        // NEW            TS_WAIT      native thread started, not yet ready to run managed code
  kNative,                          // RUNNABLE       TS_RUNNING   running in a JNI native method
  kSuspended,                       // RUNNABLE       TS_RUNNING   suspended by GC or debugger
};

Blocked beside the thread name is an ART state. Owner 89 in the image is an ART tid; find it in the same dump before mapping to a Linux TID. One wait edge does not prove deadlock: continue looking for a cycle.

Normal Main Thread Trace

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
"main" prio=5 tid=1 Native
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x72c8bbf8 self=0xb400007b0ec10800
  | sysTid=5991 nice=-10 cgrp=default sched=0/0 handle=0x7b95f61500
  | state=S schedstat=( 807053249 267562324 1494 ) utm=63 stm=17 core=3 HZ=100
  | stack=0x7fcccd9000-0x7fcccdb000 stackSize=8192KB
  | held mutexes=
  native: #00 pc 00000000000c6418  /apex/com.android.runtime/lib64/bionic/libc.so (__epoll_pwait+8)
  native: #01 pc 0000000000019a9c  /system/lib64/libutils.so (android::Looper::pollInner(int)+184)
  native: #02 pc 000000000001997c  /system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+112)
  native: #03 pc 0000000000114310  /system/lib64/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)+44)
  at android.os.MessageQueue.nativePollOnce(Native method)
  at android.os.MessageQueue.next(MessageQueue.java:339)
  at android.os.Looper.loop(Looper.java:198)
  at android.app.ActivityThread.main(ActivityThread.java:8142)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1006)

This example shows an event wait at dump time; it does not rule out an earlier blocker.

Abnormal Main Thread Trace

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
"main" prio=5 tid=1 Blocked
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x70f65400 self=0xe28dae00
  | sysTid=22002 nice=-10 cgrp=default sched=0/0 handle=0xe9674474
  | state=S schedstat=( 1943159901 290647362 1661 ) utm=159 stm=34 core=7 HZ=100
  | stack=0xff041000-0xff043000 stackSize=8192KB
  | held mutexes=
  at com.facebook.cache.disk.DiskStorageCache.e(DiskStorageCache.java:3)
  - waiting to lock <0x0e57c91f> (a java.lang.Object) held by thread 89
  at com.xxx.community.util.imageloader.FrescoImageLoader.a(FrescoImageLoader.java:18)
  at com.xxx.community.util.imageloader.FrescoImageLoader$2$1.run(FrescoImageLoader.java:2)
  at android.os.Handler.handleCallback(Handler.java:938)
  at android.os.Handler.dispatchMessage(Handler.java:99)
  at android.os.Looper.loop(Looper.java:254)
  at android.app.ActivityThread.main(ActivityThread.java:8142)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1006)

Follow this monitor wait to its owner. Its duration and dependency chain determine whether it explains the ANR.

CPU Usage Analysis

After finding ANR in, read the CPU sample interval. It is not necessarily before the ANR. These historical 2020 logs include explanatory annotations; intervals marked later may include diagnostic work after detection. Do not add percentages from the two intervals. Page-fault annotations are corrected below; original measurements are retained.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
ActivityManager: ANR in com.xxx.launcher (com.xxx.launcher/.Launcher)(Process Name)
ActivityManager: PID: 5991(Process PID)
ActivityManager: Reason: Input dispatching timed out (6a6083a com.xxx.launcher/com.xxx.launcher.Launcher (server) is not responding. Waited 5001ms for FocusEvent(hasFocus=true))(Reason)
ActivityManager: Parent: com.xxx.launcher/.Launcher
ActivityManager: Load: 15.29 / 5.19 / 1.87(Load indicates CPU load for 1 min, 5 min, 15 min)
ActivityManager: ----- Output from /proc/pressure/memory -----(Memory Pressure)
ActivityManager: some avg10=1.35 avg60=0.31 avg300=0.06 total=346727
ActivityManager: full avg10=0.00 avg60=0.00 avg300=0.00 total=34803
ActivityManager: ----- End output from /proc/pressure/memory -----

// CPU usage within 13s
ActivityManager: CPU usage from 0ms to 13135ms later (2020-09-09 02:09:54.942 to 2020-09-09 02:10:08.077):
ActivityManager:   191%(Total CPU Usage) 1948/system_server: 72%(User Space Usage) user + 119%(Kernel Space Usage) kernel / faults: 78816 minor 9 major
ActivityManager:     10% 2218/android.bg: 3.6% user + 6.6% kernel
ActivityManager:   30% 5991/com.xxx.launcher: 23% user + 6.4% kernel / faults: 118172 minor(Minor page faults) 2 major(Major Page faults)
ActivityManager:     16% 6174/launcher-loader: 13% user + 2.8% kernel
ActivityManager:     3.9% 5991/m.xxx.launcher: 3.1% user + 0.8% kernel
ActivityManager:   20% 6549/com.xxx.xxx: 16% user + 3.7% kernel / faults: 3541 minor
ActivityManager:     10% 6889/DBCacheManager: 8.7% user + 1.2% kernel
ActivityManager:     9.4% 6942/DefaultDispatch: 7.1% user + 2.2% kernel

// CPU usage of each thread of each process within 1s
ActivityManager: CPU usage from 246ms to 1271ms later (2020-09-09 02:09:55.188 to 2020-09-09 02:09:56.213):
ActivityManager:   290% 1948/system_server: 114% user + 176% kernel / faults: 9353 minor
ActivityManager:     32% 5159/LockSettingsSer: 29% user + 2.9% kernel
ActivityManager:     25% 8661/AnrConsumer: 8.8% user + 16% kernel
ActivityManager:   44% 5991/com.xxx.launcher: 37% user + 7.4% kernel / faults: 5756 minor
ActivityManager:     16% 6174/launcher-loader: 13% user + 3.7% kernel
ActivityManager:     14% 5991/m.xxx.launcher: 14% user + 0% kernel
ActivityManager:   37% 6549/com.xxx.xxx: 28% user + 9.3% kernel / faults: 153 minor
ActivityManager:     37% 6942/DefaultDispatch: 28% user + 9.3% kernel
ActivityManager:   20% 5962/com.android.phone: 14% user + 5.5% kernel / faults: 1345 minor
ActivityManager:     11% 5962/m.android.phone: 7.4% user + 3.7% kernel

In Android 15 ProcessCpuTracker, process/thread percentages use the sampled uptime interval as the denominator. Parallel threads can give a process 191% or 290% CPU usage. TOTAL uses aggregate CPU time and therefore a different denominator. Fault counts are sample deltas. Align these measurements with the critical thread rather than attributing the failure from process totals alone.

CPU Load

1
ActivityManager: Load: 15.29 / 5.19 / 1.871

Load represents average active task counts over roughly 1, 5, and 15 minutes, including runnable tasks and uninterruptible waits. It is not CPU utilization, and can remain elevated after CPUs become idle. Values of 0.7, 1, or 5 are not universal phone alarm thresholds: account for online CPUs, scheduling restrictions, and I/O waits. Heterogeneous cores, frequency, and thermal limits also prevent treating eight cores as eight times one core’s capacity. See the Linux loadavg definition.

When available, /sys/devices/system/cpu/cpu%d/cpufreq/stats/time_in_state records frequency residency, not CPU busy time or app runtime, since driver initialization or a statistics reset. Upstream documents 10 ms usertime units; check vendor extensions separately. See CPUFreq Stats. The standalone extract says 1.871, whereas the preceding full log says 1.87; their original precision is retained without deriving a new result.

Memory Load

1
2
3
4
ActivityManager: ----- Output from /proc/pressure/memory -----(Memory Pressure)
ActivityManager: some avg10=1.35 avg60=0.31 avg300=0.06 total=346727
ActivityManager: full avg10=0.00 avg60=0.00 avg300=0.00 total=34803
ActivityManager: ----- End output from /proc/pressure/memory -----

This is PSI output from /proc/pressure/memory. The old transcription somavg10 is corrected to some avg10, without changing the values. avg10/60/300 are smoothed pressure percentages at those timescales. total is cumulative stall time in microseconds (µs), not milliseconds.

some covers periods when at least some tasks stall on the resource; full covers periods when all non-idle tasks stall on it simultaneously. These measure resource pressure, not CPU utilization. See Linux PSI.

The following two-task I/O illustration explains the distinction:

Red marks I/O stalls. In this idealized 60-second interval, both tasks stall for 16.66% and at least one stalls for 50%. These are interval ratios, not a direct calculation of the kernel’s smoothed avg60. Stalls may be spread across several periods, as below.

Historical illustration background: Kernel Craftsman (Chinese).

IO Load

1
ActivityManager:   30% 5991/com.xxx.launcher: 23% user + 6.4% kernel / faults: 118172 minor(faults without page I/O) 2 major(faults requiring page I/O)
  1. Minor fault: a page fault resolved without loading a page from storage, for example by mapping an already-resident page. It is not a CPU cache miss or a counter of every memory access.
  2. Major fault: a page fault requiring a page to be loaded from storage. It does not cover all I/O; ordinary file reads and writes need not generate major faults.

Thus 118172 minor / 2 major counts faults during the sample interval, not I/O operations or bandwidth. Many major faults warrant checking fault latency, I/O PSI, and critical-thread waits, but do not establish a storage-related ANR by themselves. See Linux /proc/pid/stat.

Process Load

1
ActivityManager:   30% 5991/com.xxx.launcher: 23% user + 6.4% kernel / faults: 118172 minor(Minor page faults) 2 major(Major Page faults)

23% user and 6.4% kernel describe user-mode and kernel-mode CPU time. The displayed total of 30% uses formatting precision; independently rounded fields need not add up digit for digit. See the CPU usage section for denominators and multicore behavior.

CPU Anomalous Process

These are investigation leads, not conclusions based on process names:

  1. High system_server usage: identify the thread and service/lock this operation depends on.
  2. Active kswapd: correlate reclaim and swap activity with critical-thread delays.
  3. High logd usage: inspect log volume and actual write latency; this does not prove all processes block synchronously on logging.
  4. High vold usage: follow storage operations and Binder dependencies.
  5. High app CPU: separate main-thread work, worker threads, and scheduling contention. Low app CPU can still accompany a lock- or Binder-related ANR.
  6. A thread in D: inspect its blocked stack; see the earlier freezer discussion rather than attributing it to power policy from state alone.
  7. +/- on CPU lines: these mark additions/removals in sample tracking, not exact process birth/death timestamps. Correlate lifecycle logs.

Key System Log Introduction

Application Freezing

1
xxxHansManager : freeze uid: 10245 package: com.tencent.mm reason: LcdOff

This vendor log identifies a UID, package, and LcdOff reason. Correlate process state, unfreeze timing, and the timeout before blaming a freezer bug. The AOSP cached apps freezer, supported from Android 11, uses cgroup v2; it is not interchangeable with older __refrigerator stacks or vendor Hans logs.

ActivityManager : Slow operation

The old AMS checkTime example is retained below. For Android 15 process-start checks, see ProcessList.checkSlow: checkpoints report cumulative time since startTime once it exceeds 50 ms. This is not automatic instrumentation of every AMS operation.

1
2
3
4
5
6
7
void checkTime(long startTime, String where) {
    long now = SystemClock.uptimeMillis();
    if ((now-startTime) > 50) {
        // If we are taking more than 50ms, log about it.
        Slog.w(TAG, "Slow operation: " + (now-startTime) + "ms so far, now at " + where);
    }
}
1
2
3
ActivityManager: Slow operation: 138ms so far, now at startProcess: done updating battery stats
ActivityManager: Slow operation: 138ms so far, now at startProcess: building log message
ActivityManager: Slow operation: 138ms so far, now at startProcess: starting to update pids map

Three lines saying 138ms so far can be consecutive checkpoints in one operation, not three steps each taking 138 ms. Correlate frequent reports with scheduling, locks, and I/O; they do not establish the ANR cause alone.

Looper : Slow dispatch

1
Looper  : Slow dispatch took 418ms main h=android.app.ActivityThread$H c=android.app.-$$Lambda$LoadedApk$ReceiverDispatcher$Args$_BumDX2UKsnxLVrE6UJsJZkotuA@e68bdc4 m=0

418ms is the uptime duration of dispatchMessage (end minus start), including execution, waits, and preemption—not CPU runtime. h/c/m identify the Handler, callback, and what code. Logging depends on configuration and thresholds; there is no universal 500 ms rule. See Android 15 Looper.

Looper : Slow delivery

1
Looper  : Slow delivery took 361ms android.ui h=com.android.server.am.ActivityManagerService$UiHandler c=null m=53

361ms is dispatch start minus msg.when: lateness relative to the scheduled execution time, not total time since creation or enqueueing. A delayed message intentionally has a future due time. Investigate why it was not dispatched after becoming due.

Looper：Slow Looper

1
W/Looper: Slow Looper main: Activity com.androidperformance.memoryfix/.MainActivity is 439ms late (wall=0ms running=0ms ClientTransaction{ callbacks=[android.app.servertransaction.TopResumedActivityChangeItem] }) because of 3 msg, msg 2 took 268ms (seq=2 running=207ms runnable=15ms late=1ms h=android.app.ActivityThread$H w=110), msg 3 took 171ms (seq=3 running=140ms runnable=5ms io=1ms late=268ms h=android.app.ActivityThread$H w=159)

This is a vendor extension. The definitions of late/wall/running/runnable/io and message history depend on that ROM, not a stable AOSP Looper interface. Earlier messages are leads; without the full trace these fields do not establish a complete causal chain.

onTrimMemory

1
ClockTag AlarmClockApplication: onTrimMemory: 80

80 is the historical TRIM_MEMORY_COMPLETE level, not 80 MB or 80%. The API documentation says this level is no longer delivered from Android 14 (API 34), and the constant was deprecated in API 35. It helps interpret older incidents, but is neither a guaranteed modern low-memory signal nor proof of an imminent kill.

dvm_lock_sample

1
dvm_lock_sample：[system_server,1,Binder_9,1500,ActivityManagerService.java,6403,-,1448,0]

This is an older nine-field sample: process, sensitive-thread flag, waiting thread, wait in ms, waiter file/line, owner file/line, and sample percentage. - means the same filename; it does not prove that the lock object is AMS itself. Locate both positions in the matching build. The final 0 does not match the usual nonzero sampling condition; the original device implementation is unknown, so the value is retained without inventing a policy.

This is not a live alert emitted whenever a wait crosses 500 ms. ART records completed contention after acquiring the lock, using runtime configuration and possible sampling below the threshold. Android 15 also includes method names; do not decode it with fixed positions from this older format. See Monitor and LogContentionEvent.

binder_sample

1
6628  6628 I binder_sample: [android.view.accessibility.IAccessibilityManager,6,2010,com.xxx.community,100]

PID and TID are both 6628, identifying the main thread in this historical sample. EventLogTags defines the descriptor, transaction code, duration in ms, blocking package, and sample percentage: IAccessibilityManager, code 6, 2010 ms, com.xxx.community, and 100% here. A retained tag definition does not mean collection is enabled on every release, or that a universal 500 ms threshold exists.

Resolve the code against the same build’s generated Stub/Proxy or AIDL. The older API 30 source view below maps FIRST_CALL_TRANSACTION + 5 (6) to addAccessibilityInteractionConnection. That mapping is not portable across versions. The duration is not purely server CPU time.

Long monitor contention

1
16809 14216 W system_server: Long monitor contention with owner InputDispatcher (17039) at android.content.res.Configuration com.android.server.wm.ActivityTaskManagerService.getGlobalConfigurationForPid(int)(ActivityTaskManagerService.java:1066) waiters=0 in boolean com.android.server.wm.WindowProcessController.hasActivities() for 141ms

art/runtime/monitor.cc

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
std::string Monitor::PrettyContentionInfo(const std::string& owner_name,
                                          pid_t owner_tid,
                                          ArtMethod* owners_method,
                                          uint32_t owners_dex_pc,
                                          size_t num_waiters) {
  Locks::mutator_lock_->AssertSharedHeld(Thread::Current());
  const char* owners_filename;
  int32_t owners_line_number = 0;
  if (owners_method != nullptr) {
    TranslateLocation(owners_method, owners_dex_pc, &owners_filename, &owners_line_number);
  }
  std::ostringstream oss;
  oss << "monitor contention with owner " << owner_name << " (" << owner_tid << ")";
  if (owners_method != nullptr) {
    oss << " at " << owners_method->PrettyMethod();
    oss << "(" << owners_filename << ":" << owners_line_number << ")";
  }
  oss << " waiters=" << num_waiters;
  return oss.str();
}

TID 14216 writes this line; the recorded owner is InputDispatcher (17039). 141ms is lock-wait duration, not the owner’s CPU time. waiters=0 is a count at the recording point, not proof that nobody waited. The older formatting code is retained; match the ART version. Android 15 Monitor records contention after the wait ends.

Binder Thread

1
E IPCThreadState: binder thread pool (31 threads) starved for 120 ms

This is a saturation signal for that process’s libbinder pool. The 31-thread value is configuration-specific, not a universal limit. In Android 15 IPCThreadState, timing starts when executing threads reach the limit; after the count falls below it, a duration over 100 ms is logged. It does not prove that all Binder communication stopped or that a deadlock exists. Inspect the pool threads’ locks, synchronous calls, and work.

am_kill

1
am_kill : [0,18555,com.sina.weibo.image,945,remove task]

This older five-field sample contains user 0, PID 18555, process name, OomAdj 945, and reason remove task. A stray transcribed 1 after the closing bracket has been removed. Android 15 EventLogTags adds an RSS field; parsers must match the version. The following five images index historical kill paths/reasons, not every current process-kill path.

force-stop

Abnormal Process Kill

Active Process Kill

Schedueled Process Kill

Other Process Kill

An am_kill emitted by a framework kill path is not a record of every process death. Process.killProcess(pid), shell signals, or LMK/lmkd may bypass that path while producing other logs. Signal delivery is restricted by identity, permissions, and SELinux; neither command can kill arbitrary PIDs.

An absent am_kill can also reflect overwritten or incomplete logs. Correlate death, exit, and kernel records rather than inferring the kill mechanism from a missing tag.

am_proc_died

1
am_proc_died: [0,13210,com.xxx.gallery3d,935,19]

In Android 15 EventLogTags, the fields are user, PID, process name, OomAdj, and ProcState. 935/19 are not death reasons. This event records an observed process death; correlate it with am_kill, crash, lmkd, or exit records.

am_anr

1
am_anr : [0,8769,com.android.updater,952680005,Broadcast of Intent { act=android.intent.action.BOOT_COMPLETED flg=0x9000010 cmp=com.android.updater/.BootCompletedReceiver (has extras) }]

The fields are user, PID, process name, ApplicationInfo flags, and reason. Here they identify user 0, PID 8769, com.android.updater, and a BOOT_COMPLETED broadcast. 952680005 is not a timeout duration. The Intent’s flg=0x9000010 is separate from the app flags and does not contain 0x10000000 (FLAG_RECEIVER_FOREGROUND). Determine the timeout from the build, broadcast flags, and receiver path, not the apparent size of a hexadecimal value. The log timestamp is not the broadcast start time.

Lowmemorykiller

1
2
lowmemorykiller: Kill 'com.heytap.themestore' (15545), uid 10136, oom_adj 995 to free 105068kB
lowmemorykiller: Reclaimed 105068kB at oom_adj 606

This is an older kernel lowmemorykiller format, not a promise that modern lmkd reports in the kernel log. The first line names PID 15545, UID 10136, a value labeled oom_adj of 995, and an estimated reclaim amount of 105068 kB. Do not decode 995 using the old Linux -17–15 oom_adj range; check whether the vendor uses oom_score_adj units.

The second line has no PID. Adjacency alone does not identify the same victim or establish that 606 is min_adj. A logged estimate or reclaim amount is not necessarily net physical memory freed. See AOSP lmkd for modern low-memory handling.

Blocked msg

This is internal/vendor instrumentation. The historical 1.5 s threshold belongs to that slow-message logger, not a universal AOSP ANR timeout. cost=32436 ms is message-processing duration, not CPU time. Current msg List is a pending queue snapshot, not a list of completed messages. Negative when values are offsets from scheduled execution times, not CPU durations. Decode what=110/114/121 against that build’s ActivityThread.H.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
E ANR_LOG : >>> msg's executing time is too long
E ANR_LOG : Blocked msg = { when=-32s683ms what=110 target=android.app.ActivityThread$H obj=AppBindData{appInfo=ApplicationInfo{bd8d51e com.android.contacts}} } , cost  = 32436 ms
E ANR_LOG : >>>Current msg List is:
E ANR_LOG : Current msg <1>  = { when=-32s672ms what=140 target=android.app.ActivityThread$H arg1=5 }
E ANR_LOG : Current msg <2>  = { when=-32s671ms what=114 target=android.app.ActivityThread$H obj=CreateServiceData{token=android.os.BinderProxy@f7611ff className=com.android.contacts.xxxAppServicesManagerClient packageName=com.android.contacts intent=null} }
E ANR_LOG : Current msg <3>  = { when=-32s671ms what=121 target=android.app.ActivityThread$H obj=BindServiceData{token=android.os.BinderProxy@f7611ff intent=Intent { cmp=com.android.contacts/.xxxAppServicesManagerClient }} }
E ANR_LOG : Current msg <4>  = { when=-31s658ms what=1 target=android.os.AsyncTask$InternalHandler obj=android.os.AsyncTask$AsyncTaskResult@75e517c }
E ANR_LOG : Current msg <5>  = { when=-29s750ms what=140 target=android.app.ActivityThread$H arg1=10 }
E ANR_LOG : Current msg <6>  = { when=-29s103ms what=118 target=android.app.ActivityThread$H obj={1.0 460mcc3mnc [zh_CN] ldltr sw360dp w360dp h622dp 480dpi nrml long port finger -keyb/v/h -nav/h appBounds=Rect(0, 0 - 1080, 1920) s.10mThemeChanged = 0mThemeChangedFlags = 0mFlipFont = 0}
E ANR_LOG : Current msg <7>  = { when=-28s370ms what=118 target=android.app.ActivityThread$H obj={1.0 460mcc11mnc [zh_CN] ldltr sw360dp w360dp h622dp 480dpi nrml long port finger -keyb/v/h -nav/h appBounds=Rect(0, 0 - 1080, 1920) s.11mThemeChanged = 0mThemeChangedFlags = 0mFlipFont = 0} }
E ANR_LOG : Current msg <8>  = { when=-27s821ms what=122 target=android.app.ActivityThread$H obj=BindServiceData{token=android.os.BinderProxy@f7611ff intent=Intent { cmp=com.android.contacts/.xxxAppServicesManagerClient }} }
E ANR_LOG : Current msg <9>  = { when=-27s821ms what=116 target=android.app.ActivityThread$H obj=android.os.BinderProxy@f7611ff }
E ANR_LOG : Current msg <10>  = { when=-27s654ms what=114 target=android.app.ActivityThread$H obj=CreateServiceData{token=android.os.BinderProxy@e23cf1b className=com.android.contacts.xxxAppServicesManagerClient packageName=com.android.contacts intent=null} }
E ANR_LOG : >>>CURRENT MSG DUMP OVER<<<

Common Scenario Logs Introduction

Screen Off Log

The key is power_screen_broadcast_done, screen_toggled and power_screen_state.

1
2
3
4
5
6
7
8
9
10
11
12
1810  2470 I intercept_power: [ACTION_DOWN,1,0]
1810  2470 I intercept_power: [ACTION_UP,0,0]
1810  2470 I power_sleep_requested: 0

1810  1810 I power_screen_state: [0,2,0,0,1254]
1810  1810 I screen_toggled: 0 // 0 means screen off, 1 means screen on
1810  1810 I power_screen_broadcast_send: 1
1810  1825 I wm_set_keyguard_shown: [1,0,0,setKeyguardShown] // (keyguardShowing|1),(aodShowing|1),(keyguardGoingAway|1),(Reason|3)

2768  2768 I sysui_status_bar_state: [1,1,0,0,0,1]

1810  1810 I power_screen_broadcast_done: [0,611,1] // 0 means screen off, 611 is broadcast duration (ms)

These historical logs are retained. power_screen_broadcast_done contains on, broadcast duration in ms, and wakelockCount. The 611 ms value measures the broadcast flow, not panel power-off latency. In power_screen_broadcast_send: 1, 1 is wakelockCount, not the screen state. See Android 15 Notifier.

Screen On Log

The key is power_screen_broadcast_done, screen_toggled and power_screen_state.

Where power_screen_state:

  1. offOrOn|1|5
  2. becauseOfUser|1|5
  3. totalTouchDownTime|2|3
  4. touchCycles|1|1
  5. latency|1|3
1
2
3
4
5
6
1810  2470 I intercept_power: [ACTION_DOWN,1,0]
1810  2470 I intercept_power: [ACTION_UP,1,0]
1810  1810 I screen_toggled: 1 // 1 means screen on
1810  1810 I power_screen_broadcast_send: 1
1810  1810 I power_screen_state: [1,0,0,0,319]
1810  1810 I power_screen_broadcast_done: [1,633,1] // 1 means screen on, 633 is broadcast duration (ms)

Likewise, 633 ms is broadcast duration, not total button-to-visible-screen latency. Codes such as |1|5 above are EventLog type/unit metadata, not actual event values. Check the writer for vendor-specific power_screen_state reason/latency semantics; these logs are not guaranteed on every device.

Unlock Complete Log

Values of wm_set_keyguard_shown:

  1. (keyguardShowing|1): Whether Keyguard is showing
  2. (aodShowing|1): Whether aodShowing is showing
  3. (keyguardGoingAway|1): Keyguard disappearing
  4. (Reason|3): Reason
1
2
3
4
5
6
7
8
9
10
 1810  5711 I wm_set_keyguard_shown: [1,0,1,keyguardGoingAway]
// Launcher Resume
 1810  5711 I wm_set_resumed_activity: [0,com.xxx.launcher/.Launcher,resumeTopActivityInnerLocked]
 1810  5711 I wm_resume_activity: [0,93093883,63,com.xxx.launcher/.Launcher]
20615 20615 I wm_on_restart_called: [93093883,com.xxx.launcher.Launcher,performRestartActivity]
20615 20615 I wm_on_start_called: [93093883,com.xxx.launcher.Launcher,handleStartActivity]
20615 20615 I wm_on_resume_called: [93093883,com.xxx.launcher.Launcher,RESUME_ACTIVITY]
20615 20615 I wm_on_top_resumed_gained_called: [93093883,com.xxx.launcher.Launcher,topWhenResuming]

 1810  5711 I wm_set_keyguard_shown: [0,0,1,setKeyguardShown] // keyguard not showing, aod not showing, keyguardGoingAway, reason is setKeyguardShown, not proof that the launcher is displayed

This uses an older four-field format. Android 15 has six: DisplayId, keyguardShowing, aodShowing, keyguardGoingAway, occluded, and Reason. Do not parse it with the old positions. setKeyguardShown is a call reason, not proof that the launcher is visible or interactive; correlate window, rendering, and input evidence. See WindowManager EventLogTags.

Notification Panel Pull Down Log

1
2
3
4
5
6
2768  2768 I sysui_multi_action: [757,803,799,panel_open,802,1]
2768  2768 I sysui_multi_action: [757,1328,758,4,1326,29,1327,0,1329,0]
1810  3004 I notification_visibility: [-1|android|55|null|1000,1,457483196,457483196,0,4]
1810  3004 I notification_visibility: [0|com.android.systemui|10005|null|10132,1,97168545,97168545,0,2]
1810  3004 I notification_visibility: [0|com.android.systemui|2147483647|ranker_group|10132|ranker_group,1,97168236,97168236,0,1]
1810  3004 I notification_visibility: [-1|com.android.systemui|10006|null|10132,1,82586063,82586063,0,0]

The numeric sysui_multi_action values are version-specific Metrics codes. notification_visibility contains key, visible, lifespan, freshness, exposure, and rank; its duration fields are not absolute incident timestamps. visible=1 indicates notification visibility, not a complete gesture history.

Notification Panel Collapse Log

1
2
3
4
5
2768  2768 I sysui_multi_action: [757,111,758,2]
1810  5473 I notification_visibility: [-1|android|55|null|1000,0,457546516,457546516,0,4]
1810  5473 I notification_visibility: [0|com.android.systemui|10005|null|10132,0,97231865,97231865,0,2]
1810  5473 I notification_visibility: [0|com.android.systemui|2147483647|ranker_group|10132|ranker_group,0,97231557,97231557,0,1]
1810  5473 I notification_visibility: [-1|com.android.systemui|10006|null|10132,0,82649384,82649384,0,0]

Here the visibility field becomes 0. Logging configuration and platform version affect availability; missing lines do not prove that the panel was never opened or collapsed.

App Launch Log

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// Create Task
1810  5473 I wm_task_created: [100,-1]
1810  5473 I wm_stack_created: 100
1810  5473 I wm_create_task: [0,100]

// Create Activity
1810  5473 I wm_create_activity: [0,231348670,100,com.androidperformance.memoryfix/.MainActivity,android.intent.action.MAIN,NULL,NULL,270532608]

// Launcher goes through pause flow
1810  5473 I wm_pause_activity: [0,93093883,com.xxx.launcher/.Launcher,userLeaving=true]
0615 20615 I wm_on_top_resumed_lost_called: [93093883,com.xxx.launcher.Launcher,topStateChangedWhenResumed]
0615 20615 I wm_on_paused_called: [93093883,com.xxx.launcher.Launcher,performPause]
1810  3720 I wm_add_to_stopping: [0,93093883,com.xxx.launcher/.Launcher,makeInvisible]

// Start Activity
1810  2045 I am_proc_start: [0,18803,10263,com.androidperformance.memoryfix,pre-top-activity,{com.androidperformance.memoryfix/com.androidperformance.memoryfix.MainActivity}]
1810  3428 I am_proc_bound: [0,18803,com.androidperformance.memoryfix]
1810  3428 I wm_restart_activity: [0,231348670,100,com.androidperformance.memoryfix/.MainActivity]
1810  3428 I wm_set_resumed_activity: [0,com.androidperformance.memoryfix/.MainActivity,minimalResumeActivityLocked]
8803 18803 I wm_on_create_called: [231348670,com.androidperformance.memoryfix.MainActivity,performCreate]
8803 18803 I wm_on_start_called: [231348670,com.androidperformance.memoryfix.MainActivity,handleStartActivity]
8803 18803 I wm_on_resume_called: [231348670,com.androidperformance.memoryfix.MainActivity,RESUME_ACTIVITY]
8803 18803 I wm_on_top_resumed_gained_called: [231348670,com.androidperformance.memoryfix.MainActivity,topStateChangedWhenResumed]
1810  2034 I wm_activity_launch_time: [0,231348670,com.androidperformance.memoryfix/.MainActivity,471]

// Launcher goes through stop flow
1810  1978 I wm_stop_activity: [0,93093883,com.xxx.launcher/.Launcher]
0615 20615 I wm_on_stop_called: [93093883,com.xxx.launcher.Launcher,STOP_ACTIVITY_ITEM]

The retained extract has apparent PID truncations such as 0615 20615 and 8803 18803. Without the original file, missing digits are not reconstructed; match am_proc_start and the complete incident. The 471 ms wm_activity_launch_time reports that build’s launch measurement, not necessarily full rendering or readiness for interaction.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// App launch from Launcher, focus change: Launcher => null => App
WindowManager: Changing focus from Window{b0416d7 u0 com.xxx.launcher/com.xxx.launcher.Launcher} to null,diplayid=0
WindowManager: Changing focus from null to Window{10f5145 u0 com.android.settings/com.android.settings.Settings},diplayid=0

// Return to Launcher from App, focus change: App => null => Launcher
WindowManager: Changing focus from Window{10f5145 u0 com.android.settings/com.android.settings.Settings} to null,diplayid=0
WindowManager: Changing focus from null to Window{b0416d7 u0 com.xxx.launcher/com.xxx.launcher.Launcher},diplayid=0

// Enter Lockscreen from App interface: focus change: App => null => Lockscreen
WindowManager: Changing focus from Window{10f5145 u0 com.android.settings/com.android.settings.Settings} to null,diplayid=0
WindowManager: Changing focus from null to Window{82e5f30 u0 NotificationShade},diplayid=0

// Unlock from Lockscreen interface to App, focus change: Lockscreen => App
WindowManager: Changing focus from Window{82e5f30 u0 NotificationShade} to Window{10f5145 u0 com.android.settings/com.android.settings.Settings},diplayid=0

A brief Launcher → null → App transition can be normal. A NoFocusedWindow ANR requires examining pending focus-dependent input, the focused application, how long the window is missing, and the timeout policy. A null focus alone is insufficient; these logs also depend on debugging settings. See part one.

ANR Related Information Sharing

  1. Xigua Video Stability Governance System Construction 1: Tailor Principle and Practice
  2. Xigua Video Stability Governance System Construction 2: Raphael Principle and Practice
  3. Xigua Video Stability Governance System Construction 3: Sliver Principle and Practice
  4. Xigua Freeze & ANR Optimization Governance and Monitoring System Construction
  5. Toutiao ANR Optimization Practice Series - Design Principle and Influencing Factors
  6. Toutiao ANR Optimization Practice Series - Monitoring Tools and Analysis Ideas
  7. Toutiao ANR Optimization Practice Series - Example Analysis Collection
  8. Toutiao ANR Optimization Practice Series - Barrier Causes Main Thread Deadlock
  9. Toutiao ANR Optimization Practice Series - Goodbye, SharedPreference Waiting
  10. Android ANR | Principle Analysis and Common Cases

Reference

  1. https://duanqz.github.io/2015-10-12-ANR-Analysis#1-%E6%A6%82%E8%A7%88
  2. https://duanqz.github.io/2015-10-12-ANR-Analysis
  3. http://gityuan.com/2016/12/02/app-not-response/
  4. http://gityuan.com/2017/01/01/input-anr/
  5. https://xiaozhuanlan.com/topic/5097486132

About Me && Blog

Below is a personal introduction and related links. I look forward to communicating with you all!

  1. Blogger Personal Introduction: Contains personal WeChat and WeChat group links.
  2. Blog Content Navigation: A navigation of personal blog content.
  3. Excellent Blog Articles Collected and Organized by Individuals - Must-Know for Android Performance Optimization: Welcome everyone to recommend yourself and recommend (WeChat private chat is fine)
  4. Android Performance Optimization Knowledge Planet: Historical introduction; the community has closed.

One person can go faster, a group of people can go further

Author：Gracker

Link：https://androidperformance.com/en/2025/02/08/Android-ANR-02-How-to-analysis-ANR/

Publish date：February 8th 2025, 4:29:09 pm

Update date：November 3rd 2026, 1:53:28 am

License：This work is licensed under Creative Commons Attribution-NonCommercial 4.0 International License

CATALOG
  1. 1. ANR Analysis Methodology
    1. 1.1. General ANR Analysis Steps:
    2. 1.2. Distinguishing Between Application Problems and System Problems
      1. 1.2.1. First, Analyze Whether It’s an Application Problem
      2. 1.2.2. Analyze System State
    3. 1.3. Continue Analysis: Can Application Resolve It or System Resolve It?
  2. 2. ANR Log Content
    1. 2.1. Thread Details
    2. 2.2. Thread Stack
    3. 2.3. Thread State
      1. 2.3.1. Normal Main Thread Trace
      2. 2.3.2. Abnormal Main Thread Trace
    4. 2.4. CPU Usage Analysis
    5. 2.5. CPU Load
    6. 2.6. Memory Load
    7. 2.7. IO Load
    8. 2.8. Process Load
    9. 2.9. CPU Anomalous Process
  3. 3. Key System Log Introduction
    1. 3.1. Application Freezing
    2. 3.2. ActivityManager : Slow operation
    3. 3.3. Looper : Slow dispatch
    4. 3.4. Looper : Slow delivery
    5. 3.5. Looper：Slow Looper
    6. 3.6. onTrimMemory
    7. 3.7. dvm_lock_sample
    8. 3.8. binder_sample
    9. 3.9. Long monitor contention
    10. 3.10. Binder Thread
    11. 3.11. am_kill
      1. 3.11.1. force-stop
      2. 3.11.2. Abnormal Process Kill
      3. 3.11.3. Active Process Kill
      4. 3.11.4. Schedueled Process Kill
      5. 3.11.5. Other Process Kill
    12. 3.12. am_proc_died
    13. 3.13. am_anr
    14. 3.14. Lowmemorykiller
    15. 3.15. Blocked msg
  4. 4. Common Scenario Logs Introduction
    1. 4.1. Screen Off Log
    2. 4.2. Screen On Log
    3. 4.3. Unlock Complete Log
    4. 4.4. Notification Panel Pull Down Log
    5. 4.5. Notification Panel Collapse Log
    6. 4.6. App Launch Log
    7. 4.7. Window Focus Related Flows
  5. 5. ANR Related Information Sharing
  6. 6. Reference
  7. 7. About Me && Blog
Total : 139
2026
2025
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
100Years iOS HealthKit AI Health Data Yearly Recommendations Startup Memory Android Perfetto Systrace Jank Year in Review Knowledge Planet Essays Performance AOSP Framework AIW Open Source ANR RenderThread Agent OS OpenAI Mobile OS DelayLoad Java Tools Linux Binder Locking Scheduling Performance Optimization Thread Optimization Jank Optimization Battery Optimization ANR Analysis Page Response SQL TraceProcessor SDK TraceEvent Trace DataFlow heapprofd Field GPU Power MAT Input Latency Camera Audio Programmer HashMap Singleton Nexus OpenClaw Productivity Tools Local Models Annual Recommendations AI Agent Sharp Tools Productivity SmartPerfetto MCP Design Specs Gracker Kotlin Stutter Process Overdraw Reading Notes The Programmer's Apprenticeship Design Principles Testing Internet Game Programming User Experience Reading Liqi Community Smooth Experience Optimization
Product Casual Notes Essays Reading Notes Android Java AI Android Performance Optimization Personal Projects