Dalvik Debug Monitor Service

Posted : admin | On 16-09-2021

Dalvik Debug Monitoring Service: B. Dalvik Design Memory Service: C. Dalvik Debug Memory Service: D. Dalvik Design Monitoring Service: Q. Choose the correct option regarding Activity in Android. An activity is a window that contains the user interface of your application. Dalvik is the name of Android’s virtual machine. The Dalvik VM is an interpreter-only virtual machine that executes files in the Dalvik Executable (.dex) format. The virtual machine is register-based and can run classes compiled by Java language compiler that have been altered into its native format using the included ‘dx’ tool. Quick guide of DDMS (Dalvik Debug Monitor Service) in Eclipse to work with Android. It will help us to create better applications. It will help us to create better applications. Android ships with a debugging tool called the Dalvik Debug Monitor Service (DDMS), which provides port-forwarding services, screen capture on the device, thread. Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

Dalvik Debug Monitor Service (ddms) Does Not Provide

Dalvik debug monitor service manual

In this document

  1. Using DDMS

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.

Running DDMS

DDMS is integrated into Eclipse and is also shipped in the tools/ directory of the SDK. DDMS works with both the emulator and a connected device. If both are connected and running simultaneously, DDMS defaults to the emulator.

  • From Eclipse: Click Window > Open Perspective > Other... > DDMS.
  • From the command line: Type ddms (or ./ddms on Mac/Linux) from the tools/ directory.

How DDMS Interacts with a Debugger

On Android, every application runs in its own process, each of which runs in its own virtual machine (VM). Each VM exposes a unique port that a debugger can attach to.

When DDMS starts, it connects to adb. When a device is connected, a VM monitoring service is created between adb and DDMS, which notifies 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.

DDMS assigns a debugging port to each VM on the device. Typically, DDMS assigns port 8600 for the first debuggable VM, the next on 8601, and so on. When a debugger connects to one of these ports, all traffic is forwarded to the debugger from the associated VM. You can only attach a single debugger to a single port, but DDMS can handle multiple, attached debuggers.

By default, DDMS also listens on another debugging port, the DDMS 'base port' (8700, by default). The base port is a port forwarder, which can accept VM traffic from any debugging port and forward it to the debugger on port 8700. This allows you to attach one debugger to port 8700, and debug all the VMs on a device. The traffic that is forwarded is determined by the currently selected process in the DDMS Devices view.

The following screenshot shows a typical DDMS screen in Eclipse. If you are starting DDMS from the command line, the screen is slightly different, but much of the functionality is identical. Notice that the highlighted process, com.android.email, that is running in the emulator has the debugging port 8700 assigned to it as well as 8606. This signifies that DDMS is currently forwarding port 8606 to the static debugging port of 8700.

Figure 1. Screenshot of DDMS

If you are not using Eclipse and ADT, read Configuring your IDE to attach to the debugging port, for more information on attaching your debugger.

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

Known debugging issues with Dalvik
Debugging an application in the Dalvik VM should work the same as it does in 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.

Using DDMS

The following sections describe how to use DDMS and the various tabs and panes that are part of the DDMS GUI. The Eclipse version and the command line version have minor UI differences, but the same functionality. For information on running DDMS, see the previous section in this document, Running DDMS.

Viewing heap usage for a process

DDMS allows you to view how much heap memory a process is using. This information is useful in tracking heap usage at a certain point of time during the execution of your application.

To view heap usage for a process:

  1. In the Devices tab, select the process that you want to see the heap information for.
  2. Click the Update Heap button to enable heap information for the process.
  3. In the Heap tab, click Cause GC to invoke garbage collection, which enables the collection of heap data. When the operation completes, you will see a group of object types and the memory that has been allocated for each type. You can click Cause GC again to refresh the data.
  4. Click on an object type in the list to see a bar graph that shows the number of objects allocated for a particular memory size in bytes.

Tracking memory allocation of objects

DDMS provides a feature to track objects that are being allocated to memory and to see which classes and threads are allocating the objects. This allows you to track, in real time, where objects are being allocated when you perform certain actions in your application. This information is valuable for assessing memory usage that can affect application performance.

To track memory allocation of objects:

  1. In the Devices tab, select the process that you want to enable allocation tracking for.
  2. In the Allocation Tracker tab, click the Start Tracking button to begin allocation tracking. At this point, anything you do in your application will be tracked.
  3. Click Get Allocations to see a list of objects that have been allocated since you clicked on the Start Tracking button. You can click on Get Allocations again to append to the list new objects that that have been allocated.
  4. To stop tracking or to clear the data and start over, click the Stop Tracking button.
  5. Click on a specific row in the list to see more detailed information such as the method and line number of the code that allocated the object.

Working with an emulator or device's file system

DDMS provides a File Explorer tab that allows you to view, copy, and delete files on the device. This feature is useful in examining files that are created by your application or if you want to transfer files to and from the device.

To work with an emulator or device's file system:

  1. In the Devices tab, select the emulator that you want to view the file system for.
  2. To copy a file from the device, locate the file in the File Explorer and click the Pull file button.
  3. To copy a file to the device, click the Push file button on the File Explorer tab.
