企业官网建设流程全解析

简介：面向Android开发、测试与运维人员的ADB常用命令速查文档，系统梳理Android Debug Bridge的高频操作，按场景分类，适用于真机调试、自动化测试、应用上线前的功能验证等环节。压缩包内共2个文件，主体为docx格式的详细说明文档，另附一个c格式辅助文件，整包仅19KB，轻量便携，可随取随用。内容从设备连接与状态检查入手，覆盖adb install/uninstall安装卸载应用、adb shell执行设备端命令、push/pull同步文件、logcat筛选日志、screencap/screenrecord截图录屏、tcpip/connect无线ADB连接、am force-stop强制停止应用等实用技巧，并对进入恢复模式、开启USB调试等前置操作做了必要说明。每个命令均配有简洁示例，按照功能分组排版，既方便新手按部就班地学习，也便于老手遇到具体问题时快速定位。已有914人学习下载，对普通开发者来说是快速上手的工具手册，对测试人员而言也是日常设备管理与日志排查的参考。

1. 这份 ADB 常用命令文档，帮你把设备连接、应用装卸和日志抓取一次讲透

手边一台安卓手机，想卸掉预装应用、抓个闪退日志、批量装几个测试包，结果打开命令行敲adb devices，先提示“adb 不是内部或外部命令”，折腾半天连上又卡在 unauthorized。这个场景对开发、测试和玩机玩家来说太常见了，而 ADB 常用命令正是为它准备的：一条命令安装 APK、查询包名、卸载系统应用、导出崩溃日志，能省掉大半手动点击操作。这份命令文档覆盖的范围并不神秘，按真实使用频率拆开就是四块：环境与连接、应用管理、日志抓取、故障排查。新手按顺序敲一遍就能跑通，熟手直接跳到参数部分对表查。全文没有要求你给手机装任何 App，全部基于 Android 系统自带的调试桥，最终你会得到一套随时能用的 ADB 手边工具。

2. 先把 ADB 装好把设备连上：驱动、开发者选项与 unauthorized 的第一课

2.1 安装 ADB 与配置 PATH：不用装软件但要把路指对

网上搜“ADB 安装包”会冒出一堆打包工具，我建议优先从 Android 官方开发者站点下载 platform-tools 压缩包，里面不只包括 adb，还有 fastboot 等常用二进制，解压后不需要安装，直接运行里面的 adb.exe 就行。直接把文件扔到桌面虽然能跑，但后续换目录会很麻烦，常见做法是固定放在一个不带空格的路径，比如 Windows 下C:\adb\platform-tools，macOS/Linux 下~/platform-tools，再把这个目录加进 PATH。

Windows 配置 PATH 最省事的办法是这条 setx 命令：

# Windows：把 platform-tools 目录追加到用户 PATH，等号前后别加多余空格 setx PATH "%PATH%;C:\adb\platform-tools"

设置完成后必须新开一个 cmd 或 PowerShell 窗口，老窗口不会自动刷新环境变量。macOS 则在~/.zshrc末尾加一行export PATH="$HOME/platform-tools:$PATH"，然后执行source ~/.zshrc。验证是否生效用adb version，能打印Android Debug Bridge version那串信息就说明路指对了；如果提示找不到命令，先别急着重装，八成是环境变量没刷新生效，或者配置 PATH 时把路径写错了。

这里要区分“ADB 驱动”和“USB 调试”：驱动负责让 Windows 认出你的手机，USB 调试负责授权和通信，这是两回事。新出厂的手机大部分免驱，老设备卡在驱动上时，去设备管理器看有没有带感叹号的 ADB Interface，再到手机厂商官网下载对应 USB 驱动。驱动装好但连不上，往往就是还没开 USB 调试。

2.2 打开 USB 调试并完成授权：从 adb devices 到 device 状态

USB 调试藏在开发者选项里，目前各品牌路径大同小异：设置 → 关于手机 → 连续点版本号 7 次，系统提示“你已进入开发者模式”，然后回到设置找开发者选项，打开“USB 调试”。用数据线把手机连到电脑，此时手机屏幕上会弹出“允许 USB 调试吗”并显示一串 RSA 指纹，勾选“始终允许”再点允许。这一步很多人容易翻车——弹窗不弹直接连，adb devices显示 unauthorized；或者以前手滑点了拒绝，后面一直连不上。

