ADB Shell Commands — Complete Guide for Android Testing

What is ADB?

ADB (Android Debug Bridge) is a command-line tool that lets you communicate with an Android device from your computer. It is part of the Android SDK platform tools and is essential for mobile testers, developers, and anyone working with Android devices professionally.

ADB enables you to install apps, capture logs, take screenshots, control device settings, and run shell commands — all from your terminal. In my work at Amazon and Virtusa testing Android, Fire OS, and IoT devices, ADB was a daily tool.

Steps to Enable USB Debugging

Before using ADB, you must enable Developer Options and USB Debugging on your Android device:

1. Connect your device to the computer via USB cable.
2. On your device, open the Settings app.
3. Search for Build Number (usually under About Phone).
4. Tap Build Number 7 times — you'll see "You are now a developer!"
5. Enter your PIN or password if prompted.
6. Go back to Settings and search for USB Debugging.
7. Toggle USB Debugging ON.
8. A pop-up will ask "Allow USB Debugging?" — tap OK.

Basic ADB Commands

These are the foundational commands every mobile tester should know.

Device Info Commands

These commands retrieve key information about the device — useful at the start of any test session to confirm the build and environment.

# Get Android OS version
adb shell getprop ro.build.version.release

# Get SDK version
adb shell getprop ro.build.version.sdk

# Get device serial number
adb shell getprop ro.serialno

# Get all device properties (useful for full device fingerprint)
adb shell getprop

Network Commands

These commands help you test and manage network connectivity on the device — essential for IoT and connectivity testing.

Wireless ADB via TCP/IP

You can connect to your device wirelessly over Wi-Fi without a USB cable — very useful when testing in environments where USB access is restricted.

Steps to connect via TCP/IP

1. Make sure the device and computer are on the same Wi-Fi network.
2. Connect the device to the computer via USB cable first.
3. Verify connection: adb devices
4. Set the device to listen on a TCP/IP port:
   adb tcpip 2211 (any 4-digit port number works)
5. Hit Enter — you'll see "restarting in TCP mode port: 2211"
6. Remove the USB cable.
7. Find the device's IP address (Settings → Wi-Fi → tap your network → IP Address).
8. Connect wirelessly:
   adb connect 192.168.1.X:2211
9. Verify the wireless connection:
   adb devices

# Full TCP/IP workflow
adb tcpip 2211
# Remove USB cable, then:
adb connect 192.168.1.100:2211
adb devices
# Output: 192.168.1.100:2211   device

Screen Commands

ADB lets you capture screenshots and screen recordings directly from the terminal — essential for documenting bugs and test evidence.

# Full screenshot workflow
adb shell screencap /sdcard/bug_screenshot.png
adb pull /sdcard/bug_screenshot.png ~/Desktop/bug_screenshot.png

# Full screen recording workflow
adb shell screenrecord --verbose /sdcard/test_recording.mp4
# Press Ctrl+C to stop recording, then:
adb pull /sdcard/test_recording.mp4 ~/Desktop/test_recording.mp4

Logcat Commands

Logcat is one of the most powerful tools for Android testing. It captures all system logs from the device in real time, letting you filter and trace bugs to their root cause.

# Save full logs to a file for bug reporting
adb logcat -v time -b all > test_session_logs.txt

# Real-time Wi-Fi issue filtering
adb logcat -v time -b all | grep -i wifidiags

# Filter for build info in logs
adb logcat -v time -b all | grep -i build

Package Management Commands

These commands let you inspect, list, and manage all apps installed on the device.

# Find a specific app's package name
adb shell pm list packages | grep -i netflix

# List all third-party apps
adb shell pm list packages -3

# Get full path of an APK
adb shell pm list packages -f | grep -i myapp

Settings Commands

ADB can read and write Android system settings directly — useful for automating device configuration in test setups.

Battery Commands

These dumpsys battery commands are extremely useful for testing low-battery scenarios, charging behaviour, and power-sensitive features without draining the physical battery.

# Test low battery behaviour
adb shell dumpsys battery set level 5

# Test charging connected / disconnected states
adb shell dumpsys battery set usb 1   # charging
adb shell dumpsys battery set usb 0   # not charging

# Always reset after testing
adb shell dumpsys battery reset

File Operations via ADB Shell

You can create, read, and manage files on the device directly through ADB Shell — useful for preparing test data or verifying file system behaviour.

Steps to create a file on the device

# Enter ADB shell
adb shell

# Navigate to the SD card
cd /sdcard

# Confirm current directory
pwd

# Create a new empty file
touch TestFile.txt

# Write content to the file
echo "Hello, ADB Shell!" > TestFile.txt

# Read the file contents
cat TestFile.txt

# Exit the shell
exit

Pulling files from device to computer

# Pull any file from device to your Desktop
adb pull /sdcard/TestFile.txt ~/Desktop/TestFile.txt

