Android Debug Bridge (ADB): Beyond the Basics

In this tutorial, you’ll learn how to communicate with your device using Android Debug Bridge (ADB). By Lance Gleason.

Login to leave a rating/review
Save for later

In this tutorial, you’ll learn how to communicate with your device using Android Debug Bridge (ADB).

When you deploy an app to a simulator or a device, whether you know it or not, you’re using Android Debug Bridge (ADB). This tool allows you to perform many development tasks, including:

  • Deploying apps to a device.
  • Debugging apps.
  • Viewing device and app logs.
  • Profiling apps.

With Android Studio built-in hooks to ADB, you can develop apps for a long time without needing to go beyond using these tools.

ADB is a very powerful tool. If you do Android development long enough, at some point you’ll need to go beyond what your Integrated Development Environment (IDE) provides.

Situations where you will need to do this include:

  • Running Android Studio on a Chromebook.
  • Using Android Things on a Raspberry Pi.
  • Deploying to a physical device with Wi-Fi.
  • Deploying to a virtual device on another machine.

In this tutorial, you’ll learn how to take your ADB skills beyond Android Studio.

Note: This tutorial assumes you’re familiar with Android development, knowledgable about networking and comfortable using the command-line in your chosen operating system. To complete the tutorial, you’ll need:
  • A Linux, MacOS or Windows machine.
  • A physical Android device such as a phone or tablet.
  • Access to a Wi-Fi network that allows device-to-device communication.
  • Optional: A second, remote machine with ssh installed.

Getting Started

The Android Software Development Kit (SDK) includes ADB. To use it, you’ll need to know where the SDK is on your machine.

Open Android Studio and go to Android Studio ▸ Preferences on a Mac or File ▸ Settings on Linux or Windows. Next, type android sdk in the search box. You’ll get a screen that will show the location of the SDK:

You can also find it by going to File ▸ Project Structure in an open project. This will bring up a different screen showing the location of the SDK for that project:

In these examples, the SDK is located in the /Users/lgleason/canary_fresh_sdk directory. Open the terminal on your machine and change your current directory to the location of your SDK. Finally, list the contents of the directory.

It will look similar to this:

Note: If you haven’t explored the Android SDK, a great place to start is the Android Command Line Tools documentation.

Find the ADB command in the platform-tools directory of your SDK. Change to that directory and then list the contents. You’ll see adb as one of the commands:

To run ADB on a Mac or Linux-based machine, type ./adb. On Windows, type adb.

Because you didn’t pass any parameters into ADB, you’ll see a help page describing commands you can use.

To start, use ADB to view devices connected to your machine. Connect a phone to your development machine via USB or start one of your Android Virtual Devices.

Type ./adb devices and execute it.

Note: This is an example with a connected but unauthorized device.

Note: When using ADB from the command line, you may see text about a daemon not running:

Android Studio usually hides these details, and a lot of this can seem like magic. Behind the scenes, ADB has three components that work together:

  • Client: ADB command invokes this on the terminal or via Android Studio.
  • Daemon (adbd): Runs ADB commands on a device.
  • Server: Runs on the client machine and manages the communication between the client and the daemon running on the device.

This note refers to the ADB server, which doesn’t start until Android Studio starts or until you run ADB for the first time.

Essential ADB

Now that you know how to run ADB, there are a few essential things to know when using it from the command line.

Working With Multiple Devices

If you have one device connected to your development machine, ADB automatically executes commands on that device.

To see that in action, shut down virtual machines or disconnect any physical devices until you have only one device listed.

Type in ./adb shell getprop and execute to get information about the connected device.

Note: Make sure to authorize the physical device.

Nice job! You executed a command on your connected device.

Now, try doing the same when you have multiple devices connected.
Connect another physical device or start up an additional virtual device on your machine.

Once it starts, list the devices by executing ./adb devices:

Type ./adb shell getprop and execute it:

Whoops, this time you have an error!

ADB doesn’t know on which device to perform this command. To fix this, pass a parameter to tell which device to run.

Get the name from the first column of one ADB device output:

Based on the output above, there is a device named 000002f78e859462. Pass it to the command by typing adb -s {your device name} shell getprop and execute it:

Awesome! The command now runs in a specific device.

The Shell Command

Android Studio has functions for doing things such as installing apps, viewing logs and profiling. If you want advanced device information or to list apps that are on a device, you need to use the command line shell.

Note: You may be wondering why it’s called a shell. Here’s why: Android is a distribution of Linux with a lot of customization. Using shell is the same thing as using a command prompt in Linux. The shell exposes commands that allow actions such as viewing network connections and packages installed on the device.

In this tutorial, you’ll access the shell from ADB. In other scenarios where you may need to access it by other means, such as through a serial connection in Android Things.

The getprop shell command you used earlier is one of many shell commands you can use with Android. Another useful command is the package manager shell command that lets you perform various functions with installed packages on your devices.

In the command prompt, type ./adb shell pm list packages and execute it:

