Skip to content

Learn

Useful ADB commands for android testing

Discover essential ADB commands for Android testing. Learn how to interact with devices, simulate battery parameters, capture screens, and more with ADB. 

abd commands

What is android debug bridge?

Android Debug Bridge (ADB) is a command-line tool included in the Android SDK that allows us to send commands from a computer host to an Android device. With ADB, you can copy files to/from the device and run shell commands on the device.

Before using ADB, we must enable USB debugging in Developer Options on the Android device. To do that, launch the Settings application and navigate to About Phone or About Emulated Device. Perform several touches on the Build number until the message “You are now a developer!” appears. This enables Developer Options.

Return to the main screen of the Settings application and go to System -> Advanced -> Developer Options. Enable USB debugging and connect the device to your computer using a USB cable. You are now ready to run ADB commands!

List connected devices

The first command you should learn is to list connected devices so you can test whether your device was correctly recognized by the ADB server. To do, that run the command:

$ adb devices

List of devices attached

emulator-5554 device

Having found our device in the command output, we are prepared to proceed.

Simulate battery parameters

We can’t discharge a battery on a virtual device. But we can use the following command to simulate any scenario we want, like setting the battery level to 1%:

$ adb shell dumpsys battery set level 1

You could also try to connect/disconnect an AC charger:

# Connect AC charger

$ adb shell dumpsys battery set ac 1

# Disconnect AC charger

$ adb shell dumpsys battery set ac 0

Or if you prefer, try with a USB cable instead:

# Connect USB cable

$ adb shell dumpsys battery set usb 1

# Disconnect USB cable

$ adb shell dumpsys battery set usb 0

After running each of those commands, you can reset the battery options using:

$ adb shell dumpsys battery reset

Take screenshots and recordings

ADB commands are far more powerful than simulating battery parameters. We can also take screenshots and videos of the device screen. Let’s start recording a video of our device screen by running the following command:

$ adb shell screenrecord /sdcard/Movies/video.mp4

This will record the device screen and save the video file to the path / SDcard / Movies / video.mp4. To stop recording, press Ctrl + C to finish the command. To take a screenshot of an app screen, we only need to navigate to the desired screen and run the command:

$ adb shell screencap -p /sdcard/Pictures/screenshot.png

The command above will take a screenshot of the current screen and save it at the path / SDcard / Pictures / screenshot.png. If you tried running the command, you may have noticed that no output text is displayed. So how do we know that the screenshot was really captured? We can execute Unix-like commands using ADB shell, like the ls, which we will use to list files from the Pictures folder:

$ adb shell ls /sdcard/Pictures/

As you can see in the command output, the screenshot was correctly saved in this folder. But you may have noticed that the screenshot was saved in the Android device storage. How can we access it using our computer? By copying the file using the ADB pull command:

$ adb pull /sdcard/Pictures/screenshot.png ~/Desktop/screenshot.png

/sdcard/Pictures/screenshot.png: 1 file pulled, 0 skipped. 16.0 MB/s (132917 bytes in 0.008s)

The screenshot file has now been copied from the device storage to the computer desktop. Let’s suppose that you opened it on the computer, made some changes in the image file, and want to copy it back from the computer to the Android device. Run the ADB push command:

$ adb push ~/Desktop/screenshot.png /sdcard/Pictures/screenshot.png

/home/heitor/Desktop/screenshot.png: 1 file pushed, 0 skipped. 25.0 MB/s (132917 bytes in 0.005s)

As mentioned before, we are able to execute Unix-like commands using ADB shell, and we’ve already used the ls to list the files in a directory. Now let’s use some other commands that may help when we are dealing with files. We may want to have a specific folder to save our screenshots, separating them from the other pictures. For this run the following command to create a new directory, and after that run the ls to check if it was created correctly:

$ adb shell mkdir /sdcard/Pictures/my_screenshots

$ adb shell ls /sdcard/Pictures/

my_screenshots

Screenshot.png

As we can see in the command output, the directory was created but the screenshot that we have taken is still inside the Pictures folder. We can use this command to move it to the new location:

$ adb shell mv /sdcard/Pictures/screenshot.png /sdcard/Pictures/my_screenshots/