明白 adb 的架构对排查有好处：本机的 adb 客户端会连接后台的 adb server，默认监听 5037 端口，adb server 负责与设备通信。所以adb kill-server不是迷信，是让这个后台服务重启，清掉它和旧设备之间的坏状态。连上后的第一件事永远是看设备状态，这条命令也是整个 adb 体系的起点：

adb devices

输出格式是“序列号 + 状态”两列，序列号可能是真机串号，也可能是网络连接地址。状态有四种常见值，含义和处理方向如下表。

如果状态始终异常，常规操作是重启本机的 adb server：先adb kill-server再adb start-server，然后重插数据线。这是解决大多数“连不上”的第一板斧。注意adb start-server如果提示端口被占用，说明机器上还有旧版 adb 或手机助手在抢 5037 端口，这个放到第 5 章排查。

2.3 无线调试与局域网连接：电视、车机和手机都能用的方案

有线调试不是唯一出路。电视盒子、车机和智能音箱这类设备没有桌面 USB 口，就要靠网络调试。老的通用做法是先用有线连一次，执行adb tcpip 5555让 adb 服务切到监听端口，再拔线用adb connect连接设备 IP；从 Android 11 开始，开发者选项里直接多了“无线调试”开关，可以生成配对码，配对成功后连端口都不用记。

# 先把 adb 从 USB 模式切到网络模式，端口用常规的 5555 adb tcpip 5555 # 假设手机在局域网里的 IP 是 192.168.1.100 adb connect 192.168.1.100:5555

连接成功后再敲adb devices，状态列会变成 device，序列号位置显示192.168.1.100:5555。要断开就adb disconnect 192.168.1.100:5555。无线调试对网络环境有要求：电脑和设备必须可互访，中间隔了访客网络或者有 AP 隔离都会导致连不上。需要重申的是，打开网络 adb 相当于把设备调试口暴露在局域网内，我只建议在可信网络里用，用完及时关闭无线调试开关。

3. 应用管理命令是 ADB 的高频区：install、uninstall 与 pm 系列实战

装上、连上设备之后，实际工作中碰得最多的就是应用管理。装 APK、卸旧包、查包名、清数据，每一条都有自己的参数细节，也是“ADB 常用命令”里最不能出错的部分。

3.1 安装与覆盖安装：adb install 的 -r、-d、-t 参数如何选

安装 APK 是最基础的动作，但多数新人在参数上吃过亏。adb install的基本语法是adb install [-r] [-d] [-t] [-g] 包路径，不带任何参数直接安装，下面是常用参数对照表。

实际命令：

# 覆盖安装一个 debug 测试包，避开版本号和 testOnly 两个拦路虎 adb install -r -t -d app-debug.apk # 一次安装多个 APK，适合批量装渠道包 adb install-multiple apk1.apk apk2.apk apk3.apk

逻辑说明：-r不改变包签名校验和版本校验，只是安装时保留已存在应用的用户数据；-d专门针对“已安装更高版本”的报错，降级安装时必备；-t解决的是INSTALL_FAILED_TEST_ONLY，Android Studio 生成的 debug 包默认带 testOnly 标志，直接 install 不带-t就会失败。install-multiple更适合批量回归测试，但多个 APK 必须使用同一个签名，否则中途会报错中断。

安装过程最常见的失败输出有两个：INSTALL_FAILED_VERSION_DOWNGRADE是版本号比已装的低，加-d；INSTALL_FAILED_USER_RESTRICTED常见于部分品牌机限制 USB 安装，需要在开发者选项里把“USB 安装”允许开关打开。还有一类INSTALL_FAILED_UPDATE_INCOMPATIBLE，说明签名冲突，只能先卸载旧包再装新的。

3.2 卸载用户应用与系统应用：adb uninstall 和 pm uninstall --user 0

卸载命令有两层：adb uninstall和adb shell pm uninstall。第一层是 adb 的自带子命令，只负责卸载，语法最简单；第二层是进入设备后调用系统包管理器，功能更细，能指定用户空间卸载，这也是“卸载系统预装应用”的入口。

# 卸载普通第三方应用，包名必须是 com.xxx 的完整格式 adb uninstall com.example.app # 卸载当前用户下的系统应用，不触碰系统分区 adb shell pm uninstall --user 0 com.example.systemapp # 如果卸载不彻底，用禁用代替卸载，桌面图标同样会消失 adb shell pm disable-user --user 0 com.example.systemapp

