Debugging android applications

Debugging Tools

adb  acts as a middleman between a device and yourdevelopment system. It provides various device management capabilities,including moving and syncing files to the emulator, running a UNIX shell on thedevice or emulator, and providing a general means to communicate with connectedemulators and devices.

DDMS  is a graphical program that communicates withyour devices through adb. DDMS can capture screenshots, gather thread and stackinformation, spoof incoming calls and SMS messages, and has many otherfeatures.

Device or Android Virtual Device  Your application must run in a device or inan AVD so that it can be debugged. An adb device daemon runs on the device oremulator and provides a means for the adb host daemon to communicate with thedevice or emulator.

 

JDWP debugger The Dalvik VM (Virtual Machine) supports the JDWP protocol to allowdebuggers to attach to a VM. Each application runs in a VM and exposes a uniqueport that you can attach a debugger to via DDMS. If you want to debug multipleapplications, attaching to each port might become tedious, so DDMS provides aport forwarding feature that can forward a specific VM's debugging port to port8700. You can switch freely from application to application by highlighting itin the Devices tab of DDMS. DDMS forwards the appropriate port to port 8700.Most modern Java IDEs include a JDWP debugger, or you can use a command linedebugger such asjdb.

 

Fig. 1 a typical debugging environment.

Additional Debugging Tools:

Heirarchy Viewer andlayoutopt    Graphical programs that let you debug andprofile user interfaces.

Traceview   A graphical viewer that displays trace file data for method calls andtimes saved by your application, which can help you profile the performance ofyour application.

Dev Tools Androidapplication    The Dev Tools application included in theemulator system image exposes several settings that provide useful informationsuch as CPU usage and frame rate. You can also transfer the application to ahardware device.

 

Debugging Tips

While debugging, keep these helpfultips in mind to help you figure out common problems with your applications:

Dump the stack trace

To obtain a stack dump from emulator, you can log in with adb shell, use psto find the process you want, and then kill -3. The stack trace appears in the log file.

Display useful info on the emulatorscreen

The device can display useful information such as CPU usageor highlights around redrawn areas. Turn these features on and off in thedeveloper settings window as described inDebuggingwith the Dev Tools App.

Get application and system stateinformation from the emulator

You can access dumpstate information from the adb shell commands. See dumpsys anddumpstate on the adb topic page.

Get wireless connectivityinformation

You can get information about wireless connectivity usingDDMS. From the Device menu, select Dump radio state.

Log trace data

You can log method calls and other tracing data in anactivity by calling startMethodTracing(). SeeProfiling with Traceviewand dmtracedump for details.

Log radio data

By default, radio information is not logged to the system(it is a lot of data). However, you can enable radio logging using thefollowing commands:

adb shell

logcat -b radio

Capture screenshots

The Dalvik Debug Monitor Server (DDMS) can capturescreenshots from the emulator. SelectDevice > Screen capture.

Use debugging helper classes

Android provides debug helper classes such as util.Log and Debug for your convenience.

See the Troubleshootingdocument for answers to some common developing and debugging issues.

Using DDMS

·        Viewingheap usage for a process

·        Trackingmemory allocation of objects

·        Examiningthread information

·        methodprofiling

·        UsingLogcat

·        …

 

procrank

procrank will show you a quick summary of process memoryutilization. By default, it shows Vss, Rss, Pss and Uss, and sorts by Vss.However, you can control the sorting order.

procrank source is included in system/extras/procrank, andthe binary is located in /system/xbin on an android device.

• Vss = virtual set size
• Rss = resident set size
• Pss = proportional set size
• Uss = unique set size

In general, the two numbers you want to watch are the Pssand Uss (Vss and Rss are generally worthless, because they don't accuratelyreflect a process's usage of pages shared with other processes.)

• Uss is the set of pages that are unique to a process. This is the amount of memory that would be freed if the application was terminated right now.
• Pss is the amount of memory shared with other processes, accounted in a way that the amount is divided evenly between the processes that share it. This is memory that would not be released if the process was terminated, but is indicative of the amount that this process is "contributing" to the overall memory load.

You can also use procrank to view the working set size ofeach process, and to reset the working set size counters.

Here is procrank's usage:

# procrank -h

Usage: procrank [ -W ] [ -v | -r | -p | -u | -h ]

    -v  Sort by VSS.

    -r  Sort by RSS.

    -p  Sort by PSS.

    -u  Sort by USS.

        (Default sort order is PSS.)

    -R  Reverse sort order (default is descending).

    -w  Display statistics for working set only.

    -W  Reset working set of all processes.

    -h  Display this help screen.

And here is some sample output:

# procrank

  PID      Vss      Rss      Pss      Uss  cmdline

 1217   36848K   35648K   17983K   13956K  system_server

 1276   32200K   32200K   14048K   10116K  android.process.acore

 1189   26920K   26920K    9293K    5500K  zygote

 1321   20328K   20328K    4743K    2344K  android.process.media

 1356   20360K   20360K    4621K    2148K  com.android.email

Dalvik Heap

The Dalvik heap is preloaded with classes and data byzygote (loading over 1900 classes as of Android version 2.2). When zygote forksto start an android application, the new application gets a copy-on-writemapping of this heap. As Dan Borstein says below, this helps with memoryreduction as well as application startup time.

Dalvik, like virtual machines for many other languages,does garbage collection on the heap. There appears to be a separate thread(called the HeapWorker) in each VM process that performs the garbage collectionactions. (See toolbox ps -t) [need more notes on the garbage collection]

Dan Borstein said this about heap sharing^[1]:

It's used in Android to amortizethe RAM footprint of the large amount of effectively-read-only data(technically writable but rarely actually written) associated with commonlibrary classes across all active VM processes. 1000+ classes get preloaded bythe system at boot time, and each class consumes at least a little heap foritself, including often pointing off to a constellation of other objects. Theheap created by the preloading process gets shared copy-on-write with eachspawned VM process (but again doesn't in practice get written much). This saveshundreds of kB of dirty unpageable RAM per process and also helps speed upprocess startup.