简介：这是一份面向 Android 开发、测试与运维人员的 ADB 常用命令速查压缩包，主要解决设备连接、应用安装调试、日志排查和系统控制等日常高频需求，既适合初学者逐步熟悉 adb 操作，也适合有经验的开发者随手翻阅。压缩包内共收录 2 个文件，以 docx 格式的整理文档为主体，另有 1 个 C 语言辅助文件作为补充，整体体积仅 19KB，轻量易携带。文档围绕真实调试流程组织内容：先从 adb devices 检查设备在线状态，再介绍安装与卸载应用时如何指定 apk 路径和包名；接着展开 adb shell 下的常用文件命令，以及通过 push、pull 在电脑与设备之间同步数据；随后覆盖 logcat 日志抓取与关键字过滤、pm 命令查询已安装应用、ps 查看进程、强制停止应用等操作。此外，还包括屏幕截图、屏幕录制、无线调试连接、重启设备与引导加载程序等进阶用法，并对每个命令补充参数写法和使用场景。已有 914 人学习下载，作为一份体积小、结构清晰的命令索引，能帮助读者减少记忆负担，提高设备调试效率。

1. ADB 常用命令文档真正值钱的部分：连接、取日志、卸应用三条主线

拿到ADB常用命令文档.zip，别急着解压完就丢进网盘。它值钱的地方不是几个 txt 文件，而是把高频率的 adb 命令按场景整理成速查手册：连接设备、安装卸载应用、抓 logcat、pull/push 文件、截图录屏、重启关机，基本覆盖 Android 调试的日常。它解决的不是“ADB 是什么”这种概念问题，而是“设备连不上、日志抓不到、预装应用卸不掉”时，能照着手册快速定位该敲哪条命令。我通常把它当离线 SOP 用：命令行卡住了，先翻文档，再看当前设备状态，而不是凭记忆盲试。适合刚接手 Android 调试的新人，也适合一天验几十台设备的硬件测试。

2. 用最小环境跑通第一条 adb 命令：安装、授权与无线连接

2.1 为什么先装 Android SDK Platform-Tools，而不是找一堆“ADB驱动”

很多人第一次接触 ADB，搜到的是“ADB驱动”或者“万能驱动”。但注意，adb 的本体在 Android SDK Platform-Tools 里，官方发布的压缩包自带 adb.exe（Windows）、adb（macOS/Linux）以及 fastboot 等工具。装了这个，才有命令行里的 adb；额外装驱动只影响电脑能不能识别硬件，不影响 adb 程序是否存在。所以命令文档里第一部分，永远是“工具准备”，不是“驱动安装”。

macOS 上最省事的安装方式是 Homebrew：

# macOS 使用 Homebrew 安装 platform-tools brew install android-platform-tools # 安装完先确认版本 adb version

brew install android-platform-tools会把 adb 装进 Homebrew 的 bin 目录，通常已经加入 PATH。执行adb version看到类似Android Debug Bridge version 1.0.41的输出，说明第一步跑通。

Windows 上常见做法是去 Android Developers 官网的 platform-tools 页面下载 zip，解压到比如C:\platform-tools。先临时加进 PATH 确认能用：

# 临时把 platform-tools 加进当前会话，重启终端失效 $env:Path += ";C:\platform-tools" # 验证 adb version

$env:Path +=只对当前 PowerShell 进程有效，重启终端后还要再设。确定没问题后，再通过“系统属性—环境变量”把C:\platform-tools永久加到 PATH，后续就不用每次都 cd 到目录里。这个步骤在命令文档里一般不会细写，但恰恰是“adb 不是内部或外部命令”问题的高发区。

顺带回答一个搜索热词：adb 驱动需要 USB 调试模式吗。大部分现代 Android 手机只要在开发者选项里开启 USB 调试，插上电脑就能被adb devices识别；只有少数冷门机型或老 Windows 系统才需要补装厂商 USB 驱动。别去装一堆来路不明的“ADB驱动全集”，系统里多几个未知设备反而更乱。

2.2 手机端开启“开发者选项”和“USB 调试”的完整顺序

以原生 Android 为例，路径是：设置 → 关于手机 → 连续点击“版本号”7 次 → 返回设置，找到“系统 → 开发者选项”或“更多设置 → 开发者选项”。打开开发者选项后，再把“USB 调试”开关打开。这一步没有任何命令可以替代，因为 adb 的授权本身需要用户在手机上确认，这也是文档里不该跳过的一步。

