Performance tool ANRdaemon

Performance tool ANRdaemon


ANRdaemon is a daemon that analyzes ANR problems caused by excessive CPU usage. The daemon uses debugfs to record information. The trace module to be captured is configured in / d/tracing in advance. Depending on the CPU usage level, trace can be accessed through the global switch / d/trace/trace_on to control. The original trace file is stored in / d/tracing/trace.

The following actions will cause the daemon to start:

$ anrd -t 9990 sched gfx am

This means that when the CPU utilization is above 99.90%, you will start to catch trace, and the catch module is sched gfx am

Using [device serial]dump and get the compressed trace file.

You can use systrace to extract:

$ --from-file=<path to compressed trace file>

Known issues:

In the systrace output, anrdaemon is displayed when the trace is not running. This is because the daemon turns off tracing when CPU usage drops. The last entry it leaves in the original trace file is that the scheduler switches from some other process to the daemon. Then, after a period of time (such as 20 seconds), when the CPU utilization becomes high and the daemon turns on tracing again, the first entry in / d/tracing/trace recorded by sched is switching from the daemon to some other process. Due to this mechanism, when parses the original trace file, the daemon is displayed as running for the whole 20 seconds (because from the perspective of systrace, two sched trace entries with an interval of 20 seconds about the daemon mean that the daemon runs continuously for all 20 seconds). However, in the case of high CPU utilization, this does not affect the actually captured trace.

2, Use

anrd help information

emulator_x86_64:/ # anrd  -h                                                                                                        
usage: ANRdaemon [options] [categoris...]
Options includes:
   -a appname  enable app-level tracing for a comma separated list of cmdlines
   -t N        cpu threshold for logging to start (uint = 0.01%, min = 5000, max = 9999, default = 9990)
   -s N        use a trace buffer size of N KB default to 2048KB
   -h          show helps
Categoris includes:
   am         - activity manager
   sm         - sync manager
   input      - input
   dalvik     - dalvik VM
   audio      - Audio
   gfx        - Graphics
   rs         - RenderScript
   hal        - Hardware Modules
   irq        - kernel irq events
   sched      - kernel scheduler activity
   stack      - kernel stack
   sync       - kernel sync activity
   workq      - kernel work queues
Control includes:
   SIGQUIT: terminate the process
   SIGSTOP: suspend all function of the daemon
   SIGCONT: resume the normal function
   SIGUSR1: dump the current logging in a compressed form

Just use readme, which is to run a monitoring program. If the cpu exceeds the set value, he will catch trace.

:/ # anrd -t 5000 sched gfx am
:/ # ps -e |grep anr
root           5715      1 12346524  2064 __arm64_sys_nanosleep 0 S anrd
:/ # logcat |grep 5715
08-25 18:19:21.768  5715  5715 I anrdaemon: ANRdaemon starting

You think you can stop after you catch it and lead the trace out.

Log on device:

:/ # logcat |grep anrd
08-25 18:34:13.727  9882  9882 D anrdaemon: High cpu usage, start logging.
08-25 18:34:14.233  9882  9882 D anrdaemon: Usage back to low, stop logging.
08-25 18:38:07.754  9882  9882 I anrdaemon: Started to dump ANRdaemon trace.
08-25 18:38:16.081  9882  9882 I anrdaemon: Finished dump. Output file stored at: /data/misc/anrd/dump_of_anrdaemon.2021-08-25.18:38:07

Execute sh export trace on pc:

qiucheng@haha:~/aosp/system/extras/ANRdaemon$ ./ 
/data/misc/anrd/dump_of_anrdaemon.2021-08-25.18:38:07: 1 file pulled, 0 skipped. 27.1 MB/s (5279290 bytes in 0.186s)
Trace stored at /home/qiucheng/aosp/system/extras/ANRdaemon/dump_of_anrdaemon.2021-08-25.18:38:07

3, Source code

Code location:



There are only two files. One is cpp compiled into binary executable files on the device side, and the other is a shell script on the pc, which is used to export the captured trace

Let's look at the anrd executable first



