Dump Android thread stack traces

If you’re debugging a Android application with Android Studio, it’s easy to inspect the stack traces of all the threads running in your application. But what do you do if you’re not able to attach the debugger? It may be that you’re running an out-of-process UIAutomator test or you’re just manually testing your application. We can utilize the on-device command kill with the signal SIGQUIT to dump our application’s thread stacks.

First, we’ll need to get the PID of our application. We can use the another on-device command ps for that. The -A flag will list all the running processes which we can then grep for our application ID (e.g. com.google.android.apps.gmm.dev) and then awk to print out just the column of the output with the process ID in it. You might have more than one process, so make sure you’re getting the ID for the one in which you’re interested.

> ps -A | grep $MY_APPLICATION_ID | awk '{ print $2 }'

Once we have our process ID, it’s just a simple matter of signalling our application with SIGQUIT(3).

> kill -SIGQUIT $MY_APPLICATION_PID

After we’ve sent the signal, we should immediately see the request being handled, a success message, and the file location of our traces in the logcat output. We’ll see the success message in one line with some truncated piece of our application ID bookended by two messages from tombstoned.

I 09:06:21 tombstoned received crash request for pid 21332
I 09:06:21 id.apps.gmm.de Wrote stack traces to tombstoned
E 09:06:21 tombstoned Traces for pid 21332 written to: /data/anr/trace_01

It seems that the location of the output file for the traces has changed over the generations of Android, but as for a Pixel 3XL running Android R, the result was written to /data/anr/trace_##. The ## was predictable as it was just a monotonically increasing value starting at 01. If you needed to know this location without digging through the logcat output, we could check this format before signalling to predict the output file.

The contents of the trace file look like what you’d expect. Stack traces with some nice metadata (probably more information than you actually wanted). I don’t think it’ll do any good to paste that here, you should just try it yourself!