If you’ve had experience with Android over a period of time, you may have encountered the Android Debug Bridge (ADB). ADB serves as a valuable asset not only for Android developers but also for testers. At zen8labs, our QA team is enthusiastic about harnessing this tool to enhance operational efficiency and streamline time usage for mobile software testing.
In this article, we list down a few best ADB commands that we often use.
What is ADB?
Android Debug Bridge (ADB) is a versatile command-line tool that lets you communicate with a device. The adb command facilitates a variety of device actions, such as installing and debugging apps. adb provides access to a Unix shell that you can use to run a variety of commands on a device. It is a client-server program that includes three components:
- A client, which sends commands. The client runs on your development machine. You can invoke a client from a command-line terminal by issuing an adb command.
- A daemon (adbd), which runs commands on a device. The daemon runs as a background process on each device.
- A server, which manages communication between the client and the daemon. The server runs as a background process on your development machine.
To use ADB, we must enable USB debugging in the Developer options on the phone by the following steps:
- Go to Settings > About phone > Navigate to Build number > tap on it 6 times to enable Developer options (a message You are now a developer! will be appeared).
- Back to the main Settings screen > Developer options > Turn the Developer options on > Enable USB debugging mode. Now connect the device to your computer using a USB cable and you are ready to run ADB commands.
5 useful ADB commands for testing
1. Show connected devices
When you run the adb devices command, ADB will scan for connected devices and display a list of them along with their unique device IDs. We use the device ID to identify each connected Android device. The list will look something like this:
adb devices
List of devices attached
21fa415229047ece
In the above example, the adb server connects a physical device with the device ID 21fa415229047ece. The “device” string indicates that the physical phone is ready and available for communication with ADB. If it displays the string “offline”, it means there is an error with the connection or driver.
2. Adb install an application
This command is used to install an Android application (apk file) onto a
connected Android device or emulator using the ADB tool.
adb install [options] path/to/app.apk
Here is some options that zen8labs’ QA team often uses:
- ‘-r’ : re-install an existing app, keeping its data.
- ‘-t’ : allow test APKs to be installed
- ‘-d’ : allow version code downgrade
3. Clear Android application data
Some test cases require clearing the application data before executing. It will take time if testers have to do it many times, zen8labs’ QA team often uses the adb command will save hours. The syntax is as follows:
adb shell pm clear package_name
Don’t forget to replace the ‘package_name’ with the actual package name of the application that you want to clear the data. The package name uniquely identifies the app on the device.
For example, to clear the data of Chrome app on Android 10
adb shell pm clear com.android.chrome
4. Record videos and Take screenshots
Screenshots or videos are a must-have for bug reports that involve user experience issues. They help the developer team understand and reproduce bugs easily.
To record a video, use the command
adb shell screenrecord [options] filename
The video will be saved to the specified path on your device. To stop recording, press Ctrl + C on Windows (or comman + C on Mac)
To take a screenshot, use the command
adb shell screencap filename
The screenshot will be saved to the specified path on your phone. Since the output text does not show, to check whether or not the screenshot is captured we can use the ADB shell commands like ‘ls’
adb shell ls path_filename
5. Capture log files via logcat
During the testing process at zen8labs, We have seen crash happened sometimes but the steps to reproduce it isn’t clear. Therefore, the QA team often captures the log files right after the bug occurs. This file helps developers know what went wrong with the application. Running this command ‘adb logcat’ print the log to the console, and you can stop it with Ctrl + C on Windows or command + C on Mac. To filter the log and make it more useful for testing, you can use priority levels like:
- V: Verbose (lowest priority)
- D: Debug
- I: Info
- W: Warning
- E: Error
- F: Fatal
- S: Silent (highest priority, where nothing is ever printed)
Additionally, ADB can provide other important device data like the Android version, device build, and current language using the adb shell getprop command. By passing specific keys inside brackets, you can retrieve targeted information. Examples include adb shell getprop ro.build.version.release to get the Android version, adb shell getprop ro.build.fingerprint for the build fingerprint, and adb shell getprop persist.sys.locale to retrieve the current device language.
Conclusion
I am glad the present has been helpful and saved your effort during mobile software testing. Keep in mind that the mentioned commands are only a selection, and there are numerous possibilities that can assist you and your team when working with Android devices. You can explore further by using the adb help command, which provides more insights into available ADB commands and their usage.
If you are interested in quality assurance, read other blog posts from zen8labs’ members here. Thank you!
Phuong Nguyen, QA Engineer