Windows下ADB命令完全指南：从环境配置到自动化调试

1. 为什么要在Windows下专门整理一套ADB命令1.1 排查、调试、自动化ADB到底在解决什么问题干Android开发和测试这行Windows系统几乎是绕不开的日常环境。我身边有不少同事从Mac切到Windows之后第一件事就是问ADB命令在Windows下怎么用为什么我敲同样的命令总是报错这篇文章不是官方文档的搬运而是把我在Windows下这些年高频使用的ADB命令完整梳理了一遍从环境配置到应用管理、日志抓取、自动化控制再到Windows特有的坑一次讲清楚。适合刚入门的新人也适合想把自己日常操作规范化的老手。先把概念说透。ADB全称Android Debug Bridge翻译过来就是“安卓调试桥”它本质上是电脑和Android设备之间的一条双向通信通道。手机上跑的守护进程adbd、电脑端敲的adb客户端、中间负责转发的adb server三者配合才能让你在电脑上直接操作手机。很多人只用过安装APK和看日志其实ADB能做的事情远不止这些截屏、录屏、模拟点击、修改系统设置、批量安装卸载、抓取崩溃日志、甚至跑自动化测试脚本都能通过命令行完成。Windows用户和Linux/macOS用户面对的是同一套ADB但在实际使用中会遇到不少平台特有差异。比如路径分隔符不同cmd的转义规则不同命令输出中文可能乱码USB驱动需要额外安装偶尔还会碰到设备端口被占用、文件管理器锁定APK文件这种Windows专属问题。这些坑单独看都不大但每一条都能卡住你半小时。所以我一直建议Windows下的ADB操作要单独有一套打法不要照搬Linux教程。1.2 Windows和Linux/macOS的差异真的不只是命令提示符刚开始用Windows做Android调试的人最容易踩的坑是拿Linux的思维来敲命令。Shell不一样了很多管道命令没法直接用。比如在Linux上过滤adb logcat输出你习惯写adb logcat | grep ErrorWindows自带的cmd不支持grep要用findstr替代adb logcat | findstr Error。在PowerShell里虽然可以用Select-String但老同事的批处理脚本基本都是基于cmd的交接过来还得兼容。再说路径问题。Windows的路径分隔符是反斜杠\这在ADB命令里很容易引起混乱。比如你要把电脑上的D:\test\app.apk推到设备里直接写adb push D:\test\app.apk /sdcard/看起来没问题但如果目录名或者文件名里带了空格又需要加引号引号加不好就经常报错路径里如果有特殊字符cmd还会强行尝试转义。更麻烦的是ADB本身在Windows下解析反斜杠时可能出现歧义有时候\sdcard\也能用有时候又必须写成/sdcard/我自己的习惯是设备端路径一律用正斜杠电脑端路径尽量用引号包住这样踩坑最少。再有就是驱动问题。Linux和macOS对Android设备的USB访问通常开箱即用Windows上经常出现“设备管理器里能看到手机但adb死活不识别”的情况。这种情况多半是驱动没有正确安装或者驱动版本太老。Google官方提供了统一的USB驱动包也可以在设备管理器里手动更新驱动很多国产手机品牌还有自己的助手工具装完后会自动把ADB驱动一起装上。如果你需要在多台电脑之间切换建议把platform-tools目录固定在一个稳定路径并把该路径加入环境变量PATH后面所有操作都会顺畅很多。1.3 环境搭建从下载到adb version一次跑通ADB工具的安装非常简单本质就是下载Google官方的platform-tools压缩包解压后把目录加进环境变量。不需要安装什么重量级IDE也不需要额外配置Java环境Windows下这一步做完就足够了。具体步骤是先从Android开发者官网下载Windows版本的platform-tools下载完是一个zip包解压到你习惯的目录比如D:\platform-tools。然后右键“此电脑”-“属性”-“高级系统设置”-“环境变量”在“系统变量”里找到Path编辑新增一行D:\platform-tools。保存后打开一个新的cmd窗口输入adb version能看到版本号输出就说明环境OK了。提示如果你是在公司电脑上操作可能没有修改系统环境变量的权限。这种情况可以不用改全局变量直接在cmd里先执行cd /d D:\platform-tools切到工具目录再运行ADB命令效果完全一样。或者写一个bat脚本每次自动切目录再执行命令。下载的时候我建议认准官方渠道不要随便在网上找“ADB一键安装包”因为你不知道里面捆绑了什么。官方platform-tools的体积不大每次更新也方便直接替换整个目录就行。版本方面老版本ADB在新手机上经常出现连不上、命令不支持的问题尽量保持最新版本。2. 设备连接与状态查看所有后续操作的前置条件2.1 adb devices的输出怎么看三种状态和对应处理环境配好之后第一件事就是确认设备有没有被识别。把手机用USB线连到电脑手机上如果弹出“允许USB调试吗”的窗口勾选“始终允许”点确定。然后在cmd里输入adb devices正常情况会输出类似这样的内容List of devices attached emulator-5554 device R58M12345ABC device第一列是设备序列号第二列是状态。这里有个很多人忽略的点状态不只是device一种。常见状态有device、unauthorized、offline它们的含义和应对方式完全不同。状态含义处理方法device已授权可正常执行命令直接操作unauthorized手机端没点允许或之前误点了拒绝拔掉USB重插在手机上重新弹出授权框并允许offline设备已连接但通信异常重启adb server或换USB接口/数据线no permissionsLinux常见Windows少见检查驱动或重新插拔我见过太多同事卡在unauthorized状态半天以为是驱动问题来回重装驱动实际就是手机屏幕上那个授权弹窗没注意到。现在的国产手机系统对授权弹窗提醒得比较轻有时候弹窗藏在通知栏里。所以遇到unauthorized第一反应应该是拿起手机看一眼而不是在电脑上折腾。如果设备列出来了但状态一直offline可以试着重启adb服务adb kill-server adb start-server adb devices很多时候offline是因为adb server在电脑休眠、手机锁屏或者USB控制器切换之后连接状态“假死”了。杀掉重启再重新枚举一次大多能恢复。2.2 USB、Wi-Fi还是模拟器三种连接方式的取舍USB连接是最常用的稳定性也最好。但如果你要在手机上长时间跑自动化脚本或者手机放在另一个房间USB线拖着不方便可以考虑Wi-Fi无线连接。需要注意的是Android 11及以上版本原生支持无线调试可以直接用手机上的“无线调试”功能配对不需要root。Android 10及以下的老办法是先用USB连一次执行一下命令把端口号设置好adb tcpip 5555 adb connect 192.168.1.100:5555手机IP可以通过adb shell ip addr show wlan0查也可以在手机“设置-关于手机-状态信息”里看。连接成功后拔掉USB线后续命令一样能执行。要注意的是无线连接的性能受Wi-Fi环境影响如果网络不稳定可能会频繁掉线对稳定性要求高的操作还是建议USB。模拟器是测试中另一大场景。Genymotion、Android Studio自带的模拟器、以及很多第三方安卓模拟器都默认开了ADB调试端口。你不需要把模拟器“插”到电脑上直接用adb connect 127.0.0.1:端口号就能连上。比较常见的端口有emulator-5554这种写法本质上就是模拟器自报的设备名。第三方模拟器各家的端口不一样有的在设置界面里写明了有的需要自己查使用前先确认端口别连错设备。注意如果你同时连着USB真机、Wi-Fi设备和多个模拟器adb devices会列出一大串。这时候再执行adb install或adb shellADB会提示“more than one device/emulator”要求你用-s指定设备。我在5.3小节会专门讲多设备管理。2.3 设备信息查询getprop体系的使用设备连接正常后很多人想要查看手机的型号、系统版本、屏幕分辨率等信息。这些信息不需要装任何AppADB自带一条命令就能全部查出来adb shell getprop这条命令会输出一大堆系统属性英文缩写看着比较费劲。实际工作中常用的是过滤出特定字段。Windows下配合findstr使用adb shell getprop | findstr ro.product.model adb shell getprop | findstr ro.build.version.release adb shell getprop | findstr ro.product.manufacturer执行完之后分别能看到设备型号、Android版本、厂商名称。如果一次想查多个字段可以在一条命令里用findstr指定多个关键字比如findstr product model。这个命令在写自动化脚本、判断设备类型时非常有用。除了getprop还有几个设备信息命令我用的也很频繁adb shell wm size # 查看屏幕分辨率比如 1080x2400 adb shell wm density # 查看屏幕密度比如 440dpi adb shell getprop ro.serialno # 查看设备序列号 adb shell uptime # 查看设备已开机时长分辨率和密度这两个参数在做UI适配测试、设置模拟点击坐标时特别重要。同样一张截图在不同分辨率的设备上某个按钮的坐标可能完全不同。所以我在写自动化脚本之前第一步永远是先查这两个值再计算相对坐标。3. 应用安装、卸载与数据管理日常调试的“高频区”3.1 adb install参数与Windows路径坑应用安装是ADB使用频率最高的操作没有之一。最简单的安装命令adb install D:\test\app-debug.apk但实际开发中APK文件通常在一堆子目录里路径很长Windows的路径长度限制偶尔会跳出来咬人。如果ADB报“系统找不到指定的文件”先检查路径是不是写错了再检查路径里有没有空格或者中文。我有一次把APK放在D:\我的项目\debug包\v1.0\app-release.apk这种目录下cmd里怎么敲都报错最后把APK复制到D:\根目录一条命令就装上了。Windows对中文路径和特殊字符的支持在命令行环境下一直比较脆弱建议调试时干脆用英文路径。adb install常用参数如下参数作用使用场景-r允许覆盖安装升级版本时必备否则会报INSTALL_FAILED_ALREADY_EXISTS-d允许降级安装高版本换回低版本时使用-t允许安装测试包安装debug或testOnly应用时使用-s安装到SD卡内部存储不足时使用现在用得少了--abi arm64-v8a指定架构多架构APK需要按设备选择时使用我平时最常用的是-r -t组合adb install -r -t app-debug.apk。这是因为Android Studio构建的debug包默认带testOnly标志不加-t参数安装时直接报INSTALL_FAILED_TEST_ONLY: installPackageLI非常坑。另外如果遇到报错INSTALL_FAILED_VERSION_DOWNGRADE就是设备上已经装了更高版本需要加-d参数降级安装。安装完成后如果想确认应用确实装上了可以用adb shell pm list packages | findstr 包名来查。包名和应用名称不是一回事包名是唯一的应用名称只是显示名称。比如微信的包名是com.tencent.mm抖音是com.ss.android.ugc.aweme这些记不住很正常可以安装后用命令查。3.2 包名定位从应用商店到当前前台有些时候你需要知道某个已经安装的应用的包名是什么。最笨的办法是去应用商店页面看这个有太多例外比较靠谱的办法是用ADB命令直接查。查看设备上所有已安装的应用adb shell pm list packages输出会很长一般配合过滤使用。比如你想确认微信是否已安装adb shell pm list packages | findstr tencent如果你想查当前正在前台运行的是哪个应用可以这样adb shell dumpsys window | findstr mCurrentFocus输出类似mCurrentFocusWindow{... com.tencent.mm/.ui.LauncherUI}包名和Activity名都清清楚楚。查当前前台应用这个操作在测试深链跳转、Activity生命周期时特别有用你可以点开某个应用后立刻执行这条命令确认它到底跳到了哪个页面。还有一种情况是你要打开某个应用的指定页面但你知道包名不知道Activity名。可以用adb shell monkey -p 包名 -c android.intent.category.LAUNCHER 1启动应用再看当前焦点拿到了Activity名然后后续复用。3.3 清除数据、备份与恢复的正确姿势开发和测试过程中经常会需要清掉应用的数据来还原状态比如测试“首次启动引导页”、“登录态过期”等场景。这时候用pm clearadb shell pm clear com.tencent.mm这条命令会把应用的所有数据清空效果相当于在系统设置里点“清除数据”。操作之后应用会恢复到刚安装的状态。这里要特别提醒pm clear会把应用沙盒内所有文件一起干掉如果要保留某些配置文件千万先备份。备份单个应用的APK文件是另一个常用操作。我自己遇到过一个场景手机上下了一款旧版应用应用商店已经下架了新版厂商官网也没有历史版本下载最后是借助ADB从另外一台手机上把APK拉出来adb shell pm path com.example.app这条命令会输出APK在设备上的实际路径一般长这样package:/data/app/~~~xxxx/com.example.app-xxxxx/base.apk。拿到路径后用adb pull把APK文件拉到电脑上adb pull /data/app/~~~xxxx/com.example.app-xxxxx/base.apk D:\backup\app.apk需要注意pm path输出的是package:开头的完整字符串直接用时要先把package:前缀去掉再传给pull。如果设备没root/data/app目录本身不可浏览但ADB授权后pm path和pull还是可以正常工作的这也是备份APK比较方便的方式。4. 文件传输与logcat日志抓取排查问题的两个抓手4.1 push/pull的路径写法和常见错误ADB的文件传输功能本质上就是两条命令adb push电脑推送到设备和adb pull设备拉取到电脑。看命令定义很简单但Windows下用起来也是有小九九的。推送文件的命令格式adb push D:\test\test.txt /sdcard/Download/拉取文件的命令格式adb pull /sdcard/Download/test.txt D:\test\这里有几个容易踩的坑。第一设备端路径建议统一用正斜杠/比如/sdcard/Download/不要写\sdcard\Download\。Windows下的ADB版本对反斜杠解析有可能出问题。第二电脑端路径如果带空格需要加引号adb push D:\my data\test.txt /sdcard/第三push到设备时如果目标是一个不存在的目录命令会失败。比如/sdcard/12345/这个目录根本不存在直接push会报错。可以先执行adb shell mkdir -p /sdcard/12345创建目录再推送。这个坑在自动化脚本里最常见因为脚本跑在全新设备上时很多目录都没有需要先建目录。拉取文件的另一个常见问题是adb pull拉取一个目录时如果电脑端目标目录已经存在同名文件ADB默认会覆盖还是报错不同版本行为略有差异为了稳妥我一般先看一下设备端文件是否存在、大小是多少adb shell ls -l /sdcard/Download/test.txt确认无误后再执行pull避免拉了个空文件或者不完整文件。4.2 logcat的过滤与输出Windows下请用findstr抓日志是ADB的另一大高频用途。adb logcat的输出量极大满屏滚动根本看不完。实际工作中必须学会过滤。最基础的一条清空旧日志再复现问题adb logcat -c-c是clear的意思清空缓冲区之后再让同事或测试人员去复现Bug新的日志干净地输出不会被历史日志淹没。过滤关键字时Linux/Mac下用grepWindows下用findstradb logcat | findstr AndroidRuntime adb logcat | findstr FATAL EXCEPTION adb logcat | findstr 你的应用包名如果你只看崩溃相关的日志可以直接过滤AndroidRuntime因为Java层crash都会打这个标签。还有一个很有用的参数是按优先级过滤比如只显示Error级别及以上的日志adb logcat *:E参数规则是标签:优先级优先级从低到高分别是V、D、I、W、E、F、S。如果想要“只要某个标签的错误和警告”写成TAG:W即可。在Windows的cmd下通配符*在有些场景会被扩展如果你敲adb logcat *:E没反应可能是因为cmd把*处理掉了建议用adb logcat *:E加个引号规避。抓崩溃日志时很多人会直接adb logcat crash.txt把输出重定向到文件。这个操作在Windows下正常但要注意cmd里重定向生成的文本默认是ANSI编码Android日志又是UTF-8用记事本打开可能乱码。我习惯用VS Code直接打开或者先执行chcp 65001把cmd切到UTF-8编码再重定向。4.3 截图、录屏与Windows乱码问题的绕行方案截图和录屏是Bug反馈时的黄金搭档。ADB原生支持这两项能力不需要在手机上装任何App。截图命令adb exec-out screencap -p D:\screen.png录屏命令adb exec-out screenrecord --time-limit 10 /sdcard/demo.mp4录屏的本质是先在设备上生成MP4文件再用pull拉到电脑。默认录制时长不超过180秒超时需要加--time-limit参数。这里有一个Windows专用的经典坑就是我在标题里提到的adb: createfilew nul failed: 系统找不到指定的文件。这个报错经常出现在cmd窗口下执行类似adb exec-out screencap -p nul或把screencap输出重定向给其他程序时旧版ADB在Windows下对nul设备文件的处理有兼容性问题。解决办法很简单不要用nul作为重定向目标改成一个普通临时文件把输出重定向到D:\screen_temp.png再用其他工具处理这个文件或者避开cmd在PowerShell里用$null处理空输出。我自己的习惯是截图命令里永远指明完整的目标文件路径不偷懒写nul。这样既绕开了报错也不会误删文件。提示在Windows的cmd中nul是一个特殊设备名类似于Linux的/dev/null但在某些ADB操作中ADB会把参数里的nul当作需要打开的文件路径又和cmd的重定向逻辑混淆就会报createfilew nul failed。遇到这个报错不要慌改掉重定向方式基本就能解决。5. adb shell与自动化把Windows变成你的遥控器5.1 Shell基础命令与查看系统资源adb shell等于把设备上的Linux shell搬到了你的Windows命令行里。进入shell交互模式adb shell进去之后你可以执行很多Linux命令比如ls、cd、cat、ps、top、df。如果你不想进入交互模式也可以直接在Windows命令行中加一条命令执行比如adb shell ls /sdcard/ adb shell df -h adb shell cat /proc/meminfo adb shell top -n 1top -n 1可以查看设备实时的CPU和内存占用df -h可以查看内部存储空间使用情况。如果你在测试应用性能这两条命令是最快的初步判断方式。注意Android设备的shell是精简版很多桌面Linux命令不一定存在比如没有vim、没有grep但常用的文件操作和进程管理命令基本都在。操作设备上的配置文件时sed在部分Android系统上不可用所以我一般先cat查看再用echo 文件的方式写入。批量修改系统设置更推荐用settings命令adb shell settings put global stay_on_while_plugged_in 3 adb shell settings get global stay_on_while_plugged_in第一个命令让设备插着电源时不熄屏对长时间跑测试非常友好第二个命令查看当前值。这些命令写进脚本里比手动在设置里点来点去高效得多。5.2 input事件模拟自动点按、滑动和输入如果自动化测试框架还没接入或者你只是想临时模拟一次操作adb shell input命令是最快的方式。它支持模拟点击、滑动、按键、输入文字。模拟点击adb shell input tap 500 1000模拟滑动adb shell input swipe 500 1500 500 300 500最后那个500是滑动耗时单位毫秒。模拟返回键adb shell input keyevent 4模拟Home键adb shell input keyevent 3输入文字adb shell input text hello这里有几个坑必须说明。第一坐标是绝对坐标不同分辨率屏幕的同一按钮位置不一样所以要结合wm size查到的分辨率来计算。第二input text无法输入中文这是Android input命令本身的能力限制遇到中文输入要么用剪贴板方案要么借助支持UTF-8的自动化框架。第三input swipe的滑动起点和终点需要落在屏幕范围内否则命令不报错但也没有效果很迷惑。我平时排查问题时最常用的组合是截图确认当前页面 -input tap点击目标按钮 - 再截图确认跳转结果。这几条命令配合起来可以非常快速地走通一个页面流程。5.3 多设备管理-s参数加脚本化测试工程师的工位上经常摆着好几台手机模拟器也可能同时开好几个。这时候直接执行adb install会报“more than one device/emulator”需要给每一条命令加上-s参数指定设备adb -s R58M12345ABC install app-debug.apk adb -s emulator-5554 shell input tap 500 1000设备序列号从哪里拿adb devices输出的第一列就是。你可以把它们看成是每台设备的身份证号。在脚本里我更推荐先定义好设备和别名再循环处理echo off set DEVICE1R58M12345ABC set DEVICE2emulator-5554 adb -s %DEVICE1% install app-debug.apk adb -s %DEVICE2% install app-debug.apk如果你要同时向10台设备推送同一个APK手动一条条执行太慢可以写一个批量脚本循环读取设备列表逐个安装。这个思路也适用于批量执行pm clear、批量截图、批量抓日志。多设备并行的核心就是先adb devices确认所有设备状态正常再写循环逐条操作并在关键节点输出当前设备名否则日志混在一起根本没法看。6. 高频报错与实用技巧速查表6.1 十个小问题的排查方法Windows下用ADB这些年我遇到过不少报错有些是环境问题有些是命令用错了很大一部分是Windows平台的行为差异导致的。下面这个表格是我根据实际项目经验整理的高频问题速查基本覆盖了日常90%的报错场景。报错内容原因解决办法adb server version doesnt match this client电脑上存在多个ADB版本server和客户端版本不一致执行adb kill-server后确认PATH中只有一份platform-tools或者直接用当前工具的完整路径启动device unauthorized手机端没有授权拔线重插在手机上点“允许USB调试”并勾选始终允许device offlineADB连接假死或USB不稳定重启adb server、换数据线或USB口adb: createfilew nul failedcmd下把nul当成重定向目标改用 temp.txt或使用PowerShell$nullINSTALL_FAILED_TEST_ONLYdebug包带testOnly标志安装时加-t参数INSTALL_FAILED_VERSION_DOWNGRADE安装版本比设备上已有版本低加-d参数或先pm uninstall再装system/bin/sh: grep: not found设备shell里没有grep在Windows侧用findstr过滤或者用busybox grep设备已root时more than one device/emulator连接了多个设备但没指定加-s 序列号指定设备error: device not found设备没有正常连接先adb devices确认设备是否枚举成功再检查驱动端口被占用5037 adb端口其他程序占用了ADB端口用netstat -ano这里补充一下adb server version doesnt match this client这个报错的细节。它出现得非常频繁尤其是电脑上装了多个Android工具链的时候。Android Studio自带一份ADB某些手机助手又捆绑一份ADB命令行里打开的是另一个目录的ADB三份版本各不一样server起不来。解决办法是先杀掉所有adb进程再统一用同一个目录下的ADB启动adb kill-server taskkill /f /im adb.exe adb start-server如果确实需要在多个ADB版本之间切换可以写一个环境变量切换脚本但更推荐的做法是固定使用官方platform-tools其他工具如果依赖自带的ADB也尽量把路径统一覆盖。6.2 我一直在用的几个ADB小技巧最后分享几个我每天都会用的ADB技巧都是在Windows下实践出来的“私货”文档里通常不会写这么细。第一个是录制logcat到文件并自动带时间戳。直接在cmd里执行adb logcat -v time D:\logcat_%date:~0,4%%date:~5,2%%date:~8,2%.txt这样文件名会自动带上日期比如logcat_20250115.txt。日积月累不会覆盖混乱。如果你要长期跟踪某个应用的日志可以再加一层findstr过滤包名只保留这个应用的消息。第二个是快速截图并自动打开。一条命令搞定adb exec-out screencap -p %USERPROFILE%\Desktop\screen.png explorer %USERPROFILE%\Desktop\screen.png执行完截完图Windows会自动打开图片预览。这个操作比手机上截完图再传到电脑快得多尤其在远程给同事演示问题的时候特别方便。第三个是查看Android设备上最耗电的应用排行。虽然手机设置里也能看但用命令行查看更深层的数据更直接adb shell dumpsys batterystats | findstr Uid不过batterystats的数据量很大建议先执行adb shell dumpsys batterystats --reset清空历史数据再正常使用一会儿手机最后重新抓取分析。第四个也是我个人最推荐的小习惯把常用ADB命令封装成bat脚本。比如install.bat专门用来安装指定APKlogs.bat专门负责抓日志pull_data.bat专门拉取指定目录文件。这样团队内新同学上手也快不需要记一堆命令参数双击就能跑。封装时记得在脚本开头加上cd /d %~dp0和adb devices确保脚本在任何目录下执行都不会因为路径问题翻车。我自己在实际操作中还有一个体会ADB命令本身不复杂真正决定效率的是你是否愿意把重复操作沉淀成脚本。每次手动输入一条命令只省了几秒钟长期积累下来差别非常大。希望这份Windows下的ADB命令梳理能帮你少踩一些我当年踩过的坑把更多精力放在业务本身。