Android Debugging 1

Android debugging

Summary

Overview Debugging Environment ADB

Reading and writing logs Logcat

Progress



Overview (1/3) The Android SDK provides most of the tools that you need to debug your

applications

You need a JDWP-compliant debugger if you want to be able to do thingssuch as: Step through code Step through code

View variable values

Pause execution of an application

If you are using Eclipse, a JDWP-compliant debugger is already includedand there is no setup required

If you are using another IDE, you can use the debugger that comes with itand attach the debugger to a special port so it can communicate with theapplication VMs on your devices

Overview (2/3) The main components that comprise a typical Android debugging

environment are: adb - acts as a middleman between a device and your development system. It provides

various device management capabilities, including moving and syncing files to the emulator,running a UNIX shell on the device or emulator, and providing a general means tocommunicate with connected emulators and devices.

Dalvik Debug Monitor Server - DDMS is a graphical program that communicates with yourdevices through adb. DDMS can capture screenshots, gather thread and stack information,spoof incoming calls and SMS messages, and has many other features.

Device/Android Virtual Device - Your application must run in a device or in an AVD so thatit can be debugged. An adb device daemon runs on the device or emulator and provides ameans for the adb host daemon to communicate with the device or emulator.

JDWP - The Dalvik VM (Virtual Machine) supports the JDWP protocol to allow debuggers toattach to a VM. Each application runs in a VM and exposes a unique port that you can attacha debugger to via DDMS. Most modern Java IDEs include a JDWP debugger, or you can usea command line debugger such as jdb.

Overview (3/3) We will focus on the following:

Debugging native code

Locating the problem using one of the (or usually all of the) following: adb

Loging using Log class/Logcat

Debugging using GDB

What is the best solution for debugging on Android?

Progress



Debugging Environment

Progress



Android Debug BridgeADB

Android Debug Bridge (adb) is a versatile tool lets you manage the state ofan emulator instance or Android-powered device. It is a client-serverprogram that includes three components: A client, which runs on your development machine. You can invoke a client from a shell by

issuing an adb command. Other Android tools such as the ADT plugin and DDMS also createadb clients.

A server, which runs as a background process on your development machine. The servermanages communication between the client and the adb daemon running on an emulator ordevice.

A daemon, which runs as a background process on each emulator or device instance.

When you start an adb client, the client first checks whether there is an adbserver process already running.

If there isn't, it starts the server process. When the server starts, it binds tolocal TCP port 5037 and listens for commands sent from adb clientsalladb clients use port 5037 to communicate with the adb server.

ADBIssuing adb Commands

You can issue adb commands from a command line on your developmentmachine or from a script. The usage is:

When you issue a command, the program invokes an adb client. The client is not specifically associated with any emulator instance, so if

adb [-d|-e|-s ]

The client is not specifically associated with any emulator instance, so ifmultiple emulators/devices are running, you need to use the -d option tospecify the target instance to which the command should be directed.

ADBEmulator/Device Instances

Before issuing adb commands, it is helpful to know what emulator/deviceinstances are connected to the adb server.

You can generate a list of attached emulators/devices usingthe devices command:

adb devices

Here's an example showing the devices command and its output:$ adb devicesList of devices attachedemulator-5554 deviceemulator-5556 deviceemulator-5558 device

ADBDirecting Commands to a Specific

Emulator/Device Instance

If multiple emulator/device instances are running, you need to specify atarget instance when issuing adb commands.

To do so, use the -s option in the commands. The usage for the -s option is:

As shown, you specify the target instance for a command using its adb-adb -s

As shown, you specify the target instance for a command using its adb-assigned serial number. You can use the devices command to obtain the serial numbers of running emulator/device instances.

Here is an example:

Note that, if you issue a command without specifying a target emulator/device instance using -s, adb generates an error.

adb -s emulator-5556 install helloWorld.apk

ADBMore useful tips

Forwarding Ports You can use the forward command to set up arbitrary port forwarding

forwarding of requests on a specific host port to a different port on anemulator/device instance.

Here's how you would set up forwarding of host port 6100 to Here's how you would set up forwarding of host port 6100 toemulator/device port 7100:

adb forward tcp:6100 tcp:7100

ADBMore useful tips

Copying Files to or from an Emulator/Device Instance You can use the adb commands pull and push to copy files to and from an

emulator/device instance's data file. The pull and push commands let youcopy arbitrary directories and files to any location in an emulator/deviceinstance.

To copy a file or directory (recursively) from the emulator or device, use:

To copy a file or directory (recursively) to the emulator or device, use:

In the commands, and refer to the paths to the targetfiles/directory on your development machine (local) and on theemulator/device instance (remote).

Here's an example:

adb pull

adb push

adb push foo.txt /sdcard/foo.txt

ADBMore useful tips

Issuing Shell Commands Adb provides an ash shell that you can use to run a variety of commands on

an emulator or device. The command binaries are stored in the file systemof the emulator or device, in this location:

/system/bin/...

You can use the shell command to issue commands, with or without entering the adb remote shell on the emulator/device.

To issue a single command without entering a remote shell, use the shell command like this:

When you are ready to exit the remote shell, use CTRL+D or exit to end the shell session.

/system/bin/...

adb [-d|-e|-s {}] shell

ADBOther Shell Commands

The list below shows several of the adb shell commands available. For acomplete list of commands and programs, start an emulator instance anduse the adb -help command. dumpsys - Dumps system data to the screen.

