ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Android ADB调试全链路:连接、安装、抓日志与无线调试实战指南

2026/9/15 4:59:03 拓冰建站 浏览量
Android ADB调试全链路:连接、安装、抓日志与无线调试实战指南 拿到一台新手机或者正在调试一台旧设备第一件事永远是先把ADB这条桥搭起来。很多朋友在群里问android调试常用命令有哪些adb logcat怎么抓日志adb unauthorized怎么解决其实大部分问题不是命令本身多难而是环境和基础概念没捋清楚。这篇文章不搞那种命令大全式的罗列而是从实际调试的完整链路出发把连接、安装、日志、进程操作、无线调试、典型踩坑一次讲透。无论你是刚入门的测试、转行做Android开发的新人还是偶尔需要折腾设备的硬件工程师看完应该都能直接上手。1. 环境搭建与设备连接把这条桥先搭稳1.1 ADB工具从哪来认准官方platform-toolsADB全称Android Debug Bridge字面意思就是Android调试桥。它分为三个角色电脑上的客户端、设备上常驻的守护进程adbd、以及连接两者的服务端。平时我们敲的adb命令本质是把指令发给电脑上运行的adb服务再由它通过USB或网络转发给手机里的adbd。工具下载这块我只推荐一个来源Android官方的SDK Platform Tools。直接搜Android SDK Platform Tools就能找到官方下载页面里面有Windows、macOS、Linux三个平台的压缩包。别去那些第三方网站下所谓的adb工具包很多是老版本改的要么缺驱动要么被塞了乱七八糟的东西。下载完是个压缩包解压到任意目录不需要安装。这时在命令行里切到解压目录输入adb version能看到版本号就说明工具本身没问题。1.2 环境变量配置Windows和macOS各三分钟搞定每次切到解压目录敲命令太麻烦建议把目录加进环境变量。Windows上的做法是右键此电脑→属性→高级系统设置→环境变量在Path里新建一条填你解压platform-tools的路径。比如我放在D:\platform-tools就填这个。弄完记得把当前命令行窗口全关了重新打开再敲adb version验证。macOS和Linux类似在~/.zshrc新系统默认zsh或~/.bashrc里加一行export PATH$PATH:/Users/你的用户名/platform-tools然后source ~/.zshrc生效。这里有个容易踩的坑如果之前装过其他版本的ADB环境变量里可能有多个路径命令行里敲which adbWindows用where adb确认一下用的是不是新解压的那个。1.3 adb devices三种状态authorized、unauthorized、offline分别怎么办连接设备之前手机上要开启开发者选项和USB调试。大部分手机是在设置→关于手机里连续点击版本号七次然后回到设置就能看到开发者选项了。准备工作做完插上USB线命令行输入adb devices输出结果里设备名后面会跟一个状态常见三种device正常授权状态可以执行后续命令unauthorized手机上弹了授权框但没点允许或者点了一律允许之前出现过但后来授权被撤销了offline设备连上了但通信异常可能是驱动问题、USB线质量差、或adb服务挂了unauthorized的处理很简单手机端确认弹窗勾选一律允许使用这台计算机进行调试重新插拔USB。如果授权记录被误删了可以在开发者选项里点撤销USB调试授权再重新连一次弹窗就会再出现。offline的情况我后面在踩坑章节会详细展开这里先给最常见的三板斧换一个USB口、换一根数据线很多线只能充电不能传数据、命令行执行adb kill-server adb start-server重启adb服务。1.4 一台死活连不上的设备的排查全流程有一次我帮同事调一台杂牌平板插上之后adb devices一直空白。我先看了设备管理器发现Android Composite ADB Interface上面有个黄色感叹号——驱动压根没装对。完整的排查链路应该是这样的手机端USB调试确认打开并且插线后通知栏有正在通过USB传输文件之类的提示电脑设备管理器里看有没有带感叹号的设备。有的话先卸载设备再拔插USB线让系统重新识别。还不行就下载对应手机厂商的USB驱动手动安装确认驱动正常后adb kill-server重启服务再adb devices换USB口、换线排除硬件问题换一台电脑试如果另一台电脑能认出就是驱动或系统环境的差异这套流程走下来90%的连不上都能解决。剩下10%是极老设备或者深度定制的系统那种只能靠设备厂商的工具处理。2. 安装、卸载与包管理应用调试的基础功2.1 adb install的参数你真的用对了吗安装APK是最高频的操作。基础命令很简单adb install 你的应用.apk但实际调试场景里更常用的是带参数的组合参数含义典型场景-r覆盖安装保留数据安装新版本时不想丢本地数据-d允许降级安装从测试版回到正式版-t允许安装测试包安装标记为testOnly的包-g安装后直接授予所有运行时权限免去一个个点权限弹窗-s安装到SD卡内部存储不足时比如给一台测试机装调试包我习惯一条命令adb install -r -d -t -g 你的应用.apk-r保证升级不丢数据-d防止版本号倒挂报错-t允许TestOnly包-g省去点权限的时间。四个参数加在一起基本能覆盖绝大多数内部调试场景。安装失败的报错也值得认识一下。最常见的两个INSTALL_FAILED_UPDATE_INCOMPATIBLE签名不一致。旧包和新包不是同一个签名直接覆盖会失败。解决方法是先卸载旧包再安装但要接受数据丢失INSTALL_FAILED_VERSION_DOWNGRADE版本号变低了。加上-d参数即可还有INSTALL_FAILED_INSUFFICIENT_STORAGE存储不足清理一下设备空间就行。2.2 卸载应用和清理数据卸载一条命令adb uninstall 包名注意这里需要的是包名不是应用名称。比如微信的包名是com.tencent.mm不是微信两个字。想知道某个应用的包名可以这样adb shell pm list packages这会列出设备上所有已安装应用的包名。列表太长时加个-s只看系统应用-3只看第三方应用或者用grep过滤关键词adb shell pm list packages | grep tencent如果要模拟清除应用数据的效果也就是恢复出厂状态用adb shell pm clear 包名这个命令在做兼容性测试时非常有用每次跑用例前清一下数据保证测试环境的干净。2.3 pm命令包名查询与权限授予pm是Package Manager的缩写adb shell pm后面能接一堆子命令。除了上面列包的用法我再分享几个高频的# 查看某个包的安装路径 adb shell pm path 包名 # 查看已授予的权限 adb shell pm list permissions -g | grep 包名 # 动态授予运行时权限不弹窗不打扰用户 adb shell pm grant 包名 android.permission.CAMERA # 撤销权限 adb shell pm revoke 包名 android.permission.CAMERApm grant在自动化测试或兼容性验证里特别有用。比如你要验证相机权限被拒绝时App的表现但产品弹窗要手动点好几次用pm revoke一步到位测完再grant回来。还有adb shell am start启动Activity也算包管理操作的一部分adb shell am start -n 包名/包名.MainActivity这个命令最烦的一点是要写全限定类名而且写法有可能是包名/.MainActivity这种简写形式。不过调试阶段我更推荐用下面这种启动方式直接指定主Activityadb shell monkey -p 包名 -c android.intent.category.LAUNCHER 1monkey的第一条事件就是拉起应用主界面。这条命令不用记类名谁用谁知道。3. logcat抓日志定位崩溃和ANR的关键手段3.1 缓冲区、过滤级别、输出格式三个基本概念adb logcat可以说是Android调试里含金量最高的一条命令但很多人只知道adb logcat回车然后看天书一样的输出。要真正用好它先理解三个概念。第一是缓冲区。Android日志系统分为多个环形缓冲区最常用的是main应用日志、system系统日志、crash崩溃日志。默认logcat输出main、system、crash的合集但有时候区分开反而更好。比如只看崩溃adb logcat -b crash第二是过滤级别。每个日志条目都有一个优先级从低到高是VVerbose、DDebug、IInfo、WWarning、EError、FFatal、SSilent表示屏蔽一切输出。命令行里用*:级别来设定# 只看Warning及以上级别的日志 adb logcat *:W注意这里大写和小写有区别*:w会把不同tag的过滤规则叠加写起来容易乱建议直接用大写。第三是输出格式。默认格式信息量不够尤其是当你想把日志和工作代码对应起来的时候。推荐用threadtimeadb logcat -v threadtime这个格式会输出日期 时间 PID TID 优先级 Tag: 内容其中PID就是进程号在做多进程排查时尤其重要。3.2 抓崩溃现场和ANR日志的正确姿势最典型的场景App在测试机上一操作就闪退这时候用adb logcat倒计时抓取。我的习惯做法是先把旧日志清空让App跑出问题然后立刻把崩溃日志落盘# 清空现有日志 adb logcat -c # 复现问题后抓取崩溃缓冲区的日志并写入文件 adb logcat -b crash -v threadtime crash.log然后CtrlC结束用文本编辑器打开crash.log搜FATAL EXCEPTION或者AndroidRuntime关键字崩溃堆栈就在下面。ANRApplication Not Responding日志稍微隐蔽一点。通常搜ANR in这个关键字或者找am_anr事件。设备上ANR信息也会写到/data/anr/目录但普通设备没root看不了所以还是用logcat抓比较现实。这里有个经验之谈抓问题日志时不要只抓-b crash很多时候崩溃的前因不在crash缓冲区里而是之前main缓冲区的某些警告。建议稳稳地抓全量adb logcat -v threadtime full.log复现问题后CtrlC搜索FATAL EXCEPTION然后以崩溃时间为基准点往前翻500行左右往往能找到导致崩溃的关键线索。3.3 日志过大时的分析和过滤技巧日志文件动辄几十MB不可能肉眼一行行看。我的三板斧是按进程PID过滤。先用adb shell pidof 包名拿到进程号然后adb logcat | grep 12345按Tag过滤。App的日志一般都有固定的Tag在Android Studio里正确设置后的Tag通常是包名或自定义的TAG常量adb logcat -s 你的Tag名-s会屏蔽其他所有Tag只显示指定Tag的内容配合-v threadtime效果很好。按关键字过滤时grep的上下文参数很有用adb logcat -v threadtime full.log grep -n -A 50 FATAL EXCEPTION full.log-A 50表示显示匹配行之后50行对于抓崩溃堆栈来说正好。4. 高频调试命令速查进程、Activity、模拟输入4.1 看进程、看内存、看CPU调试性能问题或者确认App有没有被杀这三条命令足够了# 根据包名查进程PID adb shell pidof 包名 # 查看进程列表类似电脑上的任务管理器 adb shell ps -A | grep 包名 # 内存使用情况输出很详细 adb shell dumpsys meminfo 包名dumpsys meminfo的输出里有个关键指标是TOTAL PSS这个数值才是应用真正占用的物理内存估算值而不是Android Studio里那个大得吓人的Java Heap。看内存是否存在泄漏可以反复操作几次然后再看PSS是否持续增长。CPU占用看全局的话用adb shell top它会实时刷新各进程CPU占用排行。退出按q。强制停止某个应用在调试时也常用adb shell am force-stop 包名比直接杀进程干净利落会同时关掉该应用所有的后台服务和任务栈。4.2 启动Activity和查看界面元素启动Activity之前提过am start -n实际工作中还经常配合隐式Intent启动。比如调起系统分享面板adb shell am start -a android.intent.action.SEND -t text/plain或启动拨号盘adb shell am start -a android.intent.action.DIAL tel:10086这些在验证深链Deep Link和跨应用跳转时非常有用比手动操作快得多。查看当前屏幕上显示的是哪个Activity这条命令在定位界面跳转问题时是刚需adb shell dumpsys window | grep mCurrentFocus输出类似mCurrentFocusWindow{... com.example.app/.MainActivity}直接告诉你当前焦点Activity的完整类名。之前给App做竞品分析时就是靠这条命令摸清了对方各个页面的类名结构。界面元素分析用uiautomator可以输出当前界面所有控件的层级和文本adb shell uiautomator dump /sdcard/ui.xml adb pull /sdcard/ui.xml这个在写UI自动化脚本时很常用能看到每个按钮的resource-id和text属性不需要反编译APK。4.3 模拟点击、滑动和输入文本模拟用户操作这件事adb shell input命令就能做。虽然比不上自动化框架那么精细但临时点几下、滑几下完全够用。# 模拟点击坐标单位是像素 adb shell input tap 540 960 # 模拟滑动起始坐标到结束坐标最后的500是耗时毫秒 adb shell input swipe 540 1700 540 500 # 输入文本注意只支持ASCII字符 adb shell input text hello分辨率不统一的时候用wm size查一下设备分辨率避免坐标偏离。更稳定一点的做法是配合上面提到的uiautomator dump先解析出目标控件中心坐标再执行tap这样不同机型都能适配。按键模拟也很实用# 按Home键 adb shell input keyevent 3 # 按返回键 adb shell input keyevent 4 # 打开最近任务 adb shell input keyevent 1874.4 截图、录屏和修改显示参数截图在排查界面问题时太常用了不需要额外安装任何工具adb shell screencap -p /sdcard/screen.png adb pull /sdcard/screen.png录屏则用screenrecordadb shell screenrecord /sdcard/video.mp4按CtrlC停止文件会保存到设备上。screenrecord默认有3分钟时长限制和码率上限录长视频时可以考虑adb shell screenrecord --time-limit 60 --bit-rate 8000000 /sdcard/video.mp4修改屏幕显示的参数也是调试高频操作。比如把屏幕密度调大模拟小屏手机的显示效果adb shell wm density 320改分辨率adb shell wm size 1080x1920还有一些朋友关心的刷新率可以这样设置adb shell settings put system peak_refresh_rate 60 adb shell settings put system min_refresh_rate 60不过要说明的是并非所有设备都支持这些设置项的修改取决于系统版本和厂商实现。测试完记得adb shell wm size reset、adb shell wm density reset恢复默认。5. 无线调试与系统设置的进阶操作5.1 无线连接从adb tcpip到Android 11配对模式USB口不够用或者想调试车机、电视这类不好插线的设备时无线调试就派上用场了。传统方式分两步先USB连接用adb tcpip 5555让设备的adbd开始监听5555端口然后拔掉USB线用adb connect 设备IP:5555连接。adb tcpip 5555 adb connect 192.168.1.100:5555连接成功后adb devices里会出现一条带IP地址的设备记录。断开用adb disconnect。Android 11及以上系统改成了无线调试配对模式。先在开发者选项里打开无线调试然后记录下界面显示的配对码和端口通常是配对IP:PORT形式电脑上执行adb pair 192.168.1.100:38261按提示输入六位配对码。配对成功后使用界面显示的另一个IP端口直接connect即可。这个模式最大的好处是设备不需要连USB线也没有对USB接口的依赖配电视盒子、车机这类设备尤其方便。5.2 应用联网控制、组件停用等实用命令adb禁止应用联网这个话题经常看到。其实不同ROM对联网权限的管理方式不一样命令层面的做法没有万金油。对系统预装应用可以停用整个应用而不卸载这在给电视、盒子精简系统时特别常用adb shell pm disable-user --user 0 包名要恢复就adb shell pm enable 包名如果你是开发人员想临时验证某个应用断网时的表现可以试试AppOpsadb shell cmd appops set 包名 INTERNET deny恢复联网改成adb shell cmd appops set 包名 INTERNET allow不过不同厂商ROM对这个命令的支持程度不一有的机型会失效最好的办法还是在真机上实测。对于需要更精细的联网控制比如按WiFi/流量区分那就必须依赖带root的设备配合iptables或专门的防火墙应用了这里就不展开说了。5.3 修改系统设置的几个常用场景系统设置的修改往往能提升调试效率。比如让设备永不休眠跑自动化测试时屏幕不会中途熄灭adb shell settings put system screen_off_timeout 2147483647这个值单位是毫秒2147483647是int最大值约等于24天。恢复默认可以设为3000030秒。关闭窗口动画和过渡动画能让界面切换更快自动化测试也更稳定adb shell settings put global window_animation_scale 0 adb shell settings put global transition_animation_scale 0 adb shell settings put global animator_duration_scale 0没装Root工具也能长时间精准控制GPS开关、蓝牙开关这些不过命令是基于svcadb shell svc wifi enable adb shell svc wifi disable adb shell svc bluetooth enable adb shell svc gps enable这些命令对车载设备、电视盒子的自动化测试很有用不需要手动在设置里翻来翻去。6. 这些年踩过的坑连接与命令实战避坑记录6.1 驱动问题安装驱动和确认设备识别我在开头提过的那台平板最终的解决方案是去设备管理器手动更新驱动。在Windows上很多连不上的通病是手机能充电、电脑有叮咚声但adb devices空空如也。这时候去设备管理器看便携设备或其他设备里有没有一个叫ADB Interface或者带黄色感叹号的设备。有黄色感叹号右键→更新驱动→手动选择驱动路径指向platform-tools目录下的google驱动文件夹。没有这个文件夹的话去对应手机厂商官网下载USB驱动。步骤不复杂但我遇到过不少朋友卡在找不到驱动文件夹。其实platform-tools解压目录里不一定带驱动Windows下推荐安装官方的Google USB Driver这个在Android Studio的SDK Manager里可以单独下载路径通常在SDK目录\extras\google\usb_driver。6.2 adb unauthorized反复出现的根因授权弹窗之前讲过但有一种情况特别坑手机和电脑的名称每次都变比如用了一些虚拟USB网卡或者USB Hub设备ID识别不稳定导致即使勾选了一律允许换一个USB口又会变成unauthorized。遇到这种情况最彻底的解法是开发者选项→撤销USB调试授权然后重新连接、重新勾选。另外有人发现关掉USB安装权限或者手机的USB调试安全设置开关也会影响授权稳定性受影响的可以检查这两项。还有个细节当电脑上运行的adb server版本和手机端adbd版本差异过大时也可能出现莫名授权失效。方案就是升级platform-tools到最新版本保持两端兼容。6.3 多设备同时调试时命令串台电脑上插了两台设备直接执行adb install会报错adb: more than one device/emulator。解决办法是给命令加-s参数指定设备序列号adb devices adb -s 设备序列号 install xxx.apk如果是shell开头的命令也可以adb -s 设备序列号 shell pidof 包名写自动化脚本时我习惯先定义一个设备变量循环遍历所有设备执行命令避免人为指定串台for device in $(adb devices | grep device$ | awk {print $1}); do adb -s $device install xxx.apk done6.4 路径空格和转义符Windows上的路径如果带空格比如C:\Program Files\xxx\app.apk直接执行adb install很容易出问题。一个稳妥的做法是给路径加双引号adb install C:\Program Files\xxx\app.apk反过来如果你的文件名里带空格但安装包在设备端那要小心shell转义。adb push时本地路径加引号能解决但adb shell里的路径要用设备的转义规则。我见过有人在一个带空格目录里折腾半天教训就是调试用的APK、脚本文件一律放在无空格无中文的纯英文路径下。6.5 特殊设备上的ADB开关电视、车机的差异不是所有设备都叫手机。电视盒子、车机、手表调试时ADB的开启方式差别很大。很多电视/盒子的ADB开关藏在系统→开发者选项里但有些品牌需要先连续点击版本号若干次解锁开发者选项有些甚至要配合遥控器输入特定按键序列。车机更麻烦有些车型的ADB需要通过工厂模式或隐藏菜单开启不同品牌完全没有统一标准。如果只是想做基础的信息读取可以先试adb devices看能不能被识别如果设备根本没开启ADB服务那任何命令都白搭。另外部分设备在开启ADB时会要求输入动态验证码这个验证码一般和设备IMEI或特定算法绑定属于厂商私有方案只能按各自设备论坛的方案来操作无法通用。6.6 文件传输遇到Android分区存储限制越来越多朋友习惯直接把测试文件推到/sdcard/Android/data/包名/目录下在Android 11及以上系统会经常失败或看不到。这是分区存储机制的限制不是adb命令的问题。应对办法几个优先推到/sdcard/Download/或者其他公共目录再在应用内通过系统文件选择器读取如果应用有run-as调试权限即debuggabletrue可以在shell里切到应用身份访问私有目录adb shell run-as 包名 ls files adb shell run-as 包名 cat files/data.json有些需要精确写入应用私有目录的场景run-as是最可靠的但也仅限可调试应用。生产包无法用这个方式这几个办法轮下来大部分数据透传和文件排查的活儿都能完成。其实adb命令本身并不复杂难的是理解每条命令背后对应的Android系统机制。当你能把pm、am、dumpsys、logcat这些命令和系统里的包管理、Activity管理、日志缓冲区对应起来很多问题根本不用上Android Studio一条命令就定位了。我自己的习惯是建一个文本笔记把每个项目常用的包名、Activity类名、过滤关键词记下来配合脚本批量执行效率比在IDE里点点点高得多。这个习惯也用建议你从今天开始。