You could also use the cut-paste command instead:

$ adb shell cp /sdcard/Pictures/screenshot.png /sdcard/Pictures/my_screenshots/

And after copying and moving the files, you can delete them by using the rm command:

# Delete a file

$ adb shell rm /sdcard/Pictures/screenshot.png

# Add the -r flag to delete directories

$ adb shell rm -r /sdcard/Pictures/my_screenshots

Obtain log files

Probably the most important command is the log, which the developer uses to understand what went wrong with the application. The log can be obtained using logcat:

$ adb logcat

The command will print the log to the console output. To stop the process, press Ctrl + C. Using the logcat command without any additional option will print the whole text available in the main logcat buffer, which is probably not so useful for your tests. However, we can filter the logs according to their priorities:

  • V: Verbose (lowest priority)
  • D: Debug
  • I: Info
  • W: Warning
  • E: Error
  • F: Fatal
  • S: Silent (highest priority. Nothing is printed)

If we want only the messages with error priority or higher, for example, we just need to use the command:

$ adb logcat *:E

To filter by other log priorities, just change the end of the command with the respective letter. We can also filter the output by the tag used by the application logger. The command below prints messages with the tag MyTag and priority level Info or higher to the output log. The *:S at the end will exclude the log from other tags with any priority:

$ adb logcat MyTag:I *:S

We can obtain data on device build, current language, or Android version by using ADB commands:

$ adb shell getprop

[build.version.extensions.r]: [0]

[cache_key.bluetooth.get_bond_state]: [5814992271136807633]

[cache_key.bluetooth.get_profile_connection_state]: [5814992271136807636]

# …

The command above will output all data that can be obtained using this command. We can also pass the key displayed inside the brackets in order to get a specific value. Some examples are displayed below:

# Get Android version

$ adb shell getprop ro.build.version.release

11

# Get build fingerprint

$ adb shell getprop ro.build.fingerprint

google/sdk_gphone_x86_arm/generic_x86_arm:11/RSR1.201013.001/6903271:userdebug/dev-keys

# Get current device language

$ adb shell getprop persist.sys.locale

en-US

Perform touch or swipe

Another feature of ADB is the ability to interact with the Android device by performing touches and swipes, entering text, and pressing buttons. To execute these interactions, we will use the input command followed by the name of the interactions to be performed and their arguments.

To enter a string in a text field, use the command below (make sure the field has focus and remember to escape the whitespaces):

$ adb shell input text “this\ is\ some\ string”

Perform the touches with coordinates. Use the input tap command followed by the x and y points to be clicked:

$ adb shell input tap 500 400

The swipe command can be executed by sending the coordinates, but we need to send two different points: initial and final. Optionally, we can define the duration of the swipe movement in milliseconds:

# Perform a swipe gesture from the center to top

$ adb shell input swipe 500 1000 500 100

# Perform the same gesture slowly. Takes 5 seconds

$ adb shell input swipe 500 1000 500 100 5000

We can also use the input command to press device buttons like home, back, menu, or even other less common ones like camera or headset buttons. This is possible because each of these buttons has a key code associated with them, and the input command uses those codes to perform the actions.

You can find the list of all key codes in Android’s official documentation. See some examples below:

# Press Home button

$ adb shell input keyevent KEYCODE_HOME

# Press Camera button

$ adb shell input keyevent KEYCODE_CAMERA

# Press Back button

$ adb shell input keyevent KEYCODE_BACK

# Press Headset button

$ adb shell input keyevent KEYCODE_HEADSETHOOK

Launch activities

Another scenario where ADB is really useful is when the applications under test are launching activities directly. Besides launching the main activity of an app, you can also use Activity Manager to launch other activities to reduce the steps required to reach a screen.

Let’s start using the Activity Manager to launch an application by its package name. We’ll use the Settings app as an example. Its package name is com.android.settings:

$ adb shell am start com.android.settings

After running this command, the Settings application will be launched on the Android device. This command will only launch the application’s main activity. If we want to launch another one, we just need to inform the activity name with the flag -n. The command below launches the Wifi Settings screen directly:

$ adb shell am start -n com.android.settings/.Settings$WifiSettings2Activity