dumpstate - Dumps state to a file.

logcat []... []... - Enables radio logging and prints output to the screen. dmesg - Prints kernel debugging messages to the screen.

start - Starts (restarts) an emulator/device instance. stop - Stops execution of an emulator/device instance.

Progress



Reading and Writing Logs The Android logging system provides a mechanism for collecting and

viewing system debug output. Logcat dumps a log of system messages, which include things such as

stack traces when the emulator throws an error and messages that youhave written from your application by using the Log class.

You can run LogCat through ADB or from DDMS, which allows you to readthe messages in real time.

The Log class Log is a logging class that you can utilize in your code to print out messages

to the LogCat. Common logging methods include:

v(String, String) (verbose) d(String, String) (debug) d(String, String) (debug) i(String, String) (information) w(String, String) (warning) e(String, String) (error)

For example:

The LogCat will then output something like:

Log.i("MyActivity", "MyClass.getView() get item number " + position);

I/MyActivity( 1557): MyClass.getView() get item number 1

Progress



Using LogCatBasics

You can use LogCat from within DDMS or call it on an ADB shell. To run LogCat, through the ADB shell, the general usage is:

You can use the logcat command from your development computer or froma remote adb shell in an emulator/device instance. To view log output in

[adb] logcat [] ... [] ...

a remote adb shell in an emulator/device instance. To view log output inyour development computer, you use:

and from a remote adb shell you use:

$ adb logcat

# logcat

Using LogCatCommands

The following table describes the logcat command line options: -c, Clears (flushes) the entire log and exits. -d, Dumps the log to the screen and exits.

-f , Writes log message output to . The default is stdout.

-g, Prints the size of the specified log buffer and exits. -g, Prints the size of the specified log buffer and exits.

-n , Sets the maximum number of rotated logs to . Requires the -r option.

-r , Rotates the log file every of output. Requires the -f option.

-s, Sets the default filter spec to silent.

-v , Sets the output format for log messages. The default is brief format.

Using LogCatFiltering log output

Every Android log message has a tag and a priority associated with it. The tag of a log message is a short string indicating the system component

from which the message originates (for example, "View" for the view system).

The priority is one of the following character values, ordered from lowest to highest priority: V Verbose (lowest priority)

D Debug D Debug I Info W Warning E Error F Fatal S Silent (highest priority, on which nothing is ever printed)

To reduce the log output to a manageable level, you can restrict log outputusing filter expressions.

Filter expressions let you indicate to the system the tags-prioritycombinations that you are interested in the system suppresses othermessages for the specified tags.

Using LogCatFiltering log output

Here's an example of a filter expression that suppresses all log messagesexcept those with the tag "ActivityManager", at priority "Info" or above, andall log messages with tag "MyApp", with priority "Debug" or above:

The final element in the above expression, *:S, sets the priority level for alltags to "silent", thus ensuring only log messages with "View" and "MyApp"are displayed.

adb logcat ActivityManager:I MyApp:D *:S

are displayed. Using *:S is an excellent way to ensure that log output is restricted to the

filters that you have explicitly specified it lets your filters serve as a"whitelist" for log output.

The following filter expression displays all log messages with priority level"warning" and higher, on all tags:adb logcat *:W

Using LogCatViewing stdout and stderr

By default, the Android system sends stdout and stderr (System.out and System.err) output to /dev/null.

In processes that run the Dalvik VM, you can have the system write a copyof the output to the log file. In this case, the system writes the messages tothe log using the log tags stdout and stderr, both with priority I.

To route the output in this way, you stop a running emulator/device instanceand then use the shell command setprop to enable the redirection of output.Here's how you do it:Here's how you do it:

The system retains this setting until you terminate the emulator/deviceinstance. To use the setting as a default on the emulator/device instance,you can add an entry to /data/local.prop on the device.

$ adb shell stop$ adb shell setprop log.redirect-stdio true$ adb shell start

Using LogCatCrash caught in logcat

Youll see something like this:I/DEBUG ( 1326): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***I/DEBUG ( 1326): Build fingerprint:

'SigmaDesigns/smp86xx/smp86xx/:2.2.1/FRG83/eng.janjic.20110531.154325:eng/test-keys'

I/DEBUG ( 1326): pid: 1716, tid: 1729 >>> com.android.browser

Using LogCatCrash caught in logcat

Obviously somewhere in libwebcore.so is the problem? What is the line of the code that caused this? Maybe libwebcore.so uses some other library (statically linked)?

First we look at the pc (program counter) Hold the address of the instruction that caused crash

Then we look at the prelink-map for our architecture First we obtain address of the libwebcore.so library (absolute address) First we obtain address of the libwebcore.so library (absolute address) Subtract value in pc (absolute address) from address of the library in prelink-map This gives us the address of the instruction, inside library (relative), that caused crash.

What to do then? We need binary that has all of the symbols in it:

Dump the symbols to a file, and look four our relative address: This will give us the correct line in code that caused the crash

./out/target/product/generic/symbols/system/lib/libwebcore.so

./prebuilt/linux-x86/toolchain/mips-4.4.3/bin/mips-linux-gnu-objdump DSgltC ./out/target/product/generic/symbols/system/lib/libwebcore.so > objdump.log

References/Usefull links http://developer.android.com/guide/developing/debugging/index.html

http://androidcore.com/android-programming-tutorials/

http://www.kandroid.org/online-pdk/guide/debugging_gdb.html

Documents

Android Debugging 1