ADB & your first safe lab

adb—Android Debug Bridge—is a command-line tool for communicating between a development computer and an Android device or virtual device. Some commands inspect; others install software, copy files, change settings, or remove data. This lesson uses connection checks and basic read-only observations only. It does not flash partitions, unlock bootloaders, root a device, or change security settings.

Before you start#

• Workstation setup — install/check host Platform-Tools and understand PATH.
• Terminal and Git — read commands safely and distinguish host output.
• Linux files and processes — process identity and host/device distinction.
• Memory and system calls — process boundaries and Android app isolation.
• Emulator-first lab — create and boot a disposable Android target before doing this lab.

Learning goals#

You can explain where each ADB component runs, distinguish connection state from privilege, select a specific target when needed, identify safe read-only observations, and protect private data in logs. You can stop and diagnose a missing/unauthorized/offline target without trying random reset or unlock commands.

Three components and two machines#

ADB has a client on your workstation, a background server on that workstation, and a device-side daemon called adbd. The client sends a request; the server routes it to a connected daemon. This is why adb devices can start a server automatically. When the server starts, it binds to local TCP port 5037. Android Developers: ADB

workstation terminal → adb client → workstation adb server
                     → USB / approved network → Android adbd

adb shell ... starts a command on the device; the adb executable itself runs on the workstation. Physical-device USB debugging must be enabled by its owner. Android may ask you to authorize that workstation's RSA key. Approve only a computer you control and intend to trust; revoke old authorizations in device settings when no longer trusted. ADB authorization

For this first exercise, use the disposable Android Emulator target prepared in Emulator-first lab. Android Emulator/AVD and Cuttlefish are distinct virtual-device environments; neither exactly reproduces retail hardware, vendor drivers, or all device behavior. A physical test device is optional only if owned or explicitly authorized, backed up, and appropriate for the exact operation. The commands here do not require a physical device. Android Emulator · Cuttlefish

Check the connection, then identity#

First check the workstation tool and target list. These commands run on the workstation (Ubuntu Bash reference route):

adb version
adb devices -l

adb version identifies the host client; it does not prove a target exists. adb devices -l lists connected targets. A healthy row typically ends in device; unauthorized is the state for a target that has not approved this workstation (AOSP adb state names); offline means the device is not connected to adb or is not responding (ADB). device describes ADB connection state—not full Android boot, root, or user consent for arbitrary actions. Serial text and descriptions vary. If several targets appear, choose one explicitly using its exact listed serial; do not type the example label SERIAL literally.

Device command launched through the workstation client; read-only:

adb shell id
adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.sdk
adb shell uname -a

The text after adb shell executes on the device. id prints the shell process's user/group identity; getprop reads Android system properties; the two ro.build... properties give release and API-level clues; uname -a reports kernel/system information. Output varies by build and some builds restrict or omit information. These observations do not inventory the whole device or prove it is an unmodified AOSP build. Read-only means the commands request information; output can still expose device details, so do not post it without review.

If you have multiple devices, select by exact serial copied from your own listing:

adb -s emulator-5554 shell id

This example is runnable only if your listing actually shows serial emulator-5554; otherwise substitute the exact serial from your own output, keeping it as one argument. It is not a universal device name. If uncertain, stop rather than guess.

Crucial distinction: adb shell is not adb root. A shell normally has limited identity/permissions; production user builds generally do not give a root shell. Development builds can differ. Check id; do not infer privilege because a command ran. Root-capable devices remain subject to other controls and can expose or damage private data.

Read logs with care#

logcat reads Android system log messages. A bounded read is easier to review than a full bug report. The command runs from the workstation and reads device logs; output appears in the workstation terminal.

adb logcat -d -t 50

-d dumps buffered messages and exits; -t 50 prints the most recent 50 lines and implies -d (AOSP logcat source at android-14.0.0_r1). Options can vary by tool version. Logs can contain app names, paths, identifiers, or user data. Inspect locally and redact before sharing; skip logs entirely if not needed. Ongoing adb logcat streams until interrupted and can generate substantial output. Logcat command-line tool

