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