--user 0的含义是“当前主用户空间”。很多预装应用被厂商写进了系统分区，普通卸载命令动不了它们，指定--user 0卸掉的是当前用户视角的副本，应用仍然占用系统分区空间，但桌面上看不到、也不再运行。这也是业内常说的后悔药：pm enable com.example.systemapp就能恢复，不用刷机。禁用命令disable-user更进一步，它绕过卸载逻辑，直接让包管理器屏蔽应用，对国产 ROM 里那些不可卸载的系统应用很有效。

这里的坑在于“卸载”和“禁用”的边界。如果目标应用是用户自己在应用商店装的，用第一行adb uninstall；只有应用是系统预装、无法点卸载时，才动用--user 0和disable-user。把--user 0当成万能卸载器去拆厂商核心组件，可能导致桌面崩溃、设置打不开，那就要通过pm enable一条条救回来。

3.3 查包名、查 Activity、清数据：pm list、dumpsys 与 pm clear 的配合

卸载前得知道包名。查包名基本靠pm list packages，这个命令输出量极大，要配合过滤使用。Windows 的 cmd 没有 grep，用 findstr；macOS 和 Linux 直接用 grep。

# 列出所有第三方应用，Android 官方把用户自装和部分预装归到 -3 adb shell pm list packages -3 # 按关键字过滤，比如找所有包含 tencent 的包 adb shell pm list packages | grep tencent adb shell pm list packages | findstr tencent

拿到包名之后，经常还需要定位当前打开的是哪个界面，方便做 UI 自动化或者确认跳转是否成功。这一条在常用命令文档里出现频率极高：

# 打印栈顶 Activity 的包名和类名 adb shell dumpsys activity activities | grep -E "mResumedActivity|topResumedActivity"

输出最后会给出类似mResumedActivity: ActivityRecord{... com.example/.MainActivity}，这就是当前前台界面。清数据和强制停止是两个经常一起出现但用途不同的操作：pm clear会删应用的全部数据，相当于恢复出厂；am force-stop只杀进程，数据还在。自动化测试里常用组合是“先 clear 再启动”。

adb shell pm clear com.example.app adb shell am force-stop com.example.app adb shell am start -n com.example.app/.MainActivity

pm clear对系统应用要谨慎，清掉了某系统组件的数据可能导致它无法正常工作；好在多数情况下重开应用就能自恢复，但仍有小概率进入永久黑屏的坑。测试机上这种状态多半要重刷系统，所以拿系统应用练手前，先确认它有可用的pm enable或重置路径。

4. 用 logcat 抓日志和基础调试：崩溃定位、截图录屏与文件传输

开发要数据、测试要证据，最后都落在 logcat 上。抓日志不一定要装抓包工具，adb 自带的功能已经够用，关键是掌握过滤和落盘这两件事。

4.1 logcat 按级别按进程过滤：抓崩溃日志只用一行命令

logcat 是 Android 日志系统的命令行出口，日志量极大，直接adb logcat会刷屏到怀疑人生。真正干活要用过滤参数，先看一条最常用的：

# 只输出 Error 及以上级别的日志，其他等级全部静默 adb logcat *:E -v threadtime

*:E是优先级过滤器，格式是“标签:级别”，*代表所有标签，级别从低到高是 V、D、I、W、E，Android 10 之后加了 F（Fatal）。-v threadtime让每条日志带“时间 线程ID 优先级 标签”前缀，是排查崩溃时的标准姿势。app crash 的核心现场是 tag 为“AndroidRuntime”的行，以及行内的“FATAL EXCEPTION”，抓 logcat 时不要只盯倒数几行，先搜这两个关键词。

有时候只想要某一个进程的日志，比如只看被测 App，可以先用pidof拿到 PID，再传给 logcat：

# 先取被测应用的进程号 adb shell pidof com.example.app # 假设返回 12345，按进程号过滤日志 adb logcat --pid=12345 -v threadtime

--pid比用包名过滤更可靠，因为 logcat 本身不认包名。再配合结束后的 dump 模式，就能得到一份干净的崩溃现场。常用流程是：先清空旧日志，再复现崩溃，最后把当前缓冲一次性导出。

adb logcat -c # 手动让应用崩溃，或执行复现步骤 adb logcat -d -v threadtime AndroidRuntime:E *:S > crash.log

