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=<path to compressed trace 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.