Debug

Flags for printLoadedClasses(). Default behavior is to only show the class name.

Flags for startMethodTracing(). These can be ORed together. TRACE_COUNT_ALLOCS adds the results from startAllocCounting to the trace key file.

Change the JDWP port.

Dump "hprof" data to the specified file. This will cause a GC.

Enable "emulator traces", in which information about the current method is made available to the "emulator -trace" feature. There is no corresponding "disable" call -- this is intended for use by the framework when tracing should be turned on and left that way, so that traces captured with F9/F10 will include the necessary data. This puts the VM into "profile" mode, which has performance consequences. To temporarily enable tracing, use startNativeTracing().

Returns the number of death notification links to Binder objects that exist in the current process.

Returns the number of active local Binder objects that exist in the current process.

Returns the number of references to remote proxy Binder objects that exist in the current process.

Returns the number of received transactions from the binder driver.

Returns the number of sent transactions from this process.

Get the number of loaded classes.

Retrieves information about this processes memory usages. This information is broken down by how much is in use by dalivk, the native heap, and everything else.

Returns the amount of allocated memory in the native heap.

Returns the amount of free memory in the native heap.

Returns the size of the native heap.

Determine if a debugger is currently attached.

Dump a list of all currently loaded class to the log file.

Establish an object allocation limit in the current thread. Useful for catching regressions in code that is expected to operate without causing any allocations. Pass in the maximum number of allowed allocations. Use -1 to disable the limit. Returns the previous limit. The preferred way to use this is: int prevLimit = -1; try { prevLimit = Debug.setAllocationLimit(0); ... do stuff that's not expected to allocate memory ... } finally { Debug.setAllocationLimit(prevLimit); } This allows limits to be nested. The try/finally ensures that the limit is reset if something fails. Exceeding the limit causes a dalvik.system.AllocationLimitError to be thrown from a memory allocation call. The limit is reset to -1 when this happens. The feature may be disabled in the VM configuration. If so, this call has no effect, and always returns -1.

Establish a global object allocation limit. This is similar to setAllocationLimit(int) but applies to all threads in the VM. It will coexist peacefully with per-thread limits. [ The value of "limit" is currently restricted to 0 (no allocations allowed) or -1 (no global limit). This may be changed in a future release. ]

Count the number and aggregate size of memory allocations between two points. The "start" function resets the counts and enables counting. The "stop" function disables the counting so that the analysis code doesn't cause additional allocations. The "get" function returns the specified value. Counts are kept for the system as a whole and for each thread. The per-thread counts for threads other than the current thread are not cleared by the "reset" or "start" calls.

Start method tracing, specifying the trace log file name. The trace file will be put under "/sdcard" unless an absolute path is given. See Traceview: A Graphical Log Viewer for information about reading trace files.

Start method tracing, specifying the trace log file name and the buffer size. The trace files will be put under "/sdcard" unless an absolute path is given. See Traceview: A Graphical Log Viewer for information about reading trace files.

Start method tracing, specifying the trace log file name and the buffer size. The trace files will be put under "/sdcard" unless an absolute path is given. See Traceview: A Graphical Log Viewer for information about reading trace files.

When method tracing is enabled, the VM will run more slowly than usual, so the timings from the trace files should only be considered in relative terms (e.g. was run #1 faster than run #2). The times for native methods will not change, so don't try to use this to compare the performance of interpreted and native implementations of the same method. As an alternative, consider using "native" tracing in the emulator via startNativeTracing().

Start method tracing with default log name and buffer size. See Traceview: A Graphical Log Viewer for information about reading these files. Call stopMethodTracing() to stop tracing.

Enable qemu tracing. For this to work requires running everything inside the qemu emulator; otherwise, this method will have no effect. The trace file is specified on the command line when the emulator is started. For example, the following command line
emulator -trace foo
will start running the emulator and create a trace file named "foo". This method simply enables writing the trace records to the trace file.

The main differences between this and startMethodTracing() are that tracing in the qemu emulator traces every cpu instruction of every process, including kernel code, so we have more complete information, including all context switches. We can also get more detailed information such as cache misses. The sequence of calls is determined by post-processing the instruction trace. The qemu tracing is also done without modifying the application or perturbing the timing of calls because no instrumentation is added to the application being traced.

One limitation of using this method compared to using startMethodTracing() on the real device is that the emulator does not model all of the real hardware effects such as memory and bus contention. The emulator also has a simple cache model and cannot capture all the complexities of a real cache.

Stop method tracing.

Stop qemu tracing. See startNativeTracing() to start tracing.

Tracing can be started and stopped as many times as desired. When the qemu emulator itself is stopped then the buffered trace records are flushed and written to the trace file. In fact, it is not necessary to call this method at all; simply killing qemu is sufficient. But starting and stopping a trace is useful for examining a specific region of code.

Get an indication of thread CPU usage. The value returned indicates the amount of time that the current thread has spent executing code or waiting for certain types of I/O. The time is expressed in nanoseconds, and is only meaningful when compared to the result from an earlier call. Note that nanosecond resolution does not imply nanosecond accuracy. On system which don't support this operation, the call returns -1.

Wait until a debugger attaches. As soon as the debugger attaches, this returns, so you will need to place a breakpoint after the waitForDebugger() call if you want to start tracing immediately.

Returns "true" if one or more threads is waiting for a debugger to attach.