or

After the initial prefix, options are provided as name=value pairs. The options currently supported by the Dalvik VM are:

To debug a program on an Android device using DDMS over USB, you could use a command like this:

This tells the Dalvik VM to run the program with debugging enabled, listening for a connection from DDMS, and waiting for a debugger. The program will show up with an app name of " " in the process list, because it wasn't started from the Android application framework. From here you would connect your debugger to the appropriate DDMS listen port (e.g. jdb -attach localhost:8700 after selecting it in the app list).

To debug a program on an Android device using TCP/IP bridged across ADB, you would first need to set up forwarding:

and then jdb -attach localhost:8000.

(In the above examples, the VM will be suspended when you attach. In jdb, type cont to continue.)

The DDMS integration makes the dt_android_adb transport much more convenient when debugging on an Android device, but when working with Dalvik on the desktop it makes sense to use the TCP/IP transport.

Most of the optional features JDWP allows are not implemented. These include field access watchpoints and better tracking of monitors.

Not all JDWP requests are implemented. In particular, anything that never gets emitted by the debuggers we've used is not supported and will result in error messages being logged. Support will be added when a use case is uncovered.

The debugger and garbage collector are somewhat loosely integrated at present. The VM currently guarantees that any object the debugger is aware of will not be garbage collected until after the debugger disconnects. This can result in a build-up over time while the debugger is connected. For example, if the debugger sees a running thread, the associated Thread object will not be collected, even after the thread terminates.

The situation is exacerbated by a flaw in the exception processing code, which results in nearly all exceptions being added to the "do not discard" list, even if the debugger never sees them. Having a debugger attached to a program that throws lots of exceptions can result in out-of-memory errors. This will be fixed in a future release.

The only way to "unlock" the references is to detach and reattach the debugger.

The translation from Java bytecode to Dalvik bytecode may result in identical sequences of instructions being combined. This can make it look like the wrong bit of code is being executed. For example:

The Dalvik bytecode uses a common return instruction for both return statements, so when i is 1 the debugger will single-step through return 0 and then return 1.

Dalvik handles synchronized methods differently from other VMs. Instead of marking a method as synchronized and expecting the VM to handle the locks, dx inserts a "lock" instruction at the top of the method and an "unlock" instruction in a synthetic finally block. As a result, when single-stepping a return statement, the "current line" cursor may jump to the last line in the method.