插上数据线后，先执行一次：

# 列出当前所有连接的 Android 设备 adb devices

正常输出右侧会是device，例如：

emulator-5554 device R58M123ABC device

如果显示unauthorized，说明手机弹窗还没点允许。此时手机桌面上会有一个“允许 USB 调试吗？”的对话框，勾选始终允许然后确定。如果没有弹窗，右上方通常也能看到“允许USB调试”的通知；实在不弹，把数据线拔掉重插，或者在开发者选项里点“撤销 USB 调试授权”再重来。

这里有一个很常见的误操作：把“USB 用途”从“传输文件”切到“仅充电”甚至“反向充电”。部分机型会在切换瞬间把调试通道断开，表现就是adb devices从device变成空列表。遇到这种情况，先把 USB 模式固定到“文件传输”，再执行adb kill-server && adb devices重新枚举。

另外，建议理解一下 adb 的底层结构：本机始终有一个 adb server 进程，设备端则跑一个 adbd 守护进程。你敲adb devices时，本机 server 会自动启动，然后向设备端询问状态。如果之后遇到“连不上”“显示 offline”但又不确定原因，先执行adb kill-server重启一次本机服务，可以排除掉一半以上的“玄学问题”。

2.3 无线连接：adb tcpip 与 adb connect

数据线不够长，或者设备是电视、车机、嵌入式板子时，无线方式更实际。前提是手机和电脑在同一局域网段。先用 USB 跑通一次授权，然后执行：

# 让设备在 5555 端口监听 adb adb tcpip 5555 # 通过 IP 与设备建立 adb 连接 adb connect 192.168.1.23:5555

第一行的tcpip 5555只在当前开机状态下生效，重启后失效。最常见的选择是固定 5555 端口，但如果你电脑上有多台设备或 5555 被占用，也可以改成 6666，例如adb tcpip 6666后adb connect ip:6666。改端口后要自己记住，后面adb disconnect ip:6666时也要带上端口，端口不对会出现连接已存在但什么都干不了的情况。

顺手查设备 IP 的办法，不依赖图形界面：

# 在已连接的设备上查看当前网段 adb shell ip route

ip route输出像是default via 192.168.1.1 dev wlan0和192.168.1.0/24 dev wlan0，从中读设备自身 IP。如果你同时插着多台设备，需要加-s指定序列号：

adb -s R58M123ABC shell ip route adb -s R58M123ABC tcpip 5555 adb connect 192.168.1.23:5555

不指定序列号时，多设备环境会直接报错more than one device，这也是命令文档里最容易忽略的一行参数。

还有一个容易混淆的点：Android 11 及以上自带“无线调试”功能，需要配对码，流程是先用adb pair 设备IP:配对端口输入配对码，再用普通adb connect连接。而电视、车机和很多国产盒子只认adb tcpip 5555这条老路。命令文档如果只写“无线调试”，你会在这些设备上踩一圈坑。我的顺序是：先试adb connect ip:5555，失败再查系统版本，最后决定用配对还是老办法。

3. 把常用命令文档拆成四块：文件、应用、日志、系统控制

3.1 文件推送与拉取：adb push、adb pull 及权限边界

文档里最常用的两类文件操作是adb push和adb pull。它们的语法很简单，真正麻烦的是权限边界：

# 从设备拉取文件到电脑当前目录 adb pull /sdcard/Download/netlog.txt ./netlog.txt # 把测试脚本推送到设备 /data/local/tmp 并授权 adb push ./test.sh /data/local/tmp/ adb shell chmod 755 /data/local/tmp/test.sh

第一个路径是设备端，第二个路径是电脑端。/sdcard路径普通权限可读，适合同志之间传日志；/data/local/tmp是 adb shell 用户能写入的临时目录，适合放测试脚本，但它不在全局 PATH 里，执行时要用完整路径或者先chmod 755再通过sh /data/local/tmp/test.sh调用。

注意：adb pull不是从设备文件系统直接读，而是通过 adbd 的权限访问。普通 adbd 在非 root 设备上只能访问/sdcard、/data/local/tmp等公共区域，遇到/data/data/com.app/databases这种应用私有目录，多半会报Permission denied。想拉这种文件，一是设备有 root 权限，一是先run-as切换身份：