-c清空缓冲里积压的旧日志；复现结束后用-d以 dump 模式退出，避免长时间挂在前台刷屏；AndroidRuntime:E *:S把 AndroidRuntime 之外的输出全部静默，最终落盘的文件很小、可读性高。这一套流程在测试交付场景很管用，你给开发一份几百 MB 的原始 logcat，不如给他这份抢救出来的崩溃现场。

4.2 截图、录屏、查系统参数：不用装任何 App 的调试手段

要在测试报告里留证据、复现偶现问题，不一定要装截图 App，adb 自带工具够用。截图命令有个容易踩的细节：用exec-out而不是shell screencap直接重定向。

# 直接输出 PNG 到本地，比 screencap 写到设备再 pull 少一步 adb exec-out screencap -p > screen.png # 录屏，最长时间受设备限制，默认 180 秒封顶 adb shell screenrecord --time-limit 30 /sdcard/demo.mp4

exec-out作为 adb 的一个执行通道，会原样输出二进制流，不会像普通adb shell那样把换行和回车做平台转换，所以截图必须用exec-out screencap。录屏参数里--time-limit最大 180 秒，画面默认尺寸按设备屏幕来，要控制大小可以加--size 720x1280。查系统参数最实用的一批命令包括getprop、wm和dumpsys battery：

adb shell getprop ro.product.model adb shell wm size adb shell wm density adb shell dumpsys battery

getprop ro.product.model返回机型，wm size和wm density返回当前分辨率和屏幕密度，做兼容性适配时用来核对设备信息。dumpsys battery能看到电量、温度、充电状态，比在手机上翻设置快得多。

4.3 push 与 pull：把文件送进设备再拿回来

adb push和adb pull是文件传输的一等公民，放在调试章节里，是因为它们常和截图、日志配合使用。

# 把本地安装包推进设备的下载目录 adb push app.apk /sdcard/Download/ # 把设备上的视频拉到当前目录，注意结尾的 ./ adb pull /sdcard/Download/demo.mp4 ./

路径上建议优先选/sdcard和/sdcard/Download，这两个目录普通应用可读可写，不需要 root 权限；系统目录需要 root 或 adb root 权限，普通机器 push 到/system会报权限不足。pull时如果文件正在被占用会读到空文件，尤其不要一边录屏一边拉 mp4，等录完再拉。push 大文件时中途断开是正常现象，重新执行一次即可，adb 没有断点续传，别指望它能在弱网环境下的稳定可靠，文件大就换数据线。

5. 避坑排查：ADB 连接与命令执行的 5 个经典现场

命令记熟了，最后还是要过排查关。下面 5 个现场都是我处理过的高频问题，按“现象、原因、解决”三条写，方便对号入座。

5.1 现象：adb devices 一直显示 unauthorized，怎么解决

现象：adb devices输出一串XXXXXXX unauthorized，手机端却没有任何授权弹窗；重新拔插数据线也没有反应。原因：Android 的 USB 调试授权是每台电脑一个 RSA 指纹记录，只要之前在弹窗上点过“否”，这台电脑就会被记住并拒绝授权；部分国产 ROM 还要求解锁屏幕才能弹窗。解决：打开开发者选项，找到“撤销 USB 调试授权”或“删除授权记录”，撤销后重新拔插数据线，就会再次弹出 RSA 授权框，勾选“始终允许”。如果弹窗还是不出现，把当前 adb server 重启一次再接。这个问题的本质是设备端的授权状态，不是电脑端能硬解的，别在电脑上反复重装驱动浪费时间。

5.2 现象：提示 adb 不是内部或外部命令，也不是可运行的程序

现象：在 cmd 里敲adb，直接回“'adb' 不是内部或外部命令，也不是可运行的程序或批处理文件”。原因：platform-tools 目录没有加进 PATH，或 PATH 改完没重开终端；系统里装了多个 adb 时，新加的路径被旧的覆盖。解决：先用绝对路径验证工具本身可用，比如C:\adb\platform-tools\adb version；然后在系统环境变量里把 platform-tools 放在靠前位置；最后打开一个全新终端测试。开发机上如果同时装了 Android Studio 自带的 platform-tools，两个版本不一致时，优先统一删掉一个，避免调半天才发现是本机 adb server 与新版工具不匹配。

5.3 现象：设备 offline 或反复断开，执行命令中途丢连接

