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 may cause a GC.

Get a debugging dump of a system service by name.

Most services require the caller to hold android.permission.DUMP.

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.

Returns the global count of external allocation requests. The external allocation tracking feature was removed in Honeycomb. This method exists for compatibility and always returns 0.

Returns the global count of bytes externally allocated. The external allocation tracking feature was removed in Honeycomb. This method exists for compatibility and always returns 0.

Returns the global count of freed external allocation requests. The external allocation tracking feature was removed in Honeycomb. This method exists for compatibility and always returns 0.

Returns the global count of freed bytes from external allocation requests. The external allocation tracking feature was removed in Honeycomb. This method exists for compatibility and always returns 0.

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.

Retrieves the PSS memory used by the process as given by the smaps.

Returns the count of external allocation requests made by the current thread. The external allocation tracking feature was removed in Honeycomb. This method exists for compatibility and always returns 0.

Returns the global count of bytes externally allocated. The external allocation tracking feature was removed in Honeycomb. This method exists for compatibility and always returns 0.

Determine if a debugger is currently attached.

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

Resets the global count of external allocation requests. The external allocation tracking feature was removed in Honeycomb. This method exists for compatibility and has no effect.

Resets the global count of bytes externally allocated. The external allocation tracking feature was removed in Honeycomb. This method exists for compatibility and has no effect.

Resets the global count of freed external allocations. The external allocation tracking feature was removed in Honeycomb. This method exists for compatibility and has no effect.

Resets the global count counter of freed bytes from external allocations. The external allocation tracking feature was removed in Honeycomb. This method exists for compatibility and has no effect.

Resets the count of external allocation requests made by the current thread. The external allocation tracking feature was removed in Honeycomb. This method exists for compatibility and has no effect.

Resets the count of bytes externally allocated by the current thread. The external allocation tracking feature was removed in Honeycomb. This method exists for compatibility and has no effect.

Establish an object allocation limit in the current thread. This feature was never enabled in release builds. The allocation limits feature was removed in Honeycomb. This method exists for compatibility and always returns -1 and has no effect.

Establish a global object allocation limit. This feature was never enabled in release builds. The allocation limits feature was removed in Honeycomb. This method exists for compatibility and always returns -1 and has no effect.

Start counting the number and aggregate size of memory allocations.

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 various get functions return the specified value. And the various reset functions reset the specified count.

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 with default log name and buffer size. See Traceview: A Graphical Log Viewer for information about reading these files. Call stopMethodTracing() to stop tracing.

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, 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.

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 counting the number and aggregate size of memory allocations.

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.