Some useful adb commands

The Android Debug Bridge creates a communication channel between your development machine and an Android device. The adb process on your development machine communicates with a matching adb process running on your Android device.

When you tell Android Studio to run your app, it will use the Android build tools to create a .apk file. It will then use the adb command to install your app on the Android device, to start the app running, and then to read the log information that is generated by the app.

Sometimes it can be useful to learn how to run adb commands yourself on the command line or terminal. And the adb is also an excellent tool for exploring how your Android device works.

Add adb to your PATH

In order to run the adb command, you will need to make sure the right directory is included in your PATH variable. The adb command is in the platform-tools directory beneath the Android SDK directory. If you’re using a Mac, this will be ~/Library/Android/sdk/platform-tools

adb command vs server

The adb command communicates with the ADB daemon process. The adb server is actually just a running instance of the adb command, but running in server mode. Only one copy of the server process runs at a time. When you use the adb command, it will try to communicate with the adb server process. If it doesn’t exist, adb will start it for you.

For example, the adb devices command will tell you which Android devices are connected to your machine. If the adb server is not running, the command will automatically start it for you.

$ adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
emulator-5554	device

$ 

adb kill-server

Sometimes the adb server can go slightly nuts, and you can set it right again by killing it before issuing your next command:

$ adb kill-server
$ adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
emulator-5554	device

$

adb logcat

This command will stream the complete logcat output to your screen. logcat is the combined log output of every app on your device, and reading it is like drinking from a fire hydrant.

$ adb logcat
--------- beginning of /dev/log/main
E/logwrapper(  920): executing /system/bin/e2fsck failed: No such file or directory
E/logwrapper(  926): executing /system/bin/e2fsck failed: No such file or directory
I/qemu-props(  932): connected to 'boot-properties' qemud service.
I/qemu-props(  932): receiving..
I/qemu-props(  932): received: dalvik.vm.heapsize=64m
I/qemu-props(  932): receiving..
I/qemu-props(  932): received: qemu.sf.lcd_density=480
I/qemu-props(  932): receiving..
I/qemu-props(  932): received: qemu.hw.mainkeys=0
...

Typically you would filter the output using some other tool, such as grep:

$ adb logcat| grep LAUNCHER
I/ActivityManager( 1273): START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 cmp=com.hfad.starbuzz/.TopLevelActivity} from pid 1826
I/ActivityManager( 1273): START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.hfad.starbuzz/.TopLevelActivity} from pid 1406
...

adb shell

You can use adb to open up a shell on your device.

$ adb shell
root@generic_x86:/ # ls
acct
cache
config
d
data
default.prop
dev
etc
file_contexts
fstab.goldfish
init
init.environ.rc
init.goldfish.rc
init.rc
init.trace.rc
init.usb.rc
mnt
proc
property_contexts
root
sbin
sdcard
seapp_contexts
sepolicy
storage
sys
system
ueventd.goldfish.rc
ueventd.rc
vendor
root@generic_x86:/ #

If you log into a physical device, you will have very restricted access. If you log into an Android Virtual Device (AVD), you should be able to do pretty much anything.

adb pull

This command allows you to copy files from the device:

$ adb pull /default.prop
33 KB/s (116 bytes in 0.003s)
$ cat default.prop
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=1
ro.debuggable=1
persist.sys.usb.config=adb
$