# Pull a folder
adb pull /sdcard/DCIM ~/Desktop/DevicePhotos

ADB for Test Automation Integration

ADB is not just a manual debugging tool — it is a first-class component in automated test pipelines. Combining ADB commands with Python's subprocess.run() lets you control the device, capture evidence, and manage application state directly inside your test scripts without needing a third-party library.

Running ADB Commands from Python Test Scripts

The standard way to invoke ADB from Python is subprocess.run() with capture_output=True. This gives you the command's stdout and stderr as byte strings that you can decode and assert on:

import subprocess

def adb(cmd: list[str]) -> str:
    result = subprocess.run(
        ["adb"] + cmd,
        capture_output=True,
        text=True,
        timeout=30
    )
    if result.returncode != 0:
        raise RuntimeError(f"ADB command failed: {result.stderr.strip()}")
    return result.stdout.strip()

Taking a Screenshot and Pulling It to Host During a Pytest Test

Capturing a screenshot on test failure provides visual evidence for bug reports and is especially useful when tests run unattended in CI. The following pattern hooks into pytest's fixture system to pull a screenshot to the host whenever a test fails:

import subprocess
import pytest

@pytest.fixture(autouse=True)
def capture_screenshot_on_fail(request):
    yield  # test runs here
    if request.node.rep_call.failed:
        test_name = request.node.name
        device_path = f"/sdcard/fail_{test_name}.png"
        host_path = f"screenshots/fail_{test_name}.png"
        subprocess.run(["adb", "shell", "screencap", device_path])
        subprocess.run(["adb", "pull", device_path, host_path])
        print(f"[SCREENSHOT] Saved to {host_path}")

Clearing App Data Before Each Test

Starting every test from a clean application state is essential for test independence. Rather than manually navigating to Settings to clear data, use pm clear in your pytest setup fixture:

PACKAGE = "com.example.myapp"

@pytest.fixture(autouse=True)
def reset_app():
    subprocess.run(["adb", "shell", "pm", "clear", PACKAGE], check=True)
    yield

pm clear wipes all app data, cache, and shared preferences — equivalent to a fresh install without uninstalling and reinstalling the APK. This is significantly faster and ensures every test starts from an identical baseline.

Checking Whether an App Is Running

Before interacting with an app in a test, confirm it is actually running. adb shell pidof returns the process ID if the app is active, or an empty string if it is not:

def is_app_running(package: str) -> bool:
    result = subprocess.run(
        ["adb", "shell", "pidof", package],
        capture_output=True, text=True
    )
    return result.stdout.strip() != ""

Setting Up ADB in GitHub Actions CI

Running ADB-based tests in a GitHub Actions pipeline requires installing the Android SDK platform-tools, starting an emulator, and waiting for it to fully boot before the first test executes:

- name: Install Android SDK platform-tools
  run: sudo apt-get install -y android-sdk

- name: Start Android emulator
  run: |
    $ANDROID_HOME/emulator/emulator -avd test_avd -no-window -no-audio &

- name: Wait for emulator boot
  run: adb wait-for-device shell 'while [ "$(getprop sys.boot_completed)" != "1" ]; do sleep 2; done'

- name: Run tests
  run: pytest tests/ -v

adb wait-for-device blocks until ADB can see the emulator, but it does not mean the Android OS has finished booting. The getprop sys.boot_completed poll is the correct signal that the emulator is truly ready to receive app interactions.

Capturing Logcat During Tests

Starting logcat in the background during your test run and killing it after gives you a complete device log for any test that fails. Parse the output for specific tags or error keywords:

import subprocess, signal

logcat_proc = subprocess.Popen(
    ["adb", "logcat", "-v", "time", "-b", "all"],
    stdout=open("test_logcat.txt", "w"),
    stderr=subprocess.DEVNULL
)
# ... run tests ...
logcat_proc.send_signal(signal.SIGINT)  # stop logcat after tests finish

# Parse for crashes
with open("test_logcat.txt") as f:
    if "FATAL EXCEPTION" in f.read():
        print("[WARNING] Crash detected in logcat")

Common ADB Automation Pitfalls

• Device not found when multiple emulators are running. If more than one emulator or device is connected, ADB commands fail with "error: more than one device." Always specify the target with -s <serial>: adb -s emulator-5554 shell .... Retrieve the serial from adb devices at setup time and store it as a fixture variable.
• Emulator not ready. Launching an emulator and immediately running tests causes intermittent failures because the emulator is still in the boot animation. Always poll adb shell getprop sys.boot_completed and wait for it to return "1" before starting any test interaction.
• Path differences between device manufacturers. The path /sdcard/ is standard on most devices, but some manufacturers and Android versions map it differently. Use adb shell echo $EXTERNAL_STORAGE to get the correct external storage path for the specific device under test rather than hardcoding /sdcard/.