Dalvik

Examining thread information

The Threads tab in DDMS shows you the currently running threads for a selected process.

  1. In the Devices tab, select the process that you want to examine the threads for.
  2. Click the Update Threads button.
  3. In the Threads tab, you can view the thread information for the selected process.

Starting method profiling

Method profiling is a means to track certain metrics about a method, such as number of calls, execution time, and time spent executing the method. If you want more granular control over where profiling data is collected, use the startMethodTracing() and stopMethodTracing() methods. For more information about generating trace logs, see Profiling and Debugging UIs.

Before you start method profiling in DDMS, be aware of the following restrictions:

  • Android 1.5 devices are not supported.
  • Android 2.1 and earlier devices must have an SD card present and your application must have permission to write to the SD card.
  • Android 2.2 and later devices do not need an SD card. The trace log files are streamed directly to your development machine.

To start method profiling:

  1. On the Devices tab, select the process that you want to enable method profiling for.
  2. Click the Start Method Profiling button.
  3. Interact with your application to start the methods that you want to profile.
  4. Click the Stop Method Profiling button. DDMS stops profiling your application and opens Traceview with the method profiling information that was collected between the time you clicked on Start Method Profiling and Stop Method Profiling.

Using the Network Traffic tool

In Android 4.0, the DDMS (Dalvik Debug Monitor Server) includes a DetailedNetwork Usage tab that makes it possible to track when your application ismaking network requests. Using this tool, you can monitor how and when your apptransfers data and optimize the underlying code appropriately. You can alsodistinguish between different traffic types by applying a “tag” to networksockets before use.

These tags are shown in a stack area chart in DDMS, as shown in figure 2:

Figure 2. Network Usage tab.

By monitoring the frequency of your data transfers, and the amount of datatransferred during each connection, you can identify areas of your applicationthat can be made more battery-efficient. Generally, you should look forshort spikes that can be delayed, or that should cause a later transfer to bepre-empted.

To better identify the cause of transfer spikes, theTrafficStats API allows youto tag the data transfers occurring within a thread using setThreadStatsTag(), followedby manually tagging (and untagging) individual sockets using tagSocket() and untagSocket(). For example:

Alternatively, the Apache HttpClient and URLConnection APIs included in the platformautomatically tag sockets internally based on the active tag (as identified by getThreadStatsTag()).These APIs correctly tag/untag sockets when recycled throughkeep-alive pools. In the following example, setThreadStatsTag() sets the active tag to be 0xF00D. There can only be one active tag per thread. That is the value that will be returned by getThreadStatsTag()and thus used by HttpClient to tag sockets. The finally statement invokes clearThreadStatsTag() to clear the tag.

Socket tagging is supported in Android 4.0, but real-time stats will only bedisplayed on devices running Android 4.0.3 or higher.

Using LogCat

LogCat is integrated into DDMS, and outputs the messages that you print out using the Log class along with other system messages such as stack traces when exceptions are thrown. View the Reading and Writing Log Messages. topic for more information on how to log messages to the LogCat.

When you have set up your logging, you can use the LogCat feature of DDMS to filter certain messages with the following buttons:

  • Verbose
  • Debug
  • Info
  • Warn
  • Error

You can also setup your own custom filter to specify more details such as filtering messages with the log tags or with the process id that generated the log message. The add filter, edit filter, and delete filter buttons let you manage your custom filters.

Emulating phone operations and location

The Emulator control tab lets you simulate a phone's voice and data network status. This is useful when you want to test your application's robustness in differing network environments.

Changing network state, speed, and latency

The Telephony Status section of the Emulator controls tab lets you change different aspects of the phone's networks status, speed and latency. The following options are available to you and are effective immediately after you set them:

  • Voice - unregistered, home, roaming, searching, denied
  • Data - unregistered, home, roaming, searching, denied
  • Speed - Full, GSM, HSCSD, GPRS, EDGE, UMTS, HSDPA
  • Latency - GPRS, EDGE, UMTS

Spoofing calls or SMS text messages

The Telephony Actions section of the Emulator controls tab lets you spoof calls and messages. This is useful when you want to to test your application's robustness in responding to incoming calls and messages that are sent to the phone. The following actions are available to you:

  • Voice - Enter a number in the Incoming number field and click Call to send a simulated call to the emulator or phone. Click the Hang up button to terminate the call.
  • SMS - Enter a number in the Incoming number field and a message in the Message: field and click the Send button to send the message.

Setting the location of the phone

If your application depends on the location of the phone, you can have DDMS send your device or AVD a mock location. This is useful if you want to test different aspects of your application's location specific features without physically moving. The following geolocation data types are available to you:

  • Manual - set the location by manually specifying decimal or sexagesimal longitude and latitude values.
  • GPX - GPS eXchange file
  • KML - Keyhole Markup Language file
For more information about providing mock location data, see Location Strategies.

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.

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.

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

Dalvik Debug Monitor Service

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.

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.

Dalvik Debug Monitor Server

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

Dalvik Debug Monitor Server Ddms

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.

Dalvik Debug Monitor Service

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

Dalvik debug monitor service

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.