# 先看能不能用 run-as 进入应用私有目录 adb shell run-as com.example.app ls databases adb shell run-as com.example.app cat databases/app.db > local.db

这只对 debug 应用适用。命令文档里如果只写“adb pull 设备路径 本地路径”，不会提醒你权限问题，真正拿到手的是空文件或者报错。我的习惯是 pull 完马上ls -l看一眼文件大小，而不是直接去解包。

反过来推送到设备时，优先推到/data/local/tmp，不要推到/system、/vendor这类分区。没有 root 权限时写/system必失败；有 root 权限时，推错文件覆盖系统库，设备就等着卡 logo。文档里加一行“少碰系统分区”，能省下你后半周的加班。

3.2 应用安装、覆盖更新与卸载（含 pm uninstall --user 0 的完整参数）

安装 APK 时，最常用的是覆盖安装，因为测试阶段经常要频繁更新版本：

# 普通安装 adb install app.apk # 覆盖安装，保留用户数据；-d 允许降级版本 adb install -r -d app.apk

参数含义：

• -r：允许覆盖安装并保留数据
• -d：允许低版本覆盖高版本
• -t：允许安装测试包，Debug 包常用
• -s：安装到 SD 卡，老设备上偶尔用

卸载命令分两类。第三方应用直接卸载：

# 完全卸载第三方应用 adb uninstall com.example.app

系统内置应用，尤其电视盒子和运营商定制设备上，常见写法是：

# 对系统应用做“禁用而非卸载”，用户 0 指主用户 adb shell pm uninstall --user 0 com.example.bloatware

pm uninstall --user 0的实际效果是删除主用户下的应用副本，系统包本身还在。但这句命令不能乱用：卸载了某个被系统组件依赖的包，设置会闪退，桌面可能异常，甚至开机卡动画。所以命令文档里如果写了这条，最好同时写一句备用命令，先把包名归档：

# 列出第三方应用包名，方便卸载前留底 adb shell pm list packages -3

更稳妥的替代方案是禁用而不是卸载：

# 禁用指定用户下的应用，恢复时用 pm enable adb shell pm disable-user --user 0 com.example.bloatware

禁用可以随时pm enable com.example.bloatware恢复，卸载后恢复路径更长。如果不是做固件定制，建议优先用 disable-user，给自己留后悔药。

3.3 日志抓取：adb logcat 的缓冲区、过滤与落盘

logcat 是排查崩溃、ANR、运行时打 Log 的核心命令。命令文档里最常出现的三个参数是-c、-d、-v threadtime：

# 清空所有历史日志，确保下一次抓到的是新日志 adb logcat -c # 带线程和时间的日志输出到文件，前台滚动 adb logcat -v threadtime > app.log

先清空再操作，是因为设备已经开机运行很久，缓冲区里堆了海量无关信息。清空后执行复现步骤，最后 Ctrl+C 结束，拿到的是从复现起点开始的完整记录。-v threadtime让每行带上进程号、线程号与时间，回看时能直接对上崩溃时刻。

抓单应用日志时，不要凭眼睛找 pid。用 shell 组合先解析：

adb logcat --pid=$(adb shell pidof -s com.example.app)

pidof -s只输出一个进程，如果应用是多进程且没过滤，日志会混在一起。若应用没运行，pidof返回空，--pid抓不到任何内容。搜索引擎里常有人问“adb logcat 抓取日志怎么没有输出”，八成是先清了缓冲但复现步骤在日志开始前就结束了，或者过滤条件把日志全滤掉了。

3.4 系统操作命令：截图、录屏、重启、关机

验收和 bug 描述最需要的是截图与录屏，过去最容易翻车的是把 screencap 的二进制内容直接输出到终端。正确姿势：

# 截图并保存到电脑 adb exec-out screencap -p > screen.png # 录屏 20 秒，保存到设备后再拉取 adb shell screenrecord --time-limit 20 /sdcard/demo.mp4 adb pull /sdcard/demo.mp4

exec-out能避免 shell 层对二进制输出的干扰，Windows PowerShell 重定向得到损坏 PNG 的概率会小很多。录屏参数--time-limit单位是秒，最长一般 180 秒，测试时先录短一点。还有个细节：录屏文件格式是 mp4，但真正播放速度取决于设备编码能力，超时长录制中途失败的情况并不少见。

另外两个常用系统操作：

# 重启系统 adb reboot # 关机，部分设备不支持 adb reboot -p

