做设备端测试这几年真正让我对 ADB 从“会用几个命令”变成“顺手工具”的时刻是某次在 Windows 系统下排查一台连不上电脑的安卓设备时折腾了两小时却发现只是驱动没装对。类似这种在 Windows 下跑 ADB 命令的怪问题几乎每个接触安卓开发、测试或刷机的人都遇到过。市面上讲 ADB 的文章很多但大多只给命令清单不讲取舍、不解释报错结果你抄过来一样跑不通。这篇就把我日常在 Windows 下真正高频使用的 ADB 命令、配置步骤、排错思路一起梳理出来读完你可以直接照着用也适合把它当一份速查手册收藏。ADB 的全称是 Android Debug Bridge翻译过来就是“安卓调试桥”它负责让电脑和安卓设备之间建立通信。你可以在电脑上操作设备里的文件、安装卸载应用、模拟点击滑动、抓取运行日志甚至控制设备的系统设置。前提是你得先把环境搞定这一步劝退了不少人所以我先从最基础的安装和连接讲起。1. 从安装到第一个设备识别ADB 环境配置的完整闭环1.1 下载与配置为什么我建议把 platform-tools 路径写进系统变量ADB 不是 Windows 自带的命令需要去开发者官网下载 SDK Platform Tools。解压后会得到一个 platform-tools 文件夹里面就有 adb.exe、fastboot.exe 等关键文件。很多教程会告诉你“直接进到这个文件夹里执行 adb”实际上更推荐把它配置到环境变量 Path 里这样不管在哪个目录打开命令行敲 adb 都能直接执行不用每次 cd 到绝对路径。配置步骤很简单Win R 输入 sysdm.cpl 打开系统属性切到“高级”选项卡点“环境变量”在“系统变量”里找到 Path 这项点编辑新建一行填上你解压后的绝对路径比如 D:\platform-tools。保存之后重新打开一个命令提示符窗口输入 adb version能看到版本号说明已经配好。这里有个新手特别容易踩的坑配置完环境变量后还在原先开着的那个 cmd 窗口里敲 adb会提示“不是内部或外部命令”。这不是没配好而是环境变量的刷新需要重新打开终端。命令行进程读取环境变量的时机是在启动那一刻已经打开的窗口不会自动感知新配置所以忘了这一点会白白浪费好几分钟。另外解压路径尽量避免中文和空格。虽然 ADB 本身对中文路径的兼容性已经改好了很多但一旦你后面在批处理脚本里拼接路径空格会引入引号嵌套的麻烦中文编码在部分旧版 Windows 终端下还会出现乱码。老老实实放在 D:\platform-tools 这类纯英文目录能省去很多额外问题。1.2 驱动是 Windows 系统下最容易翻车的环节我见过很多人 ADB 工具下载好了环境变量也配好了插上手机执行 adb devices输出却是空列表设备型号根本不出现。问题大概率出在 USB 驱动而不是 ADB 本身。Windows 对安卓设备的驱动支持比较“随缘”有些手机插上就能用通用 ADB 接口有些必须安装厂商专用 USB 驱动。遇到设备没识别先把设备管理器打开Win X - 设备管理器看看是否有一个带黄色感叹号的 Android Composite ADB Interface 或“其他设备”下的未知设备。有的话右键选择“更新驱动程序” - “浏览我的计算机以查找驱动程序”手动指向你解压的 platform-tools 目录或者电脑上已经安装的厂商驱动目录让它强制装一次。手机端也要检查两个点一是开发者选项里的“USB 调试”必须打开二是 USB 连接模式最好选择“文件传输”或者 MTP 模式不要只是“仅充电”。有些手机在“仅充电”模式下根本不把 USB 服务拉起来ADB 自然连不上。第一次插线时设备上会弹出“是否允许 USB 调试”的窗口必须点“允许”如果手滑点成“拒绝”后面所有 adb devices 都会显示 unauthorized需要去开发者选项里撤销授权后再插一次。一台设备第一次连接时电脑端和手机端会交换一次 RSA 公钥指纹。电脑端的密钥默认存在用户目录下的 .android 文件夹里这也是后面排查 unauthorized 问题时的关键位置先记住这个点。1.3 验证连接adb devices 输出里藏着的状态信息环境配好、驱动装好、手机允许调试之后执行 adb devices能看到类似这样的输出List of devices attached emulator-5554 device 0123456789ABCDEF device最后一列是设备状态最常见的三种device 表示正常连接可用unauthorized 表示设备端未确认授权offline 表示设备连接异常或驱动不稳定。不同状态的处理方式不一样unauthorized 重点排查授权弹窗offline 则优先怀疑数据线、USB 口、驱动冲突。电脑上已经装了多种手机助手类软件时它们的进程可能抢占 ADB 端口建议安装后直接关闭自启或者把它们的连接服务停掉。如果 adb devices 一直卡住没反应先执行 adb kill-server再执行 adb start-server 重启服务端这是 Windows 下清理 ADB 状态最常用的组合拳。还有一种是 5037 端口被占用可以用 netstat -ano | findstr 5037 查看占用进程确认不是 adb.exe 后再杀掉那个进程。ADB 服务端负责和所有设备通信这个端口一旦被劫持整个调试链路都会变得很诡异。2. 高频 ADB 命令实战应用管理、文件传输与日志排查2.1 应用管理从安装到卸载、禁用、清除数据的全流程搞定连接后最常用的就是应用相关操作。安装一个 APK 用 adb install加上绝对路径即可比如 adb install D:\test\app.apk。如果设备上已经装了同一签名应用需要覆盖安装加 -r 参数如果目标是跑兼容性测试安装的 APK 是测试包要加 -t如果应用请求运行时权限想一次性全部授予加 -g。综合起来常用的一条是adb install -r -t -g D:\test\debug.apk卸载是 adb uninstall 后面跟包名不是跟应用名称。想知道包名最直接的办法是执行 adb shell pm list packages列出全部包名。Windows 命令提示符里没有 grep可以用 findstr 做过滤比如adb shell pm list packages | findstr tencent这条命令会筛出所有含 tencent 字样的包名。注意这里有个细节管道符 | 在 Windows cmd 里由本地命令行解析adb 会把前面的输出返回给本地管道所以可以直接用 findstr 过滤。PowerShell 也可以但管道行为略有差异后面讲到 shell 命令时再细说。清空应用数据用 adb shell pm clear 包名相当于应用设置里的“清除存储空间”会重置应用的所有本地数据和登录态做测试前清理非常实用。强制停止应用用 adb shell am force-stop 包名和用户在最近任务里划掉不太一样这个命令会直接让应用进程退出并且系统不再保留后台状态。启动应用也有讲究只知道包名不知道 Activity 名时可以先命令adb shell monkey -p 包名 -c android.intent.category.LAUNCHER 1这条命令本质是通过 Monkey 工具触发应用的主入口 Activity。或者直接指定组件名启动adb shell am start -n com.example.app/.MainActivity实测下来Monkey 方式更省事不需要去反查 Activity缺点是偶发会触发一些额外事件但只启动一次的话很稳。2.2 文件传输adb push / adb pull 的边界与权限问题从电脑往设备传文件用 adb push从设备取文件用 adb pull。日常用得最多的是往 /sdcard/Download 目录推送安装包或测试素材adb push D:\test\video.mp4 /sdcard/Download/ adb pull /sdcard/Download/video.mp4 D:\test\Windows 路径里有空格时一定要用双引号把整个路径包起来比如 adb push C:\Program Files\setup.apk /sdcard/。设备端路径用的是正斜杠 /sdcard/而 Windows 本地路径习惯用反斜杠这个很容易在混写时搞错。ADB 命令解析时会把反斜杠当作 Windows 路径分隔符所以设备侧路径写反斜杠反而可能解析失败。有个实操中的边界问题很多人尝试 adb push 到应用私有目录 /data/data/ 下大概率会报 Permission denied。普通设备上 /data 目录权限受保护只有 root 或 run-as 才能访问。正确做法是先把文件 push 到 /data/local/tmp 或 /sdcard/ 这种公共可写位置然后通过 adb shell 配合 su 或 run-as 挪到目标位置。如果只是为了放测试文件直接放 /sdcard/ 最稳妥。设备端文件管理也可以用 adb shell 执行 Linux 命令比如 adb shell ls /sdcard/、adb shell rm /sdcard/test.mp4、adb shell mkdir /sdcard/backup。这些命令实际跑在设备端的 shell 里和 Linux 终端里的体验基本一致。2.3 日志不只看 logcat抓取系统级运行状态排查问题必备的一条是 logcat。Windows 下最推荐先加时间线程格式adb logcat -v threadtime这样每条日志会带上时间、进程号、线程号和应用标签定位堆栈时才不会一头雾水。如果日志刷新太快可以先 adb logcat -c 清空缓冲区然后复现问题再 adb logcat -d log.txt 把缓冲区一次性导出到本地文件用文本编辑器慢慢看。注意 重定向用的是 Windows 本地命令解析输出到文件是没问题的但如果直接 adb shell logcat 想导到文件反而会有编码和换行的小坑。要按标签过滤比如只看某个模块adb logcat -s AudioTrack:E这条命令的格式是 标签名:级别E 表示只看 Error 级别也可以写成 V、D、I、W。多标签过滤用逗号分隔比如 -s TAG1:I,TAG2:E。比 logcat 更偏系统级的是 dumpsys。它把系统服务内部状态拉出来给你看命令格式是 adb shell dumpsys 服务名。常用几个adb shell dumpsys battery 看电量、温度、充电状态adb shell dumpsys meminfo 包名 看应用内存占用adb shell dumpsys activity top 看当前界面的 Activity 信息adb shell dumpsys batterystats 看整机耗电统计热搜里提到的 adb shell dumpsys batterystats --enable full-wake-history 是干什么用的它开启完整唤醒历史记录然后你正常操作一段时间再执行 adb shell dumpsys batterystats 就能看到哪些应用频繁唤醒系统、哪些持锁时间过长是做功耗分析时非常硬核的一条命令。分析完记得 adb shell dumpsys batterystats --reset 重置统计避免下次统计包含历史脏数据。3. 深入 shell用 adb shell 做 Windows 下做不了的事3.1 shell 基础远程执行命令与 pm/am 两大核心从这一章开始你的电脑就不再只是“安装应用”的工具而是能直接操纵设备内部状态的控制台。adb shell 有两种用法直接跟命令执行一次比如 adb shell ls /sdcard/不带任何命令进入交互式 shell像连了 SSH 一样在设备终端里敲命令。Windows 命令行和 adb shell 之间有一层“命令解析归属”的混淆我重点说一下。在 cmd 里执行adb shell ps | findstr com.android管道符会被 Windows 本地 cmd 解释所以流程是 adb shell ps 的输出回到本地再交给 findstr。如果写成adb shell ps | grep com.android加了双引号后adb 会把引号里的整体字符串发给设备端 shell 执行管道符由设备端解释这时用的是设备里的 grep 命令Windows 本地不需要有 grep。这层区别在自动化脚本里很容易踩坑代码里如果混用两套解析逻辑命令结果会完全不同。我在脚本里习惯了给设备侧命令都套上一层双引号保持设备端执行的一致性本地管道则单独写在管道符前后。pm 和 am 是两个核心命令。pm 是 Package Manager 的缩写负责包管理常见操作有 pm list packages、pm clear 包名、pm disable 包名禁用应用、pm enable 包名重新启用。am 是 Activity Manager 的缩写负责应用生命周期和 Intent 管理前面用到的 am start、am force-stop 都属于它。两者配合基本能覆盖绝大多数应用侧操作。3.2 输入模拟用命令行控制设备的点击、滑动和按键自动化测试场景里input 命令是灵魂。基本原理是通过 adb shell input 注入触摸事件或按键事件让设备像真人一样操作 UI。常见用法adb shell input tap 520 1280 adb shell input swipe 500 1500 500 300 300 adb shell input keyevent 4tap 后面的两个数字是屏幕上的 x、y 坐标单位是像素。swipe 后面是起终点坐标和滑动时长单位毫秒。keyevent 的键码有约定3 是 Home4 是返回键26 是电源键220 是静音键224 是亮屏/灭屏。做回归测试时我会写一个循环脚本来重复启动应用、滑动、返回全程不需要手动碰设备。获取当前界面的应用和坐标可以先用 screencap 截图adb exec-out screencap -p screen.png这里特意用了 exec-out 而不是 adb shell screencap。原因很关键Windows 默认会把控制台输出里的换行符做转换直接重定向保存 PNG 可能损坏二进制内容导致图片打不开。exec-out 从 ADB 的原始输出流读取结果能最大程度避免 Windows 的换行污染。这是我在 Windows 上抓截图踩过坑之后总结出来的习惯虽然偶尔和旧版 adb 有兼容问题但在新版本 platform-tools 上实测很稳。录屏用 screenrecordadb shell screenrecord --time-limit 10 /sdcard/demo.mp4 adb pull /sdcard/demo.mp4 D:\test\3.3 尺寸与设置调整不 root 也能改的系统参数不少和 UI 相关的调试需要临时修改分辨率或密度。比如让某款应用适配更大屏幕可以执行adb shell wm size 1080x1920 adb shell wm density 420这是临时修改重启设备后恢复默认。如果想恢复原始状态执行 adb shell wm size reset 和 adb shell wm density reset。实测中修改密度可能让桌面布局错乱但 test 场景下反而能快速验证不同适配方案改完随时 reset。修改系统设置也有一条很好用adb shell settings put global stay_on_while_plugged_in 3这个设置让设备在插电充电时保持常亮方便长时间跑测试脚本。3 的值是把 1USB 充电常亮和 2交流充电常亮加起来的效果。类似的还有 adb shell settings put system screen_off_timeout 60000 调整息屏时间跑 UI 自动化时非常实用。4. 无线调试与多设备场景摆脱数据线的三种方式4.1 从 USB 切换到无线调试的完整步骤不是所有场景都方便拖着一根数据线。设备放在工位上跑测试或者调试电视、盒子这类不便连接电脑的设备时无线调试就派上用场了。最传统的方法是先用 USB 连接一次然后执行adb tcpip 5555这条命令让设备上的 adbd 开始监听 TCP 5555 端口。接着给设备配好 WiFi并确保电脑和设备处于同一局域网获取到设备 IP。IP 可以通过 adb shell ip addr show wlan0 查看或者去设备设置里的“关于本机”看状态信息。拿到 IP 后拔掉数据线执行adb connect 192.168.1.100:5555如果状态变成 device说明无线连接成功。之后所有 ADB 操作和有线连接完全一样。想切回 USB 模式就执行 adb usb让设备重新回到 USB 调试状态。整个过程本质是告诉设备端的 adbd 开启网络监听然后电脑端以 TCP 方式建立会话Windows 防火墙第一次连接时可能会弹窗记得允许 adb.exe 访问网络否则 connect 会一直超时。4.2 Android 11 以后的无线调试配对码方案Android 11 把无线调试的逻辑改得更方便了开发者选项里直接多了一个“无线调试”入口不需要先插 USB。我习惯的流程是打开“无线调试”点“使用配对码配对设备”屏幕会显示一个 IP 地址加冒号端口还有一个六位配对码。电脑端执行adb pair 192.168.1.100:39821回车后提示输入配对码把设备上的六位数字输进去显示配对成功这台设备就登记了电脑的 adb 密钥。之后无线调试主界面会显示这台设备的连接信息比如 192.168.1.100:43211此时执行adb connect 192.168.1.100:43211到这里有个很容易搞混的坑配对时界面显示的端口号和 connect 时用的端口号通常是两个不同的端口。配对端口只用于一次性交换配对码connect 端口才是 adbd 真正监听的连接端口。我之前对着“配对端口”去 adb connect一直报 unable to connect折腾了一会才发现是端口看错了。无线调试相比传统 tcpip 方式最大优势是不依赖数据线只要第一次配好以后设备开机并在同一网络下就可以直接 adb connect。对经常要在机柜、电视、盒子上调试的同学来说这一条能极大提升效率。4.3 多设备管理如何避免操作错设备同时连着多个设备时adb devices 会列出所有条目包括 USB 和无线连接的设备。如果不指定目标设备ADB 会报错“adb: more than one device/emulator”并拒绝执行。指定设备用 -s 参数加设备序列号adb -s 0123456789ABCDEF shell input keyevent 26 adb -s 192.168.1.100:43211 shell screencap -p /sdcard/s.png设备序列号从 adb devices -l 的输出里可以看到无线连接设备的序列号就是 IP:端口 的格式。如果经常在一个终端窗口里操作某一台设备可以设置环境变量 ANDROID_SERIAL 指定默认设备但我的建议是脚本里显式写 -s避免环境变量在多个终端窗口之间干扰。模拟器场景也归到这一类。许多安卓模拟器会把自己注册为一个 ADB 设备你可以用 adb connect 127.0.0.1:端口 直接连接不同模拟器的端口各不相同常见的像雷电、夜神、MuMu 都有各自的默认端口。连接后可以用 adb -s emulator-5554 这种方式精确定位。这里提示一句如果本机的 platform-tools 版本和模拟器自带的 adb 版本差异过大可能出现连接成功后立刻显示 offline优先换用同一个版本的 adb 来连接。5. 高频报错的症状与排查思路Windows 下 ADB 疑难杂症实录5.1 adb: createfilew nul failed: 系统找不到指定的文件这条在 Windows 用户里被问得特别多先看现象在 cmd 或 PowerShell 里执行某些带重定向的 adb shell 命令时报错 adb: createfilew nul failed: 系统找不到指定的文件。它的英文原意是 ADB 尝试调用 Windows 的 CreateFile 打开名为 nul 的文件失败了。Windows 系统把 NUL 当成了特殊的空设备名类似 Linux 的 /dev/null所以这个报错往往和 shell 命令里的重定向处理有关。我自己的排查思路分成三步。第一步确认是偶发还是稳定复现先执行 adb devices如果正常说明 ADB 基本链路是通的。第二步把具体命令里的重定向去掉改用 adb exec-out 替代看能不能正常输出。比如抓截图adb exec-out screencap -p screen.png 通常能绕过这个报错。第三步换到 cmd 原生窗口执行一次同样的命令如果正常那基本锁定是终端环境差异导致。目前社区里的主流解法有两个方向一是别让 Windows 解析到设备侧的重定向符号把命令整体用双引号包住例如 adb shell top -n 1 /sdcard/top.txt让设备端自己处理重定向二是在 PowerShell 里用 --% 符号停止 PowerShell 的解析比如 adb --% shell top -n 1 /sdcard/top.txt。实测下来大多数情况下是终端环境或者路径里藏着奇怪字符引出的问题把命令简化、改用 exec-out、统一在 cmd 下执行基本都能绕过去。5.2 adb unauthorized 怎么解决unauthorized 表示电脑端和设备的授权关系没建立成功。第一次连接时设备端弹窗允许即可解决如果弹窗没出来大多是因为之前误点了拒绝或者设备的授权记录和电脑端密钥不匹配。排查顺序重新插拔 USB看设备端有没有弹出授权窗口如果没弹窗去开发者选项里选“撤销 USB 调试授权”然后重插还不行就删除电脑端 %USERPROFILE%.android\ 下的 adbkey 和 adbkey.pub再执行 adb kill-server重新插线删除密钥后手机再次弹出授权窗口时勾选“始终允许”。原理上ADB 通信靠的是 RSA 非对称加密电脑端私钥保存在 .android\adbkey设备端保存了对应的公钥指纹。如果密钥文件损坏、被清理工具误删或设备端保存的指纹不一致就会一直 unauthorized。删除电脑端旧密钥让它重新生成等于让设备和电脑重新建立一次信任关系。需要注意删除密钥后其他所有设备都要重新点一遍授权所以这个操作要在确认必要后再做。5.3 设备不识别先别急着刷驱动按这个链路走设备在 adb devices 里完全不出现大多数人第一反应是重装驱动但很多时候源头是数据线或 USB 模式。按下面这个顺序排查效率最高首先确认手机端“USB 调试”开关是打开的并且 USB 连接模式选的是“文件传输”而不是“仅充电”。很多旧款设备的 adbd 在仅充电模式下不会启动这一步占了不识别问题的一小半。然后把数据线换成一根明确支持数据传输的线很多第三方线只能充电导致设备只进入充电状态根本不会和电脑通信。再看设备管理器确认有没有带感叹号的 ADB Interface 或未知设备有就更新驱动没有的话说明 USB 协商都没成功可以换一个 USB 口特别是台式机建议直接用后置接口排除供电不足的影响。还有一类很容易被忽略设备本身没开启“网络调试”但你想用它做无线调试。很多电视盒子、智能手表、智能硬件需要在设备端进入开发者菜单打开 adb 开关然后开放一个端口。它们各自的入口和标识不同但只要设备端 adbd 正常监听Windows 这端用 adb connect IP:端口 就能连通。所谓“专属校验码”、“专用工具”本质上都是在帮你完成设备和电脑之间的密钥信任与端口连通思路大同小异。排查到最后如果还是不行执行一次 adb kill-server然后 adb start-server 再试。这个操作能重置 ADB 服务端和设备端之间的一些临时状态代价很小却经常能解决莫名其妙的问题。ADB 这类工具就是这样单个命令的语法不难真正决定效率的是遇到异常时能快速定位到底哪一层出了问题——端口、驱动、授权、还是数据线。把这条链路理清Windows 下折腾安卓设备的基本功就算扎实了。