This is telling pm (package manager) to list all the installed packages in your device.

Note: To learn more about the commands available via shell, the ADB shell commands reference from the Android project is a great place to start.

Advanced Connectivity

ADB makes it easy to connect to virtual devices running on your machine and physical devices connected via USB. However, there are scenarios where you may need to use ADB to connect to devices via Wi-Fi or over a network.

ADB Over Wi-Fi

One common scenario is connecting to a phone or tablet over Wi-Fi. For example, if you’re using the Linux support for Chromebooks, it’s the only way you can use ADB on physical devices.

Note: Enabling ADB over Wi-Fi on a device opens it for anybody on the same network be able to execute commands. This includes being able to install or delete packages, view data and add or delete users.
If you’re on a public network, make sure your device doesn’t have any sensitive data. If you’re on a private network with a device that has sensitive data, remote ADB will be enabled on any network you join until you restart your device.

Make sure your physical device is connected to the same network as your development machine. With the device connected to your machine via USB, type ./adb tcpip 5555 in your terminal and execute it.

Behind the scenes, the daemon on your device will restart and if needed, ask for ADB authorization.

Next, get the device’s IP address. Type ./adb shell ifconfig and execute (or ./adb shell ip addr if it is running a version of Android older than M/API 23):

The Wi-Fi controller will usually be your wlan0 controller. Use the value for inet addr:, which in this case is

Unplug your device, type ./adb connect {your device IP address} and execute it:

If your device isn’t set up to automatically authenticate ADB from your machine, the command will come back with a message stating that it failed to authenticate on your device. Your device will display a message asking you to authenticate.

Once you hit OK, you’ll have an authorized connection. To verify this, type ./adb devices and execute it:

You’ve now fully attached your device. Congrats! You’re amazing!

Open Android Studio, execute any project and you’ll see your device connected via Wi-Fi:

ADB Over Virtual Devices on a Remote Machine

Android virtual devices make it easy to test many different device configurations without needing to have multiple phones to test on. However, many virtual device configurations will take one to two gigabytes of memory and increase the host machine’s CPU usage.

To get around this, run your virtual devices on a remote machine.

Note: For this part of the tutorial, you need a development machine with an additional remote instance. Each machine needs to have:
  • A ssh client and server.
  • Android Studio.
  • At least two configured virtual devices.
  • The ability to remotely access ports in the range of 5000 to 7000.

If you don’t have the remote machine, following along will help you to better understand the concepts surrounding Android virtual devices, and you can leave the exercise for another time.

When you run a virtual device, it uses two ports. The Android Console uses the first port to perform commands on the virtual device such as restarting it or shutting it down. The second port is for ADB commands.

First, prepare your remote machine by closing any open virtual devices. Next, open the Android Virtual Device Manager by selecting Tools ▸ AVD Manager:

After launching the emulator, select the Settings using the ... button:

At the top of the settings window, you’ll see the emulator name along with :5554, in this case. That’s the port for an Android Console. Your ADB port will be that number plus one. For the emulator above, it’s 5555.

Now, start another virtual device and open its settings:

This will have am Android Console port of 5556 and an ADB port of 5557. As you open more virtual devices, these numbers will continue to increase.

Now, perform an ssh port forward from this remote machine back to your development machine.

To start, get the IP address of your development machine. Then, on your remote machine, perform an ssh port forward by typing ssh -R 6554:localhost:5554 -R 6555:localhost:5555 {your username}@{your dev machine IP address} and executing it:

Note: If you’re not using ssh keys, you’ll need to supply a password.

This is a technique called SSH tunneling. In essence, you’re creating a tunnel that’s going through an encrypted SSH connection.

While the SSH connection is active, requests on port 6554 and 6555 on your development machine will forward to port 5554 and 5555 on your remote machine.

To get a feel for how the console works, on your development machine, type telnet localhost 6554 and execute it:

You’re now in the Android Console. Now that you’re in here you can execute commands to control your virtual device. Things you can do with this include simulating hardware events, simulating crashes etc. Check out the emulator console documentation to learn about the the various things you can do to control your console.

Type exit to exit the console:

Use the ./adb connect localhost:6555 command to connect to your tunneled remote virtual device:

Verify that it’s connected with ./adb devices:

Note: This technique is generally reliable for remotely running apps and unit test suites. Debugging via this connection is not reliable, so you may not want to use it for that part of your development flow.

Where to Go From Here

In this tutorial, you learned a lot about ADB. Consider these exercises to take your ADB skills further:

  • Try out some other shell commands such as pinging another network device from a device or poking around the filesystem to see what else is there.
  • Root a device and use some shell commands to explore system levels on your device.

For more details on related topics, visit the Android Developers Site and check out the ADB Shell, which has great information about ADB and shell commands.

Pluimet’s ADB Useful Commands List is another list with useful tips.

I hope you enjoyed this introduction to ADB. If you have any comments or questions, please join the forum discussion below!