Dalvik Debug Monitor Service

Android ships with a debugging tool called the Dalvik Debug Monitor Server (DDMS), which provides port-forwarding services, screen capture on the device, thread and heap information on the device, logcat, process, and radio state information, incoming call and SMS spoofing, location data spoofing, and more. This page provides a modest discussion of DDMS features; it is not an exhaustive exploration of all the features and capabilities.

Dalvik Debug Monitor Service Manual
Dalvik Debug Monitor Server Ddms

DDMS ships in the tools/ directory of the SDK. Enter this directory from a terminal/console and type ddms (or ./ddms on Mac/Linux) to run it. DDMS will work with both the emulator and a connected device. If both are connected and running simultaneously, DDMS defaults to the emulator.

Dalvik Debug Monitor Service. Computing » Software. Add to My List Edit this Entry Rate it: (1.00 / 2 votes) Translation Find a translation for Dalvik Debug Monitor Service in other languages: Select another language: - Select - 简体中文 (Chinese - Simplified) 繁體中文 (Chinese - Traditional). Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube. The Android Device Monitor is a stand-alone tool with a graphical user interface for serveral Android application debugging and analysis tools, including the Dalvik Debug Monitor Server (DDMS). You can use the Android Device Monitor to analyze memory usage, profile methods, monitor network traffic and simulate incoming calls and messages.

How DDMS works

DDMS acts as a middleman to connect the IDE to the applications running onthe device. On Android, every application runs in its own process, each of which hosts its own virtual machine (VM). And each processlistens for a debugger on a different port.

When it starts, DDMS connects to adb and starts a device monitoring service between the two, which will notify DDMS when a device isconnected or disconnected. When a device is connected, a VM monitoring service is createdbetween adb and DDMS, which will notify DDMS when a VM on the device is started or terminated. Once a VM is running, DDMS retrieves the the VM's process ID (pid), via adb,and opens a connection to the VM's debugger, through the adb daemon (adbd) on the device. DDMS can now talk to the VM using a custom wire protocol.

For each VM on the device, DDMS opens a port upon which it will listen for a debugger. For the first VM, DDMS listens for a debugger on port 8600, the next on 8601, and so on. When a debugger connects to one of these ports, all traffic is forwarded between the debugger and the associated VM. Debugging can then process like any remote debugging session.

DDMS also opens another local port, the DDMS 'base port' (8700, by default), upon which it also listens for a debugger. When a debugger connects to this base port, all traffic is forwarded to the VM currently selected in DDMS, so this is typically where you debugger should connect.

For more information on port-forwarding with DDMS,read Configuring your IDE to attachto port 8700 for debugging.

Tip:You can set a number of DDMS preferences in File >Preferences.Preferences are saved to '$HOME/.ddmsrc'.

Known debugging issues with Dalvik
Debugging an application in the Dalvik VM should work the same as it doesin other VMs. However, when single-stepping out of synchronized code, the 'current line'cursor may jump to the last line in the method for one step.

Left Pane

The left side of the Debug Monitor shows each emulator/device currently found, with a list of all the VMs currently running within each. VMs are identified by the package name of the application it hosts.

Use this list to find and attach to the VM running the activity(ies) that you want to debug. Next to each VM in the list is a 'debugger pass-through' port (in the right-most column). If you connect your debugger to one of the the ports listed, you will be connected to the corresponding VM on the device. However, when using DDMS, you need only connect to port 8700, as DDMS forwards all traffic here to the currently selected VM. (Notice, as you select a VM in the list, the listed port includes 8700.) This way, there's no need to reconfigure the debugger's port each time you switch between VMs.

When an application running on the device calls waitForDebugger() (or you select this option in the developer options), a red icon will be shown next to the client name, while it waits for the debugger to attach to the VM. When a debugger is connected, the icon will turn green.

If you see a crossed-out bug icon, this means that the DDMS was unable to complete a connection between the debugger and the VM because it was unable to open the VM's local port.If you see this for all VMs on the device, it is likely because you have another instance ofDDMS running (this includes the Eclipse plugin).

If you see a question mark in place of an application package, this means that, once DDMS received the application pid from adb, itsomehow failed to make a successful handshake with the VM process. Try restarting DDMS.

Right pane

On the right side, the Debug Monitor provides tabs that display useful information and some pretty cool tools.

Dalvik Debug Monitor Service Manual

Info

This view shows some general information about the selected VM, including the process ID, package name, and VM version.

Threads

