Android: Debugging

Log mechanism

Android's log

Android's log can be fetched via logcat:

 adb logcat -d -v time -b main 
 adb logcat -d -v time -b events
 adb logcat -d -v time -b system
 adb logcat -d -v time -b radio

The default used log buffers are: main, system, crash.

adb logcat -d -b events | grep boot

04-24 16:51:55.687  3211  3226 I boot_progress_enable_screen: 47948
04-24 16:52:00.582  3022  3616 I sf_stop_bootanim: 52843
04-24 16:52:00.584  3211  3234 I wm_boot_animation_done: 52845

App's log

Generally, you should use the Log.v(), Log.d(), Log.i(), Log.w(), and Log.e() methods to write logs. You can then view the logs in logcat.

A good convention is to declare a TAG constant in your class:

private static final String TAG = "MyActivity";

then, make a call like

import android.util.Log;

Log.i(TAG, "index=" + i);

Framework's log

import android.util.Slog;


Slog.i(TAG, "something to say.");

HAL's log

#include <utils/Log.h>

LOGV() 
LOGD() 
LOGI() 
LOGW() 
LOGE()

Kernel's log

adb shell dmesg

The end of kernel's initialization is logged with "Freeing initrd memory:".

Debugging Native Android Platform Code

Recommend use of adb in conjunction with the setprop argument to debug certain aspects of Android.

Crash dumps

When a dynamically linked executable starts, several signal handlers are registered that, in the event of a crash, cause a basic crash dump to be written to logcat and a more detailed "tombstone" file to be written to /data/tombstones/. The tombstone is a file with extra data about the crashed process. In particular, it contains stack traces for all the threads in the crashing process (not just the thread that caught the signal), a full memory map, and a list of all open file descriptors.

In Android O and later, crash_dump32 and crash_dump64 are spawned as needed to handle crashes.
You can get a more detailed unwind with line number information by pasting the backtrace into development/scripts/stack.
If you've run lunch, then stack will be on your $PATH already so you don't need to give the full path.
You can also stack an entire tombstone file. Example:

 stack < FS/data/tombstones/tombstone_05

This is useful if you've just unzipped a bugreport in the current directory.

Getting a stack trace/tombstone from a running process

You can also use the debuggerd tool to get a stack dump from a running process.
From the command line, invoke debuggerd using a process ID (PID) to dump a full tombstone to stdout. To get just the stack for every thread in the process, include the -b or --backtrace flag.

Diagnosing Native Crashes

Abort

Aborts are deliberate.
There may be an explicit "Abort message" line in the crash messages. You should also look in the logcat output to see what this thread logged before deliberately killing itself.

Pure null pointer dereference