ADB Basics

Android Debug Bridge fundamentals for QA: logs, build installation, and troubleshooting.

Updated:

Contents

ADB, Android Debug Bridge, connects a computer to an Android device or emulator. Beyond investigating crashes, QA can use it to install builds, collect logs, capture screenshots, and reproduce link navigation without lengthy manual sequences.

Commands are useful when testers understand the state they change. Clearing data, stopping a process, and updating an application are different actions. Confusing them can remove a defect's precondition and produce a false success.

How the connection works

ADB is part of Android SDK Platform Tools. Physical devices require authorized debugging access; on first connection, the user confirms trust in the computer. Dedicated test devices and agreed access are preferable.

Start diagnosis with the device list. In these examples, SERIAL means an actual device identifier and com.example.app means the tested application's package; replace both.

bash
adb devices -l
adb -s SERIAL shell getprop ro.build.version.release

unauthorized indicates a trust problem, while offline indicates a connection problem. Until the device is operational, failed installation commands are not a basis for application investigation.

Why to select the device explicitly

When several phones or emulators are connected, use -s. This reduces the risk of installing a build or clearing data on the wrong device. Automated run logs should include the selected serial.

Also record the model, OS, and application build number. Otherwise, even correct logs remain tied to an unknown configuration and are difficult for colleagues to reproduce.

Installation and updating

Installing an APK and replacing an existing version differ. The -r flag reinstalls while preserving application data; replacement requires a compatible signature and compliance with version restrictions.

bash
adb -s SERIAL install app.apk
adb -s SERIAL install -r app-new.apk

After Success, open the application and check its build number and reference data. Installation does not establish successful migration or core functionality. Split APK sets need an appropriate installation method; an arbitrary single file does not replace the complete package.

Clearing, stopping, and uninstalling

Compare these commands to understand their different consequences. They change device state and should target only the selected test package.

bash
adb -s SERIAL shell am force-stop com.example.app
adb -s SERIAL shell pm clear com.example.app
adb -s SERIAL uninstall com.example.app

Force-stop forcibly stops the application. Pm clear deletes its data and changes the next launch's preconditions. Uninstall removes the application. None should silently substitute for normal backgrounding or closing a screen.

These commands do not delete the server account. Reinstallation may also restore a backup, so confirm initial state separately.

Collecting useful logs

Logcat displays Android and application logs. Start collection before reproduction to preserve preceding events. For a short controlled experiment, export the current buffer to a file.

bash
adb -s SERIAL logcat -v threadtime > device-log.txt
adb -s SERIAL logcat -d -v threadtime > log-snapshot.txt

The first command runs continuously until stopped; the second exports the buffer and exits. Full logs may contain unnecessary data, so inspect them and remove secrets before sharing. Process filters help, but PID changes after restart; an overly narrow filter can miss the crash itself.

Practical example: a crash after updating

Imagine the application closes when opening an old note. Preserve both initial data and failure evidence.

  1. 1.On the agreed device, install the old build and create a note. Record its identifier and application version.
  2. 2.Update with install -r without running pm clear. Expect user state to be preserved.
  3. 3.Start recording logcat, open the application, and reproduce the crash.
  4. 4.Stop recording, retain the exact action time, and extract the exception and preceding events.
  5. 5.Restart the application and check whether the same object reproduces the problem.
  6. 6.Attach versions, serial or internal device number, steps, and sanitized logs. The expected result is an accessible note after updating.

The developer now receives an observable sequence rather than only a video of a disappearing screen.

Screenshots and system diagnostics

ADB screenshots are convenient automatic result attachments. Bugreport collects a broader diagnostic package, so consider its size and contents.

bash
adb -s SERIAL exec-out screencap -p > screen.png
adb -s SERIAL bugreport bugreport.zip

Do not collect a bugreport for every minor visual issue unnecessarily. Choose minimal evidence that explains the particular defect and follow team diagnostic-data retention rules.

ACTION_VIEW helps check routing. Do not specify a package when the goal is observing the system's handler selection.

bash
adb -s SERIAL shell am start -W -a android.intent.action.VIEW -d 'https://example.com/articles/123'

This is a diagnostic launch. Supplement it by tapping a link in an actual email or browser because the source also affects the user journey.

Common mistakes and conclusion

Avoid starting investigations by deleting data, using force-stop as a substitute for every background state, or sharing huge logs without event times. Understand each command's purpose, preconditions, and effect.

ADB strengthens QA when it makes experiments reproducible. The correct device, preserved state, and concise evidence are more useful than many commands executed without checking outcomes.

Further reading