adb reboot -p在手机大多表示关机，在电视盒子上行为随厂商而定，有些只等同重启。远程调试时如果身边没人能帮忙开设备，执行关机前先确认自己有没有物理恢复手段，否则设备会一直睡到明天。

对电视、机顶盒、车机这些设备，搜索里常出现的“ADB键盘”“万能车机adb工具”大多是带图形界面的小工具，底层调用的还是这些系统命令。工具能归并窗口，但报错信息和参数边界还得你自己判断。

4. ADB 连接排错与避坑：unauthorized、offline、误卸载系统应用的 5 条记录

4.1 “‘adb’ 不是内部或外部命令”多半是环境变量，不是命令缺失

现象：命令行输入任何 adb 命令，返回'adb' 不是内部或外部命令，也不是可运行的程序或批处理文件（Windows），或者command not found（macOS/Linux）。

原因：platform-tools 没安装，或者路径没写入 PATH。

解决：先执行adb version，如果提示找不到，再用完整路径测试一次；Windows 是C:\platform-tools\adb.exe version，macOS 是/usr/local/bin/adb version或 Homebrew 安装后的实际路径。确认能跑后，把 platform-tools 目录永久写进 PATH。别只把adb.exe复制到别的目录，platform-tools 里的其它动态库是一套的，拆开会出各种奇怪问题。

4.2adb devices一直显示 unauthorized 怎么解决

现象：手机已连接，但状态是unauthorized，而不是device。

原因：授权链没打通。手机上没点“允许USB调试”，或之前误选了“仅充电”，也可能授权记录过期。

解决：重新插拔数据线，观察手机弹窗，勾选“始终允许”后确定。如果弹窗已经消失，到开发者选项里点“撤销 USB 调试授权”，再重新插入。也可以先用adb kill-server重启本机服务，再跑adb devices。大部分情况下，问题不是驱动，而是弹窗没点。

4.3 无线连接后 offline，或连接上就掉

现象：adb connect 192.168.1.23:5555返回 connected，紧接着adb devices状态是 offline；或者用了几分钟就消失。

原因：手机与电脑不在同一网段、设备休眠、固件无线调试策略异常。

解决：先确保同网段；再关掉设备的省电策略，或者插着电别灭屏。Windows 防火墙偶尔会拦 adb 的 5555 端口，可以先临时关掉防火墙测试，确认是防火墙问题后单独加一条入站规则。部分老电视、车机上，adb tcpip 5555之后还需要在系统设置里保持屏幕常亮。搜索里常问的“老款创维如何打开 adb”，多半也是入口藏得深，不同版本路径不一样，但最终都要先把无线调试或开发者模式打开，再走adb connect。

4.4 logcat 抓不到应用日志

现象：应用崩溃后，logcat 里找不到自己包名的日志，或者日志文件前半段全是历史垃圾。

原因：缓冲区没清干净，或者过滤条件不对。

解决：先清空再复现，复现完成后用进程过滤：

adb logcat -c # 复现一次崩溃或操作 adb logcat --pid=$(adb shell pidof -s com.example.app)

如果知道具体 tag，比如网络库打的是OKHttp，可以用adb logcat -s OKHttp。注意前提是进程还活着，应用已经闪退退出，pidof会拿到空值，这时换成应用最后停留的日志缓冲段，或从adb logcat -d | grep 包名里捞。

4.5 pm uninstall --user 0 后开机异常

现象：卸载某个系统应用后，开机卡动画、设置闪退、桌面图标消失，严重时无限重启。

原因：被卸载的应用被其它系统组件依赖，uninstall --user 0移除了主用户下的包，调用方还在，系统找不到组件就开始连环崩溃。

解决：在还能连 adb 时尽快恢复安装：

adb wait-for-device adb shell pm install-existing com.example.systempackage

如果设备已经卡在重启无法进入桌面，但 adb 还能识别，那就连上后立刻执行恢复命令。恢复不了的情况下，能保住数据的办法不多，只能考虑恢复出厂设置。所以遇到陌生系统包，先pm list packages -f把路径记录下来，再决定是否禁用一个系统应用。改卸为停，才能不让这次排查变成设备变砖事故。

5. 把常用命令文档变成可复用脚本：批量安装、批量查机、定时抓日志

5.1 批量查设备型号与系统版本：从 adb devices 到循环脚本