The threads view has a list of threads running in the process of the target VM. To reduce the amount of data sent over the wire, the thread updates are only sent when explicitly enabled by toggling the 'threads' button in the toolbar. This toggle is maintained per VM. This tab includes the following information:

ID - a VM-assigned unique thread ID. In Dalvik, these are odd numbers starting from 3.
Tid - the Linux thread ID. For the main thread in a process, this will match the process ID.
Status - the VM thread status. Daemon threads are shown with an asterisk (*). This will be one of the following:
- running - executing application code
- sleeping - called Thread.sleep()
- monitor - waiting to acquire a monitor lock
- wait - in Object.wait()
- native - executing native code
- vmwait - waiting on a VM resource
- zombie - thread is in the process of dying
- init - thread is initializing (you shouldn't see this)
- starting - thread is about to start (you shouldn't see this either)
utime - cumulative time spent executing user code, in 'jiffies' (usually 10ms).
stime - cumulative time spent executing system code, in 'jiffies' (usually 10ms).
Name - the name of the thread

'ID' and 'Name' are set when the thread is started. The remaining fields are updated periodically (default is every 4 seconds).

VM Heap

Displays some heap stats, updated during garbage collection. If, when a VM is selected,the VM Heap view says that heap updates are not enabled, click the 'Show heap updates' button, located in the top-left toolbar. Back in the VM Heap view, click Cause GC to perform garbage collection and update the heap stats.

Allocation Tracker

In this view, you can track the memory allocation of each virtual machine.With a VM selected in the left pane, click Start Tracking, then Get Allocations to view all allocations since tracking started. The table below will be filled with all the relevantdata. Click it again to refresh the list.

Emulator Control

With these controls, you can simulate special device states and activities.Features include:

Telephony Status - change the state of the phone's Voice and Data plans (home, roaming, searching, etc.), and simulate different kinds of network Speed and Latency (GPRS, EDGE, UTMS, etc.).
Telephony Actions - perform simulated phone calls and SMS messages to the emulator.
Location Controls - send mock location data to the emulator so that you can perform location-aware operations like GPS mapping.
To use the Location Controls, launch your application in the Android emulator and open DDMS. Click the Emulator Controls tab and scroll down to Location Controls.From here, you can:
- Manually send individual longitude/latitude coordinates to the device.
  Click Manual, select the coordinate format, fill in the fields and click Send.
- Use a GPX file describing a route for playback to the device.
  Click GPX and load the file. Once loaded, click the play button to playback the route for your location-aware application.
  When performing playback from GPX, you can adjust the speed of playback from the DDMS panel and control playback with the pause and skip buttons. DDMS will parse both the waypoints (<wpt>, in the first table), and the tracks (<trk>, in the second table, with support for multiple segments, <trkseg>, although they are simply concatenated). Only the tracks can be played. Clicking a waypoint in the first list simply sends its coordinate to the device, while selecting a track lets you play it.
- Use a KML file describing individual placemarks for sequenced playback to the device.
  Click KML and load the file. Once loaded, click the play button to send the coordinates to your location-aware application.
  When using a KML file, it is parsed for a <coordinates> element. The value of which should be a single set of longitude, latitude and altitude figures. For example:
  In your file, you may include multiple <Placemark> elements, each containing a <coordinates> element. When you do so, the collection of placemarks will be added as tracks. DDMS will send one placemark per second to the device.
  One way to generate a suitable KML file is to find a location in Google Earth. Right-click the location entry that appears on the left and select 'Save place as...' with the save format set to Kml.
  Note: DDMS does not support routes created with the <MultiGeometry><LineString>lat1, long1, lat2, long2, ....</LineString></MultiGeometry> methods. There is also currently no support for the <TimeStamp> node inside the <Placemark>. Future releases may support timed placement and routes within a single coordinate element.
For additional methods of setting up mocks of location-based data, see the Location topic.

File Explorer

With the File Explorer, you can view the device file system and perform basic management, like pushing and pulling files. This circumvents using the adbpush and pull commands, with a GUI experience.

With DDMS open, select Device >File Explorer... to open theFile Explorer window. You can drag-and-drop into the device directories, but cannot drag out of them.To copy files from the device, select the file and click the Pull File from Devicebutton in the toolbar. To delete files, use the Delete button in the toolbar.

If you're interested in using an SD card image on the emulator, you're still required to usethe mksdcard command to create an image, and then mount it during emulator bootup. For example, from the /tools directory, execute:

Now, when the emulator is running, the DDMS File Explorer will be able to read and write to the sdcard directory. However, your files may not appear automatically. For example, if you add anMP3 file to the sdcard, the media player won't see them until you restart the emulator. (When restartingthe emulator from command line, be sure to mount the sdcard again.)

For more information on creating an SD card image, see the Other Tools document.

Screen Capture

You can capture screen images on the device or emulator by selecting Device > Screen capture... in the menu bar, or press CTRL-S. Be sure to select a device first.

Exploring Processes

You can see the output of ps -x for a specific VM by selecting Device > Show process status... in the menu bar.

Cause a GC to Occur

Cause garbage collection to occur in the selected application by pressing the trash can button on the toolbar.

Running Dumpsys and Dumpstate on the Device (logcat)

To run dumpsys (logcat) from Dalvik, select Device > Run logcat... in the menu bar.
To run dumpstate from Dalvik, select Device > Dump device state... in the menu bar.

Examine Radio State

By default, radio state is not output during a standard logcat (it is a lot of information). To see radio information, either click Device > Dump radio state... or run logcat as described in Logging Radio Information.

Stop a Virtual Machine

You can stop a virtual machine by selecting Actions > HaltVM. Pressing this button causes the VM to call Runtime.halt(1).

Known issues with DDMS

DDMS has the following known limitations:

If you connect and disconnect a debugger, ddms drops and reconnects the client so the VM realizes that the debugger has gone away. This will be fixed eventually.

In this document

Use the System Log
Work with Breakpoints

Run your App in Debug Mode

Figure 1. The Choose Device window enables you to select a physical Android device or a virtual device to debug your app.

To run your app in debug mode, you build an APK signed with a debug key and install it on aphysical Android device or on the Android emulator.To set up an Android device for development, see UsingHardware Devices. For more information about the emulator provided by the Android SDK, seeUsing the Emulator.

To debug your app in Android Studio:

Open your project in Android Studio.
Click Debug in the toolbar.
On the Choose Device window, select a hardware device from the list or choose a virtual device.
Click OK. Your app starts on the selected device.

Figure 1 shows the Choose Device window. The list shows all the Android devicesconnected to your computer. Select Launch Emulator to use an Android virtual deviceinstead. Click the ellipsis to open theAndroid Virtual Device Manager.

Android Studio opens the Debug tool window when you debug your app. To open theDebug window manually, click Debug.This window shows threads and variables in the Debugger tab, the device status in theConsole tab, and the system log in the Logcat tab. The Debug toolwindow also provides other debugging tools covered in the following sections.

Figure 2. The Debug tool window in Android Studio showingthe current thread and the object tree for a variable.

Use the System Log

The system log shows system messages while you debug your app. These messages includeinformation from apps running on the device. If you want to use thesystem log to debug your app, make sure your code writes log messages and prints the stacktrace for exceptions while your app is in the development phase.

Write log messages in your code

To write log messages in your code, use the Log class. Log messageshelp you understand the execution flow by collecting the system debug output while you interactwith your app. Log messages can tell you what part of your application failed. For moreinformation about logging, see Reading and Writing Logs.

The following example shows how you might add log messages to determine if previous stateinformation is available when your activity starts:

During development, your code can also catch exceptions and write the stack trace to the systemlog:

Note: Remove debug log messages and stack trace print calls fromyour code when you are ready to publish your app. You could do this by setting a DEBUGflag and placing debug log messages inside conditional statements.

View the system log

Both the Android DDMS (Dalvik Debug Monitor Server) and the Debug tool windowsshow the system log; however, the Android DDMS tool window lets you view only log messagesfor a particular process. To view the system log on the Android DDMS tool window:

Start your app as described in Run your App in Debug Mode.
Click Android to open the Android DDMS tool window.
If the system log is empty in the Logcat view, click Restart .

Figure 4. The system log in the Android DDMS toolwindow.

The Android DDMS tool window gives you access to some DDMS features from Android Studio.For more information about DDMS, see Using DDMS.

The system log shows messages from Android services and other Android apps. To filter the logmessages to view only the ones you are interested in, use the tools in the Android DDMSwindow:

To show only log messages for a particular process, select the process in the Devices view and then click Only Show Logcat from Selected Process . If the Devices view is not available, click Restore Devices View on the right of the Android DDMS tool window. This button is only visible when you hide the Devices window.
To filter log messages by log level, select a level under Log Level on the top of the Android DDMS window.
To show only log messages that contain a particular string, enter the string in the search box and press Enter.

Work with Breakpoints

Breakpoints enable you to pause the execution of your app at a particular line of code, examinevariables, evaluate expressions, and continue the execution line by line. Use breakpoints todetermine the causes of run-time errors that you can't fix by looking at your code only. To debugyour app using breakpoints:

Open the source file in which you want to set a breakpoint.
Locate the line where you want to set a breakpoint and click on it.
Click on the yellow portion of the side bar to the left of this line, as shown in figure 5.
Start your app as described in Run your App in Debug Mode.

Android Studio pauses the execution of your app when it reaches the breakpoint. You can thenuse the tools in the Debug tool window to identify the cause of the error.

Figure 5. A red dot appears next to the line when you seta breakpoint.

View and configure breakpoints

To view all the breakpoints and configure breakpoint settings, click ViewBreakpoints on the left side of the Debug toolwindow. The Breakpoints window appears, as shown in figure 6.

Figure 6. The Breakpoints window lists all the currentbreakpoints and includes behavior settings for each.

The Breakpoints window lets you enable or disable each breakpoint from thelist on the left. If a breakpoint is disabled, Android Studio does not pause your app whenit hits that breakpoint. Select a breakpoint from the list to configure its settings.You can configure a breakpoint to be disabled at first and have the system enable it after adifferent breakpoint is hit. You can also configure whether a breakpoint should be disabled afterit is hit. To set a breakpoint for any exception, select Exception Breakpointsin the list of breakpoints.

Debug your app with breakpoints

After you set breakpoints in your code, click Rerun to start the app again. When a breakpoint ishit, Android Studio pauses the app and highlights the breakpoint in the source code. TheDebug tool window lets you examine variables and control the execution step bystep:

To examine the object tree for a variable, expand it in the Variables view. If the Variables view is not visible, click Restore Variables View .
To evaluate an expression at the current execution point, click Evaluate Expression .
To advance to the next line in the code (without entering a method), click Step Over .
To advance to the first line inside a method call, click Step Into .
To advance to the next line outside the current method, click Step Out .
To continue running the app normally, click Resume Program .

Figure 7. The Variables view in the Debug tool window.

Track Object Allocation

Android Studio lets you track objects that are being allocated on the Java heap and see whichclasses and threads are allocating these objects. This allows you to see the list of objectsallocated during a period of interest. This information is valuable for assessing memory usagethat can affect application performance.

To track memory allocation of objects:

Start your app as described in Run Your App in Debug Mode.
Click Android to open the Android DDMStool window.
On the Android DDMS tool window, select the Devices | logcat tab.
Select your device from the dropdown list.
Select your app by its package name from the list of running apps.
Click Start Allocation Tracking
Interact with your app on the device.
Click Stop Allocation Tracking

Android Studio shows the objects that the system allocated with the following information:

Allocation order
Allocated class
Allocation size
Thread ID
Allocation method, class, and line number
Stack trace at the point of allocation

Figure 8. Object allocation tracking in Android Studio.

Analyze Runtime Metrics to Optimize your App

Even if your application does not generate runtime errors, this does not mean it is free ofproblems. You should also consider the following issues:

Does your app use memory efficiently?
Does your app generate unnecessary network traffic?
What methods should you focus your attention on to improve the performance of your app?
Does your app behave properly when the user receives a phone call or a message?

The Android Device Monitor is a stand-alone tool with a graphical user interface for serveralAndroid application debugging and analysis tools, including the Dalvik Debug Monitor Server (DDMS).You can use the Android Device Monitor to analyze memory usage, profile methods,monitor network traffic and simulate incoming calls and messages.

To open the Android Device Monitor from Android Studio, clickMonitor on the toolbar. The Android Device Monitoropens in a new window.

For more information about the Android Device Monitor and DDMS, seeDevice Monitor andUsing DDMS.

Capture Screenshots and Videos

Android Studio enables you to capture a screenshot or a short video of the device screenwhile your app is running. Screenshots and videos are useful as promotional materials for yourapp, and you can also attach them to bug reports that you send to your development team.

To take a screenshot of your app:

Start your app as described in Run your App in Debug Mode.
Click Android to open the Android DDMS tool window.
Click Screen Capture on the left side of the Android DDMS tool window.
Optional: To add a device frame around your screenshot, enable the Frame screenshot option.
Click Save.

To take a video recording of your app:

Dalvik Debug Monitor Server Ddms

Start your app as described in Run your App in Debug Mode.
Click Android to open the Android DDMS tool window.
Click Screen Record on the left side of the Android DDMS tool window.
Click Start Recording.
Interact with your app.
Click Stop Recording.
Enter a file name for the recording and click OK.

Foxrc377