Two shell boundaries and safety#

There may be two shells in one command. In adb shell getprop ro.build.version.release, your local shell starts the host ADB program, then ADB asks the device shell to run getprop. Quotes, pipes, wildcards, and variables can be interpreted locally or remotely. Start with simple commands without shell metacharacters. ADB remote shell commands

For example, in adb shell command > output.txt, a typical local shell redirects output to a workstation file. In adb shell 'command > /some/path', the quoted redirection is interpreted by the remote shell and could write on the device. This lesson avoids remote redirection. Never run pasted commands using su, dd, fastboot flash, rm -rf, or setprop without an authorized, planned reason and recoverable lab.

ADB is a transport/debugging interface, not a universal security bypass. What a command can do depends on build, shell identity, permissions, and release. A successful ADB shell does not give an app shell access or remove the app sandbox. USB and Wi-Fi debugging are sensitive: pair only with trusted workstations/networks, and forget pairings no longer needed. ADB overview · Android app sandbox

Practice#

Context: workstation commands observing a disposable virtual Android device; no device modification. First complete the Emulator-first lab, boot its virtual target, and verify its own instructions say it is ready. Then on the workstation run adb version and adb devices -l; only continue if the intended virtual target appears as device. Next run the id, release, SDK, and kernel commands above. Keep output local; redact serials, usernames, paths, and any identifying information before sharing.

Failure branches: if the list is empty, stop and check that the virtual device is booted and that Platform-Tools is available; do not run random server reset commands. If it says unauthorized, use only the target's documented authorization prompt for a computer you control. If offline, stop and consult emulator/ADB documentation for that specific environment; do not unlock, flash, or wipe. If multiple targets appear, use an exact serial from the listing. If no virtual device can be provisioned, use source-only mode and mark the runtime exercise not yet evidenced. No physical-device runtime test is implied by this lesson.

Knowledge check#

1. adb devices -l shows a row ending in device. What does this prove, and what does it not prove?
2. In adb shell id, where does id run and where does its output appear?
3. Your device list is empty. A forum suggests fastboot flashing unlock as a connection fix. Why must you stop?
4. Why can a read-only log command still create a privacy risk?

Answers#

1. ADB reports a connection state for that target. It does not prove Android fully booted, root access, or authorization for every possible operation.
2. id runs in the device-side shell; its output is returned to the workstation terminal.
3. Unlocking is a mutating bootloader operation that can wipe data and is unrelated to a safe first connection check. Use the emulator/ADB-specific safe troubleshooting branch.
4. Logs may include personal data, identifiers, app names, paths, or secrets. Review and redact before sharing, or skip collection.

Checkpoint#

Artifact: a short private record of target type, ADB connection state, and shell identity, with identifying values redacted. For source-only learners, submit a labeled command-context diagram instead. Ready: you distinguish host client/server from device daemon, connection from root, and can explain the safe empty/unauthorized/offline branches. Revise: revisit “Three components” and “Two shell boundaries.” Not yet evidenced: no disposable target was available, or you cannot explain where a command runs; use Emulator-first lab and retry. Do not substitute a personal phone or treat this checkpoint as runtime certification.

Sources#

• Android Debug Bridge (ADB) — official client/server/daemon, connection states, shell, and command reference.
• ADB authorization — enabling debugging and approving a workstation.
• ADB remote shell — device shell invocation and quoting context.
• Logcat command-line tool — log collection options and filtering; output can vary by platform-tools version.
• AOSP logcat source at android-14.0.0_r1 — usage text: -d dumps the log and exits; -t N prints the most recent N lines and implies -d.
• AOSP adb source at android-14.0.0_r1 — to_string(ConnectionState) names the states, including offline, device, and unauthorized.
• Android Emulator — official virtual-device overview; use the separate lab for provisioning steps.
• Cuttlefish — AOSP virtual-device documentation; not interchangeable with an AVD.
• Android app sandbox — Android-specific app isolation.

Next: Find your way around AOSP.