现象：adb devices显示 offline，或者刚跑一条命令就提示 connection lost。原因：数据线是纯充电线，没有数据通道；Windows 驱动安装不正确；adb server 端口被手机助手、模拟器或占用 5037 端口的进程抢走。解决：先换线，换原装或至少能传文件的数据线；执行adb kill-server && adb start-server重启服务；再用netstat -ano | findstr 5037看端口占用，查到 PID 后在任务管理器里结束对应进程。注意重启 adb server 后，原来已经授权的 USB 调试记录还在，通常不需要重复授权，除非你连的设备真的被你彻底重置了。

5.4 现象：卸载系统应用报错 Failure [DELETE_FAILED_INTERNAL_ERROR]

现象：用adb shell pm uninstall --user 0 com.example卸载预装应用，返回Failure [DELETE_FAILED_INTERNAL_ERROR]，或者提示 Success 但桌面图标还在。原因：部分厂商把包标记为不可卸载，--user 0对它们不生效；或者应用本身还在运行，被系统锁定。解决：先用am force-stop com.example强停，再执行卸载；仍然失败就把卸载换成禁用：adb shell pm disable-user --user 0 com.example。禁用后图标消失、进程被杀，效果接近卸载。要恢复就执行adb shell pm enable com.example。还有一类情况是adb uninstall卸载用户应用时报DELETE_FAILED_DEVICE_POLICY_MANAGER，表示该应用是设备管理器，需要先去系统设置里解除设备管理器激活再卸。

5.5 现象：logcat 抓下来的文件在 Windows 乱码，或漏抓崩溃现场

现象：adb logcat -v threadtime > crash.log在 Windows 下打开，中文注释和 tag 名变成乱码；崩溃明明发生了，但日志里找不到 FATAL EXCEPTION。原因：Android 日志是 UTF-8，Windows 的 cmd 默认用 GBK 编码写文件，两边编码不一致；漏抓则是因为没清缓冲，关键行被旧日志淹没。解决：在 cmd 开头先执行chcp 65001把代码页切到 UTF-8，再重定向；抓取前先adb logcat -c清空，复现完崩溃用adb logcat -d -v threadtime AndroidRuntime:E *:Sdump 当前缓冲。如果你用 PowerShell，直接adb logcat -v threadtime | Out-File -Encoding utf8 crash.log，避免 cmd 的代码页问题。

6. 把 ADB 常用命令封装进自己的小工具：传参脚本与快速抓日志的技巧

假设你每天要测多台设备，装的卸的抓日志的命令都要重复敲，这时再翻文档就慢了。我自己的习惯是把高频命令封装成一个小脚本，放进 PATH，参数化使用：

#!/usr/bin/env bash # adb-helper.sh：把装机、卸机、抓日志、截图收敛成四个子命令 cmd=$1 case "$cmd" in install) adb install -r -t "${2}";; # 覆盖安装 test APK uninstall) adb shell pm uninstall --user 0 "${2}";; # 卸载或隐藏预装应用 logcat) pid=$(adb shell pidof "$2"); # 实时取进程号 adb logcat --pid="$pid" -v threadtime;; # 按进程过滤日志 screenshot) adb exec-out screencap -p > "${2:-screen}.png";; # 截图回传本地 *) echo "用法: adb-helper.sh {install|uninstall|logcat|screenshot} 参数";; esac

这段脚本借用了第 3 章的-r -t、--user 0、--pid和第 4 章的exec-out，把整个常用命令集里最高频的四条变成命令行工具。重点注意logcat的 PID 是每次执行时用pidof现取的，不能写死，否则换应用就失效；Windows 上没 bash 的话，把同样的分支逻辑写成 .bat，用%1和%2取参，效果一样。

脚本只是形式，真正的验证方法是给自己定一个简单规矩：新换电脑、新接设备，先跑通四条命令——adb devices看连接、adb install -r看安装、adb logcat -d看日志、adb pull看文件传输。这四条覆盖了连接、安装、调试、传输四个环节，任何一条失败都说明环境还没彻底就绪，先解决它再干别的活。我刚接触测试时最怕临时被叫去抓日志，翻文档像无头苍蝇，后来把命令整理成这份速查文档，用脚本把这些高频操作固化下来，遇到问题先跑脚本，跑不通再逐条手动定位，这让我少踩了不少坑。你也值得留一份这样的手边工具，希望帮到你。

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