But how can we discover the activity name that we want to launch? Use ‘dumpsys’ to extract the information about the activity that is being displayed on the screen.

Let’s filter the output with the grep and cut shell commands to print the activity name:

$ adb shell “dumpsys activity activities | grep mResumedActivity | cut -d ‘ ‘ -f 8”

com.android.settings/.Settings$WifiSettings2Activity

To close the app after launching and performing your validations, use the force-stop command with the package name:

$ adb shell am force-stop com.android.settings

Clear application data

Clearing application data is a quick task, but when it needs to be repeated for each test it consumes a lot of the tester’s time. To solve that, we run a Package Manager command to clear the application data by using ADB.

To test that, launch the Clock application and create an alarm. After that, run the command below and verify that all changes have been reset:

$ adb shell pm clear com.google.android.deskclock

After clearing the application data, you may want to grant the application permissions. You can do this manually when the app asks for them, but you could also enable them beforehand by using the pm command. The command below will grant the permission android.permission.READ_EXTERNAL_STORAGE to the Clock application:

$ adb shell pm grant com.google.android.deskclock android.permission.READ_EXTERNAL_STORAGE

If you want to revoke this permission, use the following command:

$ adb shell pm revoke com.google.android.deskclock android.permission.READ_EXTERNAL_STORAGE

To discover the name of the permissions to be used, use the pm command to list all known permissions:

$ adb shell pm list permissions

All Permissions:

permission:com.google.android.gms.auth.api.phone.permission.SEND

permission:android.permission.REAL_GET_TASKS

permission:android.permission.ACCESS_CACHE_FILESYSTEM

permission:android.permission.REMOTE_AUDIO_PLAYBACK

#…

We can also use the pm command to see if an application is installed. We just need to run the pm command to list all installed applications and then check the output.

Alternatively, we can add a substring of the package name to the end of the command. Then only the package names that match this substring will be printed at the command output. See the examples below:

# List all installed applications

$ adb shell pm list packages

package:com.google.android.networkstack.tethering

package:com.android.cts.priv.ctsshim

package:com.google.android.youtube

#…

# List only the package names that contains “android.settings”

$ adb shell pm list packages android.settings

package:com.android.settings.intelligence

package:com.android.settings

package:com.android.settings.auto_generated_rro_product__

FAQs

What are ADB commands in Android?

Android Debug Bridge (ADB) is a command-line tool used to communicate with a device. The ADB command drives a variety of device actions, such as installing and uninstalling apps, and it also provides access to the Unix shell through which you can run multiple commands on a device.

May I enable USB debugging using ADB?

Enabling USB debugging using an ADB command is not possible, because executing an ADB command requires you to have USB debugging enabled on your phone. ADB cannot communicate with your device until the USB debugging is turned on.

How do I run commands in ADB?

a. To run the command, type adb reboot-bootloader in the command line. To boot the device in recovery, type ADB reboot recovery.
b. Fastboot device command: Use the Fastboot device command to boot your Android device.

What is ADB shell for?

ADB shell is a command line utility included with Google’s Android SDK. An Android device where it is connected to a computer using a USB can control by the terminal interface. ADB can use to run shell commands, transfer files, install/uninstall apps, and more.

What is the purpose of ADB shell commands?

The purpose of ADB shell commands is to run different commands on an emulator or connected device.

About the author

Heitor Paceli

I am a Software Engineer based in Recife, Brazil. My education is Master of Science in Computer Science at CIn/UFPE (2016), Specialist in Test Analysis at CIn (UFPE)/Motorola (2013) and Graduated in Technology of System Analysis and Development at IFPE (2013). I Was a Undergraduate Researcher (PIBIC) in the project Virtual Reality Environments Applied to Teaching Algorithms and Data Structures (2011-2012). I am currently working as Software Engineer at CIn/Motorola partnership, where I am responsible for development of tools that run on both Web, Desktop and Mobile (Android) environments. I also have more than 8 years working with test automation for Android devices. Most of my experience is working mainly with Java, Kotlin and Javascript.

Author:

Guest Contributors

Date: Aug. 06, 2025

You may also be interested in...