文档看再多，到现场还是需要一次看一堆设备。以 bash 为例，先拿到所有设备序列号，再逐个获取型号与 Android 版本：

#!/bin/bash # 列出所有处于 device 状态的设备序列号 devices=$(adb devices | awk 'NR>1 && $2=="device" {print $1}') for sn in $devices; do echo "---------- $sn ----------" adb -s "$sn" shell getprop ro.product.model adb -s "$sn" shell getprop ro.build.version.release done

adb devices的默认输出首行是List of devices attached，从第二行开始是序列号和状态。用awk的NR>1跳过标题，$2=="device"过滤掉 unauthorized 和 offline，只保留可用设备。查询属性时用adb -s $sn指定序列号，避免多设备时 adb 不知道该发给哪台。

5.2 批量安装 APK：-r 保留数据，循环失败不中断

做多设备固件升级时，一台台手动安装太浪费时间。批处理脚本能解决，但要注意失败不中断：

#!/bin/bash for apk in ../apk/*.apk; do echo "== install $apk ==" adb install -r "$apk" || echo "[$apk] failed" done

-r表示覆盖安装，适合升级测试，保留应用数据。|| echo让单个安装失败时输出标记，但不会中断整个循环。默认adb install输出Success或Failure [reason]，脚本里加错误提示能让你快速定位哪台设备出了问题。Windows 下用 PowerShell 时，把 for 换成Get-ChildItem | ForEach-Object同样可以实现。

5.3 定时抓取 logcat 并按日期归档

压力测试时，日志要按时间归档，方便回看崩溃起始点：

#!/bin/bash log_file="log_$(date +%Y%m%d_%H%M%S).txt" adb logcat -v threadtime > "${log_file}" & pid=$! echo "collecting logs, pid=$pid" # 等一段时间后再杀进程，避免无主进程一直挂后台 sleep 300 kill "$pid"

$!保存后台进程 PID，kill在收集完成后结束 logcat。如果只跑前台，Ctrl+C 结束也可以。落盘日志最好带-v threadtime，回看时能知道崩溃发生在哪一秒。Android 13 之后部分设备 logcat 写入频繁会产生较多小文件，脚本里如果能按天归档，会比一个文件一直涨更好维护。

5.4 给命令文档做一份“冒烟测试清单”

把静态命令文档变成可执行检查表，是防止现场翻车的最后方法。至少包含设备连接、安装卸载、文件访问、日志输出、重启恢复五个点：

adb devices adb shell pm path com.android.settings adb push ./small.txt /sdcard/ adb logcat -d | tail -20 adb reboot

adb shell pm path com.android.settings应该返回 settings 包路径，例如package:/system/app/Settings/Settings.apk。如果返回空，说明系统包被改过或包名不对，后续功能测试就不用继续了。把这几个检查项贴进自己的运维笔记，每次拿到新设备都先跑一遍，能省掉大量现场返工。

6. 文档之外的进阶用法：批量导出应用清单，在刷机前做好设备体检

最后说一个我习惯在小版本升级前做的事：把一批设备的已安装应用清单和版本号导出成文本，对比升级前后差异。这一招在测试机多、刷机频繁的场景很实用，命令文档里那几条pm list packages和dumpsys合起来就是一套设备体检。

#!/bin/bash # 导出第三方应用清单 adb shell pm list packages -3 | sed 's/^package://' | sort > app_list.txt # 导出某个应用的版本号，方便对比升级前后 adb shell dumpsys package com.example.app | grep -E "versionName|versionCode"

sed 's/^package://'去掉package:前缀，sort让文件更适合做 diff；dumpsys package在厂商系统上输出几百行，先 grep 出版本字段即可。执行完用diff app_list.txt pre_upgrade.txt对比差异，哪些新装、哪些被卸载一目了然，省去一台台点开应用列表的工夫。

我自己的习惯是给命令文档重排成自己熟悉的顺序：连接、文件、应用、日志、系统、脚本。每次拿到新工具或新设备，先在文档末尾补一条“容易忘的细节”，比如“多设备用 -s”“卸载系统包前先 pm list packages -f”。这几年踩过的坑，大部分不是命令记不住，而是环境没确认就动手。拿什么都先adb devices看一眼连接状态，再开始规划，已经成了肌肉记忆。

网络上的命令文档很多，但能救你的往往不是最全的那份，而是你能快速找到并照着执行的那份。希望帮到你。

本文还有配套的精品资源，点击获取