The Android Debug Bridge (ADB) is a client-server tool that interacts directly with Android devices and emulators using a command-line interface. You can use this tool, provided as part of the Android Sorftware Development Kit (SDK), to manage and interact with emulator and device instances connected to a development machine and view logging and debugging information. ADB also provides the underpinnings for other tools, such as the Android Plug-In for Eclipse (ADT) and Dalvik Debug Monitor Service (DDMS). This Quick-Start Guide is not a complete documentation of the ADB functionality. Instead, it is designed to get you up and running with common tasks. See the ADB documentation provided with the Android SDK for a complete list of features.
Much of the functionality provided by the ADB (such as the LogCat
Android logging utility or pushing and pulling files using the File Explorer) is closely integrated into the development environment through DDMS and ADT.
Developers might prefer to use these friendly methods to interact with devices and emulators; however, you can use ADB for automation and scripting purposes. You can also use ADB to customize functionality, instead of relying on the defaults exposed through secondary tools.
You can use ADB to list all Android devices and emulator instances connected to a development machine. To do this, simply use the devices
command of the adb
command line. For example:
adb devices
This command lists the emulators and devices attached to this machine by their serial number and state (offline
or device
). For emulator instances, the serial number is based on their unique port number. For example, in this case, we have one emulator instance (Port 5554) and one Android phone (a T-Mobile G1 connected via USB):
When you know the serial number of the device you want to connect to, you can issue commands as follows:
adb –s <serial number> <command>
For example, to get the state of a specific device, type
adb -s emulator-5554 get-state
Instead of using the –s
flag with a unique serial number, you can also use the –d
flag to direct a command to the only device instance connected or the –e
flag to direct a command to the only emulator instance, provided you have only one of each type connected.
For example, if we have only one Android phone connected, we can query its serial number as follows:
adb -d get-serialno
Sometimes you might need to manually restart the ADB Server process. We have, for example, needed to do this when we’ve had an emulator instance running for a long time and have repeatedly connected and disconnected the debugger, eventually resulting in a loss of LogCat
logging. In this case, you might want to kill and restart the ADB server (and perhaps Eclipse).
To terminate the ADB server process, use the kill-server
command. For example, to kill the server for a specific emulator instance, type
adb -s emulator-5554 kill-server
You can use the ADB command line to copy files to and from your hard drive to an Android device. You need to know the full path information to the file you want to copy. File operations are subject to your user permissions (locally and remotely).
You can copy files to the device using the push
command, as follows:
adb push <local file path> <remote file path on device>
For example, to copy the file Pic.jpg
from the local hard drive to T-Mobile G1’s SD Card download directory, use the following command:
adb -s HT841LC1977 push c:Pic.jpg /sdcard/download/Pic.jpg
You can copy files from the device using the pull
command, as follows:
adb pull <remote file path on device> <local file path>
For example, to copy the file Lion.jpg
to the local hard drive from T-Mobile G1’s SD Card download directory, use the following command:
adb -s HT841LC1977 pull /sdcard/download/Lion.jpg C:Lion.jpg
If you put picture files onto your SD Card—virtual or otherwise—using this method, you need to force the Android operating system to refresh using the Media Scanner (available in the Dev Tools application on the Emulator). If you use an older version of the Android SDK or use a device, such as the T-Mobile G1, which does not have this feature, you might need to restart the phone or eject the SD Card and reinsert it to get the files to refresh within the Picture application. For a programmatic method, try sending the MEDIA_MOUNTED
broadcast Intent
.
You can use ADB to install and uninstall packages on a given Android device or emulator. Although the ADT does this for developers automatically, this functionality is useful for developers not using the Eclipse development environment and for those developers and testers who want to create automated build procedures and testing environments.
Applications are installed as packages created with the Android Asset Packaging Tool (aapt).
To install applications, first create an Android package (.apk) file, and then use the install command:
adb install <apk file path>
For example, to install the sample application Snake
on the emulator, you could use the following command:
You can use the –r
to reinstall the application package without overwriting its data. For example, you can now reinstall the Snake
application without losing your data by using the following command:
adb -e install –r C:Snake.apk
To uninstall an Android application, you need to know the name of its package—
adb uninstall <package>
For example, to uninstall the Franglais
application from the emulator, you can use the following command:
adb -e uninstall com.androidbook.franglais
You might use this command often if you switch between computers and, thus, switch signatures frequently. You can read more about signing applications in Chapter 20, “Selling Your Android Application.”
Android logging information is accessible through the LogCat
utility. This utility is integrated into DDMS and ADT, but you can also access it directly through ADB using the following command:
adb logcat <option> <filter>
To display all LogCat
logging information from the emulator instance, type
adb –e logcat
By default, the logging mode is set to brief
. For example, the following is an Informational (I
) log message (brief
mode) from the tag AppLog from process ID 20054:
I/AppLog(20054): An Informational Log message.
Another useful mode is the time
mode, which includes the date and time the log message was invoked. To change the logging mode, use the –v
flag and specify the format. For example, to change to time
mode, use the following command:
logcat -v time
The resulting log messages are formatted with the date and time, followed by the event severity, tag, process ID, and log message:
01-05 21:52:22.465 I/AppLog(20054): Another Log Message.
All the log information available through the LogCat
tool can be overwhelmingly verbose. Most of the time a filter or two is required to sift out only the messages you want to view.
Filters are formatted tags and event priority pairs. The format for each filter is
<Tag Name>:<Lowest Event Priority to Print>
For example, a filter to display Informational log messages (and higher priority messages including Warnings, Errors and Fatal messages) from log messages tagged with the string AppLog
would look like this:
AppLog:I
You can also use the asterisk (*), which means “all.” So if you use an asterisk on the Tag side of the filter, it means “All tags.” If you put it on the Event Priority side, it’s much like using the V priority—the lowest priority, so all messages display.
You can create filters to display only log events of a certain severity. The severity types (from lowest priority or most verbose to highest priority or least verbose) follow:
• Verbose (V)
• Debug (D)
• Info (I)
• Warning (W)
• Error (E)
• Fatal (F)
• Silent (S)
For example, the following command displays all Errors and Fatal errors but suppresses warnings, informational messages, debug messages, and verbose messages:
logcat *:E
You can use multiple filters, ending with a catch-all. Perhaps you want to see all messages from a specific application (a specific tag) and no others. In this case, you want to create a filter to show all messages for a given tag and another filter to suppress all other tags. We also change into time mode, so we get the date and time of the logged events messages.
The following command displays all AppLog
-tagged logging information and suppresses all other tags:
logcat –v time AppLog:V *:S
This filter is roughly equivalent to this other command line:
logcat –v time AppLog:* *:S
The resulting log messages would be formatted with the date and time, followed by the event severity, tag, process ID, and message:
01-05 21:52:22.465 I/AppLog(20054): Another Log Message.
You can redirect log output to a file on the device using the –f
flag. For example, to direct all informational logging messages (and those of higher priority) from the emulator to the file mylog.txt
in the sdcard
directory, you can use the following command:
logcat -f /sdcard/mylog.txt *:I
Android has several different logs. By default, you look at the main log. However, an events log and a radio log also exist. You can connect to the other log buffers using the –b
flag. For example, to connect to the event log to review events, type:
logcat -b events
The radio log is similarly accessed as follows:
logcat –b radio
You can create a rather verbose bug report to attach to application defects using the bugreport
command. For example, to print the debug information for the sole emulator instance running on your development machine, use
adb -e bugreport
To print the debug information for the sole phone connected via USB, you would issue this command instead:
adb –d bugreport
ADB includes a shell interface (ash) where you can interact directly with the device and issue commands and run binaries. You can use the shell interface to run built-in command-line programs such as sqlite3
(to examine SQLite application databases) and monkey
(a stress testing application). You can also install custom binaries on the emulator or device.
The ash shell has your typical file access commands like pwd
and ls
. For more information on the ash shell, check out the Linux Blog Man page for ash: http://www.thelinuxblog.com/linux-man-pages/1/ash.
You can issue a single shell command without starting a shell session using the following command:
adb shell <command>
For example, to list all the files in the /sdcard/download
directory on the emulator, type
adb -e shell ls /sdcard/download
Often you might want to issue more than one command. In this case, you might want to start a shell session. To do so, simply type
adb shell
For example, to connect to a specific device instance by serial number and start a shell session, type
You can then issue commands. Ending your session is as easy as typing exit.
Stopping the emulator makes it stop responding, although it still displays on your development machine. To stop the emulator, you can issue the stop
command within the ADB shell.
adb -s emulator-5554 shell stop
You can then restart the emulator using the start
command:
adb -s emulator-5554 shell start
You could also perform these commands from within a shell session, like this:
You can use the standard sqlite3
database tool from within the ADB shell. This tool allows you to inspect and interact directly with a SQLite database. For a thorough explanation of the sqlite3
tool, see Appendix D, “The SQLite Quick-Start Guide.”
You can use the Exerciser/Monkey tool from within the ADB shell to send random user events to a specific application. Think of it as handing your phone (or emulator) to a monkey (or a baby, or a baby monkey) and letting them push random keys, causing random events on the phone—events that can crash your application if it doesn’t handle them correctly. If your application crashes, the Monkey
application stops and reports the error, making this a useful tool for quality assurance.
To launch the Monkey
tool, use the following command line:
adb shell monkey –p <package> <options> <event count>
For example, to have the monkey generate five random events within the GroceryList
application within the emulator, you would do the following:
adb -s emulator-5554 shell
# monkey -p com.androidbook.grocerylist 5
You can watch each event generated by using the verbose flag –v
. For example, to see which events you send to the preceding GroceryList
application, you would use this command:
adb -s emulator-5554 shell
# monkey -p com.androidbook.grocerylist -v 5
Here is the important output from this command:
You can tell from the verbose logging that the Monkey
application sent five events to the GroceryList
application: a navigation event (left), two trackball events, the Menu button, and then two more navigation events (right, center).
You can specify the types of events generated by the Monkey
application. You basically give weights (percentages) to the different types of events. The event types available are shown in Table C.1.
To use a different mix of events, you need to include the event type’s command line flag as listed in Table C.1, followed by the desired percentage.
monkey [<command line flag> <percentage>...] <event count>
For example, to tell the Monkey to use only touch events, use the following command:
monkey -p com.androidbook.grocerylist --pct-touch 100 -v 5
Or let’s say you want just Basic and Major navigation events (50%/50%):
monkey -p com.androidbook.grocerylist --pct-nav 50 --pct-majornav 50 -v 5
You get the picture.
For random yet reproducible results, you can use the seed option. The seed feature allows you to modify the events that are produced as part of the event sequence, yet you can rerun sequence in the future (and verify bug fixes, for example).
To set a seed, use the –s
flag.
monkey –p <package> -s <seed> –v <event count>
For example in our command we used previously, we can change the five events by setting a different starting seed. In this case, we set a seed of 555:
monkey -p com.androidbook.grocerylist -s 555 -v 5
Changing the seed changes the event sequence sent by the Monkey
, so as part of a stress test, you might want to consider generating random seeds and sending them to the Monkey
and logging the results. When the application fails on a given seed, keep that seed (and any other command line options like event type percentages) when you log the bug and rerun the test later to verify the bug fix.
By default, the Monkey
generates events as rapidly as possible. However, you can slow this behavior down using the throttle option as follows:
monkey --throttle <milliseconds> <event count>
For example, to pause for 1 second (1000 milliseconds) between each of the five events issued to the GroceryList
application, use the following command:
monkey -p com.androidbook.grocerylist -v --throttle 1000 5
For more information about the Monkey
application and other Monkey
commands, see the Android SDK Reference Web site: http://developer.android.com/guide/developing/tools/monkey.html. You can also get a list of commands by typing monkey without any command options, like this:
adb -e shell monkey
You can also install custom binaries on the emulator or device. For example, if you spend a lot of time working in the shell, you might want to install BusyBox
, which is a free and useful set of command-line tools available under the GNU General Public License and has been called “The Swiss Army Knife of Embedded Linux” (thanks, Wikipedia for that little fact). BusyBox
provides a number of helpful and familiar UNIX utilities, all packaged in a single binary. Utilities like find and more. BusyBox
provides many useful functions (although some of which might not apply or be permissible) on Android, such as the following:
All you need to do is install the binary (which is available online) using the following steps:
BusyBox
binary (at your own risk, or compile it for yourself). You can find the binary online at http://benno.id.au/blog/2007/11/14/android-busybox, where Benno has kindly hosted it for you. (Thanks, Benno!)/data/local/busybox/
on your emulator using the ADB shell, for example, adb –e shell mkdir /data/local/busybox/.
BusyBox
binary to the directory you created, for example, adb -e push C:usybox /data/local/busybox/busybox.
adb –e shell.
BusyBox
directory, for example, #cd /data/local/busybox.
BusyBox
file, for example, #chmod 777 busybox.
BusyBox
, for example, # ./busybox –install.
# export PATH=/data/busybox:$PATH.
You can find out more about BusyBox
at http://www.busybox.net.
3.145.191.214