Top ADB commands give a power user direct control over an Android phone from a computer. ADB stands for Android Debug Bridge and it connects a computer to a phone over USB or over Wi-Fi. The bridge lets you install apps and copy files and read logs and change settings that have no button in the normal menus. A power user who learns ADB can fix many problems without waiting for a menu option that may not exist. This guide explains the most useful commands in plain order and it shows how each command fits a real task.
Read the safety warning before you run any command in this guide. ADB commands can delete data and disable apps and change system behavior in ways that are hard to undo. Some commands can void the device warranty and some mistakes can cause a bootloop or a brick. Back up photos and videos and documents and accounts before you start any low level work. Test each command on a spare device first when you can and keep a full backup ready at all times.
Connection And Device Checks
Every ADB session starts with a device check and a permission prompt on the phone screen. The command that lists attached devices confirms that the cable and the driver and the phone setting all work together. If the list is empty then check the cable and try another USB port and confirm that USB debugging is turned on. If the phone shows as unauthorized then accept the prompt on the phone and run the list command again. A stable connection matters because a dropped connection during a file transfer can leave a partial file behind.
Before you change anything read the ADB and Fastboot setup guide and follow its cable and driver checks so a simple connection fault does not look like a deep system fault. The setup guide explains how to place the tools on your computer and how to confirm that the phone trusts the computer. Once the device appears in the list you can move to information commands with confidence. Keep the phone screen awake during long tasks so the connection does not sleep in the middle of a transfer.
adb devices
adb version
adb reconnectInformation And Shell Commands
Information commands show the state of the phone without changing anything. A shell session opens a command line inside the phone and it lets you inspect files and processes and settings directly. You can list the contents of a folder and check running services and read property values from the shell. These read only checks are the safest way to learn because they do not modify the system. Use them first whenever you explore a new device or a new problem.
The shell also lets you run single commands without opening a full session. A single shell command is easier to copy and easier to review than a long interactive session. For example you can ask for the device model and the system version and the current battery state from one line each. Record the output before you change anything so you can compare the state before and after a change. A short note with the original output saves hours when a change behaves in an unexpected way.
adb shell getprop ro.product.model
adb shell dumpsys battery
adb shell ls /sdcard/DownloadApp Control And Package Commands
Package commands manage apps from the computer and they are useful when an app cannot be opened on the phone itself. You can list installed packages and install a package file and uninstall a package for the current user. The uninstall option for the current user keeps the system copy intact while it removes the app from daily use. That distinction matters on phones where a system app cannot be removed in a permanent way. Always write down the full package name before you remove anything so you can restore it later.
Install commands also help when a phone screen is broken or when touch input fails. You can push an installer file to the phone and install it from the computer without touching the screen. You can also clear app data when an app keeps crashing at startup. Clearing data removes accounts and settings inside that app so back up the app data first when the app allows a backup. Never disable a core system package blindly because the phone may lose calls or messages or settings access after a reboot.
Debloating work builds on these package commands and the debloat guide for Shizuku and ADB tools shows a safer order for removing clutter without breaking core services. That guide pairs well with this command list because it explains which apps are safe to remove and which apps must stay. Read it before you run a batch uninstall script from the internet. A script that removes dozens of packages at once can break a phone in a way that is hard to trace.
adb shell pm list packages
adb install app.apk
adb shell pm uninstall -k --user 0 com.example.appFiles Logs And Reboot Commands
File commands move data between the phone and the computer without a cloud service in the middle. Pull copies a file from the phone to the computer and push copies a file from the computer to the phone. These commands are useful for logs and backups and photos and configuration files. Check the destination path after each transfer and confirm the file size on both sides. A transfer that looks complete but has a wrong size can cause confusion later when the file fails to open.
Log commands help you find the cause of a crash or a freeze. The log output shows system events in time order and it can point to the app or service that failed first. Filter the log by app name or by error level so the output stays readable. Reboot commands move the phone into normal mode or recovery mode or bootloader mode. Use the bootloader target only when you have a clear plan for the next step because a phone in bootloader mode cannot make calls until it restarts.
System property work also starts from ADB and the build prop editing guide explains how a single property change can alter behavior across the whole system. That guide warns about the same backup rule that applies here. Do not copy a property value from another phone model without checking that the property exists on your own device. A property that means one thing on one model can mean something else on another model.
adb pull /sdcard/Download/log.txt .
adb push file.zip /sdcard/Download/
adb logcat -d
adb reboot bootloaderSafe Habits For Daily ADB Use
Safe ADB use is mostly a habit of small steps and clear notes. Run one command at a time and read the output before you run the next command. Keep a text file with the exact commands you ran and the exact output you saw. That file becomes your rollback plan when a change needs to be undone. Avoid pasting long command chains from random posts because one wrong flag in a chain can change many things at once. Break a chain into single steps and test each step on its own.
Before you run a risky command read the bootloader unlock tutorial and note how a low level change can wipe data even when the command itself looks harmless. The same caution applies to ADB commands that touch system partitions or protected settings. Keep the battery above half charge during any long operation and use a cable that stays firmly connected. A loose cable during a write operation is a common cause of a corrupted file or a failed update.
Device Checks Beyond The Basics
A device check can also reveal whether the phone runs in normal mode or in a special mode that limits commands. Normal mode supports the widest command set while recovery mode supports a smaller set focused on sideload and file access. Bootloader mode supports fastboot commands rather than ADB commands and that distinction confuses many beginners. Check the mode first when a familiar command suddenly fails because the phone may have rebooted into a different mode after an update. A mode aware habit prevents wasted time on commands that cannot run in the current state.
Wireless ADB adds convenience and it adds a security step that wired ADB does not need. Pairing over Wi-Fi requires a pairing code and a port number and both values change in some setups. Keep wireless debugging off when you do not need it because an open wireless bridge on a shared network invites unwanted access. Use a private network for wireless sessions and turn the feature off as soon as the task ends. Wired ADB stays the safer default for long or sensitive sessions.
Multiple devices on one computer need a serial target in each command so ADB knows which phone should receive it. List devices first and copy the exact serial for the target phone into the command. A command sent to the wrong phone can install or remove software on a device you did not intend to touch. That risk grows when two phones share the same model name and look identical on a desk. Label cables and label phones during multi device work.
Logs And Output Habits
Log output becomes useful only when you save it with context about what you were doing at that moment. Note the time and the app you were testing and the command you ran just before the log capture. Without that context a log file is a wall of events with no story. With context the same log points to a clear cause in minutes. Keep log files in a dated folder so old logs do not mix with new logs from a different problem.
Output redirection helps you keep a clean record without copying text by hand from a scrolling terminal. Redirect long output to a text file and then search that file for error words and for the app name you care about. A saved file also lets you compare a good run with a bad run side by side. That comparison often reveals a missing service or a changed permission that a single glance would miss. Treat every important session as a session worth saving.
Exit codes and error text deserve the same attention as successful output. A command that prints no error but changes nothing may have failed silently because of a permission limit. Check the state after the command with a read only command instead of assuming success from silence. A quick verification step after each write command turns silent failures into visible failures that you can fix early.
Command Reference Habits
Build a personal command reference file with each command and a short note about what it does and when you used it last. A personal reference beats a random internet list because it reflects commands that worked on your own devices. Update the file after each session with any new command that proved useful. Delete commands that failed repeatedly on your current system so the reference stays trustworthy. A clean reference file saves time during urgent repairs when searching the internet is not possible.
Test commands in a safe order by running read commands before write commands in every new session. A read command confirms connection and confirms device state without risk. A write command should only follow a successful read that matches your expectation. When a read shows an unexpected state stop and investigate before you write anything. That pause prevents a write based on a wrong assumption about which device is connected.
Teach ADB to others with the same safety order you use yourself. Show device checks first and show read commands second and show write commands last with a backup warning before each write. A learner who copies write commands without the safety order will eventually damage a device. A learner who understands the order will solve problems calmly instead of panicking after a mistake.
ADB rewards patience and punishes haste. Learn the read only commands first and add write commands only when you understand what each flag does. Back up before every session and verify the backup before you trust it. With those habits ADB becomes a reliable tool for repair and testing and learning instead of a source of surprise failures.
