ANRdaemon is a daemon to help analyze ANR due to CPU starvation by logging system activity when CPU usage is very high. The daemon uses debugfs underlying for logging. Trace are configured ahead by setting different modules in /d/tracing. Depending on the CPU usage level, the trace is turn on/off by writting to the global control /d/trace/trace_on. The raw trace file is stored at /d/tracing/trace.
The daemon will be started at boot time and will be running with the following settings: $ anrd -t 9990 sched gfx am This means tracing will be enabled above 99.90% CPU utilization and will trace sched, gfx and am modules (See -h for more info).
Use ANRdaemon_get_trace.sh [device serial] to dump and fetch the compressed trace file.
The compressed trace file can be parsed using systrace: $ systrace.py --from-file=
Known issue: in the systrace output, anrdaemon will show up when the trace is not running. This is because the daemon process turns off tracing when CPU usage drops, the last entry it leaves in the raw trace file is the scheduler switched from some other process to the daemon. Then sometime later (say 20 secs later), when the CPU usage becomes high and the daemon process turn on tracing again, the first entry in /d/tracing/trace logged by sched is switching away from the daemon process to some other process. Due to this artifact, when the raw trace file is parsed by systrace.py, the daemon process is shown as running for the whole 20secs (because from systrace's view, the two 20 sec apart sched trace entries regarding the daemon process indicates the daemon process ran continuously for all 20sec). However, this will not affect the actual captured trace during high CPU usage case.