GDB is deprecated and will be removed soon. If you're switching from GDB to LLDB, you should probably start by reading the LLDB Tutorial. If you're an expert GDB user, the GDB to LLDB command map is very helpful while transitioning.
To use a debugger:
- Set up the build environment with the usual
- Run the same
lunchcommand you used when building.
For more help with setting up your environment, see Set up environment.
Debugging running apps or processes
To connect to a running app or native daemon, use
gdbclient.py with a PID. For example, to debug the process with PID
gdbclient.py -p 1234
The script sets up port forwarding, starts the appropriate remote debugging stub on the device, starts the debugger on the host, configures it to find symbols, and connects it to the remote debugging stub.
Debugging native process startup
To debug a process as it starts, use
gdbclient.py with the
gdbclient.py -r /system/bin/MY_TEST_APP
continue at the debugger's prompt.
Debugging app startup
Sometimes you want to debug an app as it starts, such as when there's a crash
and you want to step through code to see what happened before the crash.
Attaching works in some cases, but in other cases is
impossible because the app crashes before you can attach. The
logwrapper approach (used for
doesn't always work because the app might not have
permissions to open a port, and
gdbserver inherits that
To debug app startup, use the developer options in Settings to instruct the app to wait for a Java debugger to attach:
- Go to Settings > Developer options > Select debug app and choose your app from the list, then click Wait for debugger.
- Start the app, either from the launcher or by using the command line to run:
adb shell am start -a android.intent.action.MAIN -n APP_NAME/.APP_ACTIVITY
- Wait for the app to load and a dialog to appear telling you the app is waiting for a debugger.
gdbclientnormally, set breakpoints, then continue the process.
To let the app run, attach a Java Debug Wire Protocol (JDWP) debugger such as Java Debugger (jdb):
adb forward tcp:12345 jdwp:XXX # (Where XXX is the PID of the debugged process.)
jdb -attach localhost:12345
Debugging apps or processes that crash
If you want
debuggerd to suspend crashed processes so that you can
attach a debugger, set the appropriate property:
- Android 7.0 Nougat and higher
adb shell setprop debug.debuggerd.wait_for_gdb true
- Android 6.0 Marshmallow and lower
adb shell setprop debug.db.uid 999999
At the end of the usual crash output,
instructions on how to connect a debugger using the command:
gdbclient.py -p PID
Debugging without symbols
For 32-bit ARM, if you don’t have symbols,
gdb can't determine
which instruction set it's disassembling (ARM or Thumb). To specify the
instruction set chosen as the default when symbol information is missing, set
the following property:
set arm fallback-mode arm # or thumb
Debugging with VS Code
LLDB supports debugging platform code on Visual Studio Code. You can use the VS Code debugger frontend instead of the LLDB CLI interface to control and debug native code running on devices.
Before using VS Code for debugging, install the CodeLLDB extension.
To debug code using VS Code:
- Ensure that all build artifacts (such as symbols) required to run
- Run the following command:
lldbclient.py -p pid | -n proc-name | -r ... --setup-forwarding vscode ANY_OTHER_FLAGS
This prints a JSON object and
lldbclient.pycontinues running. This is expected; don't kill the
- In the debugging tab in VS Code, select add configuration, then select
LLDB: Custom Launch.
This opens a
launch.jsonfile and adds a new JSON object to a list.
- Delete the newly added debugger configuration.
- Copy the JSON object printed by
lldbclient.pyand paste it into the object you just deleted. Save the changes.
- To reload the window to refresh the debugger list, press
Ctrl+Shift+P and type
- Select the new debugger configuration and press run. The debugger should connect after 10 to 30 seconds.
- When you're done debugging, go to the terminal running
lldbclient.pyand press Enter to end the