int main(int argc, char* argv[]) {
    if (get_options(argc, argv) != 0) return 1;

    if (daemon(0, 0) != 0) return 1;
    //Note 1: for signal monitoring, save the trace file when receiving the signal
    //Note 2: new "/ d/tracing/trace" fd
    /* Clear any the trace log file by overwrite it with a new file */
    int fd = creat(dfs_trace_output_path, 0);
    if (fd == -1) {
        ALOGE("Faield to open and cleaup previous log");
        return 1;
    //Note 3: enable the dead loop monitoring cpu load monitoring signal, grab trace and save trace
    ALOGI("ANRdaemon starting");

    if (err) ALOGE("ANRdaemon stopped due to Error: %s", err_msg);

    ALOGI("ANRdaemon terminated.");

    return (err ? 1 : 0);
    static void start(void) {
    if ((set_tracing_buffer_size()) != 0) return;

    dfs_set_property(tag, apps, true);


    while (!quit && !err) {
        if (!suspend && is_heavy_load()) {//Note 4: check cpu load
             * Increase process priority to make sure we can stop logging when
             * necessary and do not overwrite the buffer
            setpriority(PRIO_PROCESS, 0, -20);
            start_tracing();//Note 5: grab trace and save trace
            setpriority(PRIO_PROCESS, 0, 0);
static void handle_signal(int signo) {//Note 6: intercept signals to react differently
    switch (signo) {
        case SIGQUIT:
            suspend = true;
            quit = true;
        case SIGSTOP:
            suspend = true;
        case SIGCONT:
            suspend = false;
        case SIGUSR1:

The principle is as simple as that in readme. Start an dead cycle, constantly check the cpu load, and catch the trace when it exceeds the set value

Let's take a look at the shell script that exports trace



if [ $# -eq 1 ]; then
    DEVICE=$(echo "-s $1")
#Note 1: detect that anrd is running
PID=$(adb $DEVICE shell "ps | grep anrd")

if [ $? -ne 0 ]; then
    echo "FAILED. ADB failed or Daemon is not running."
    exit 1
#Note 2: Send a signal to anrd to trigger the save of trace
PID=$(echo "$PID" | awk '{ print $2 }')
adb $DEVICE shell "kill -s SIGUSR1 $PID"
#Note 3: find the last generated trace file
TRACE_FILE=$(adb $DEVICE shell "ls $TRACE_DIR \
    | grep $TRACE_FILE_PATTEN | tail -n1" | tr -d '\r')
#Note 4: view the files opened by the anrd process
# Wiat the trace file generation to complete
adb $DEVICE shell "lsof -p $PID" | grep $TRACE_FILE > /dev/null
while [ $? -eq 0 ];
    sleep 1
    adb $DEVICE shell "lsof -p $PID" | grep "$TRACE_FILE" > /dev/null

if [ -z "$TRACE_FILE" ]; then
    echo "FAILED. Trace file not created"
#Note 5: pull trace to pc

echo Trace stored at ${CURRENT_DIR}/${TRACE_FILE}

Simple sequential process. Find the anrd process in the device, then send the signal SIGUSR1 to trigger the signal interception in anrd, and then save the trace and pull the latest trace to the local pc.

4, There are bug s

anrd and ANRdaemon

The initial executable program is called ANRdaemon, which is later changed to anrd, but the writing method in usage and readme has not been changed. This needs to be corrected.

'/data/misc/anrd/': No such file or directory

After looking at the git log, the directory saved by trace has never been created on the file system. So you created it manually at the beginning of development? You also need to confirm whether to modify it and whether to change it in rc or anrd.

Debugging directories such as / data/misc/wmtrace / are created in init.rc during startup


mkdir /data/misc/wmtrace 0700 system system
on property:ro.debuggable=1
    # Give writes to anyone for the trace folder on debug builds.
    # The folder is used to store method traces.
    chmod 0773 /data/misc/trace
    # Give reads to anyone for the window trace folder on debug builds.
    chmod 0775 /data/misc/wmtrace

However, after manual creation, the program can be saved and exported successfully.

Tags: Android

Posted on Sun, 28 Nov 2021 15:22:41 -0500 by SteveMellor