ADB高频命令实战指南：从设备调试到应用逆向分析

第二天了。如果你的第一天是在安装 JDK、下载 Android Studio、解压各种逆向工具的折腾中度过的，那从今天起，我们终于进入真正“动手”的阶段。今天的主线任务非常明确：把 ADB 高频命令练到滚瓜烂熟，并且用一台真实的 Android 设备把整个交互链路跑通。

ADB 这个名字你可能早就听过，甚至可能已经会两三条命令，比如 adb devices、adb install，但大概率是“复制粘贴侠”式用法——能用，却不懂背后的工作原理。这其实很危险，因为后续你做包名定位、日志过滤、Activity 拉起、文件提取时，只要环境或状态稍微出点问题，看不懂报错就只会卡死。今天这篇，我不打算给你列一张几十条命令的“字典”，而是按逆向实际工作流的顺序，把每条高频命令的用途、参数、坑位一次讲透。适合刚起步的逆向新人，也适合那些想把自己的 ADB 操作从“半懂不懂”提升到“肌肉记忆”的进阶开发者。

1. ADB 的本质：先搞懂通话链路，再看命令

ADB 全称 Android Debug Bridge，中文常译作“安卓调试桥”。这个“桥”字很有意思——它连接的对象是你的电脑（宿主机）和 Android 设备，提供的是一条稳定、可复用的双向通信通道。别看现在手机厂商各搞各的定制系统，但在调试底层这件事上，大家无一例外都保留了 ADB 这个标准入口。理解了这一点，你就能明白为什么逆向学习的第二天就必须碰它：因为不管是静态分析前的 APK 提取，还是动态分析时的进程操控，ADB 都是最底层的那把钥匙。

1.1 ADB 工作过程的三个角色

很多人以为 adb 是一个“程序”，其实严格来说它是一套客户端-服务端-守护进程的体系，由三部分协作：

• 客户端（client）：运行在你的电脑上。每当你敲一条 adb xxx 命令，系统就会启动一个客户端进程，把你的指令打包成协议消息。
• 服务端（server）：同样运行在你的电脑上，但它常驻后台，负责监听 5037 端口，维护当前电脑连接的所有设备列表，并把客户端的请求转发给正确的设备。adbd 和手机之间的连接管理、消息路由都由它承担。
• 守护进程（adbd）：运行在 Android 设备内部。它只有在设备开启“USB 调试”后才会启动，负责真正执行命令，比如安装应用、读取文件、执行 shell 指令。

可以这样类比：客户端是去柜台办事的“客户”，服务端是公司前台，adbd 则是后面工位上真正干活的员工。客户只负责提需求，前台负责找到人，员工负责落地执行。这个前台接单、分发的机制，使得电脑可以同时连着多台设备，也可以随时切换目标，而不用每次重新建立物理连接。

值得提前记住的是，服务端与设备之间并非只能走 USB。ADB 协议本身支持 TCP/IP 传输，所以只要手机和电脑在同一网络内，执行 adb connect IP:端口 就能进入“无线调试”模式。后面实操部分，我会专门演示这一招。

1.2 为什么逆向学习必须把 ADB 练熟

在逆向这个领域，ADB 几乎贯穿所有阶段的全部关键动作。你可以把它理解成一个“多面手”：

• 当你需要快速识别目标 App 的包名、版本、安装路径，ADB 是效率最高的方式；
• 当你需要把设备里的 APK 原封不动搬回电脑进行分析，ADB 的 pm path + pull 组合一分钟内完成；
• 当你需要观察 App 启动时的日志、崩溃现场、组件调用顺序，ADB 的 logcat 就是设备黑匣子；
• 当你需要模拟用户点击、滑动、输入、旋转屏幕，ADB 的 input、wm 命令可以精准操控；
• 当你后面引入 Frida、Xposed 这些动态插桩工具时，启动目标应用、检查进程状态，依然离不开 ADB 兜底。

所以今天的每一分钟都不是白费的。把 ADB 练好，等于一口气学完了后面十几天课程里都会用到的公共同基础设施。

2. 开工前的 15 分钟：把 ADB 环境打磨顺滑

工欲善其事，必先利其器。这一节我会把环境准备拆成四个步骤：下载工具、修复 PATH、开启设备调试、解决多版本冲突。每一步都踩过无数人的坑，我按顺序走一遍。

2.1 获取 ADB 的两种常见方式

方式一：下载完整版 Android Studio，通过 SDK Manager 勾选“SDK Platform-Tools”。适合你未来要深度开发 App、用模拟器调试、打包签名，需要图形化工程管理工具的情况。缺点是安装包大、首次初始化时间长，而且 Studio 内置的 SDK 路径在不同版本上变化较多，对只想玩逆向的朋友来说有点“杀鸡用牛刀”。

方式二：单独下载 platform-tools 压缩包。这是官方提供的命令行工具集，体积小，解压即用，内部包含 adb.exe、fastboot.exe 等核心工具。这也是我更推荐逆向学习者采用的方式。下载完成解压到固定目录，比如 Windows 下放到 D:\platform-tools，后面所有操作都围绕这个目录展开。

提示：注意不要从第三方下载站拿压缩包，那里面的 adb 可能被修改过，也可能捆绑额外软件。认准官方渠道，这是环境安全的第一道防线。

2.2 解决“adb 不是内部或外部命令”

这是几乎每个新手的第一次碰壁。原因不复杂：你在命令行里敲 adb，操作系统会在当前目录和 PATH 环境变量列出的目录中寻找 adb 可执行文件，都找不到就会报这个错。

解决办法有两种，我建议直接做第二种。

第一种：每次运行时手动切换目录：

cd /d D:\platform-tools adb version

第二种：把 platform-tools 加入 PATH。在 Windows 里右键“此电脑”→“属性”→“高级系统设置”→“环境变量”，在系统变量里找到 Path，点击编辑，新建一行，填入 D:\platform-tools，保存后重新打开命令行窗口。macOS 和 Linux 则在 ~/.bashrc 或 ~/.zshrc 里导出 PATH。

配置完成后，输入 adb version，能显示类似 Android Debug Bridge version 1.0.41 的结果，就算安装成功。

这里补充一个排查细节：如果你已经配了 PATH 却仍然报错，用 where adb（Windows）或 which adb（macOS/Linux）查看系统实际解析到的 adb 路径。许多人在电脑上装过多个 SDK，旧版本的 adb 路径排在前面，导致执行的根本不是你配置的那个。这种情况光追加 PATH 是没有用的，需要把旧路径从环境变量里删掉。

2.3 设备端开启开发者模式与 USB 调试

命令环境准备好之后，还要让手机愿意“接电话”：

1. 打开“设置”→“关于手机”，找到“版本号”那一项；
2. 连续点击版本号 7 次，系统会提示“已进入开发者模式”；
3. 返回设置，找到“开发者选项”，打开“USB 调试”开关；
4. 用数据线连电脑，手机上弹出“是否允许 USB 调试”对话框，勾选“始终允许”，点允许。

如果你找不到“开发者选项”，大概率是刚才点击的位置不对。注意是“版本号”，不是“操作系统版本”或“内核版本”。另外，部分新机型默认隐藏开发者选项，需要在设置搜索框里输入“开发者”直接跳转。

提示：连上电脑后，手机端会要求选择 USB 连接模式。尽量选择“文件传输（MTP）”，而不是“仅充电”。有些系统在“仅充电”模式下会限制调试通道，导致 adb 怎么都连不上的奇怪问题。

2.4 无线调试与多版本 ADB 冲突

USB 调试不是唯一选择。当你在工位之间走动，或者没有合适数据线时，无线调试非常有用。先通过 USB 连一次，执行：

adb tcpip 5555

这条命令告诉设备在 5555 端口开放 ADB 调试服务。然后拔掉数据线，执行：

adb connect 192.168.1.100:5555

把 IP 换成你手机的局域网地址。看到 connected 字样后，后续操作与 USB 模式完全一致。

无线调试最大的坑，是电脑上同时跑着多个版本的 ADB 服务。比如你安装过 Android Studio，又用过第三方工具箱，它们各自带了不同版本的 adb.exe。你在新终端敲 adb 命令时，系统可能直接提示“检测到电脑上同时运行了多个版本的 adb 服务，版本不一致”。这个警告的本质是：不同版本的 server 使用了不同的通信协议，把旧的/冲突的 adb 进程留着，会导致新 server 与设备握手失败，甚至出现设备列表错乱。

解决办法一句话：彻底清理旧的 ADB 服务，重建干净的单一实例。

adb kill-server

然后在任务管理器中结束所有名字含 adb.exe 的进程，再执行：

adb start-server adb devices

这一步之后，绝大多数“命令没反应”“设备连不上”“经常 offline”的诡异问题都会消失。

3. 高频命令速查：把常用姿势固化到肌肉里

环境理顺之后，我开始按逆向日常使用的频率，把这组命令过一遍。先看设备状态，再看应用管理，然后是文件传输、shell 交互和日志采集。每一条我都会解释“为什么这样写”，而不只是让你抄答案。

3.1 设备状态管理三板斧

先来最基础的三条。

adb devices

列出当前连接的所有设备。输出有两列：序列号和状态。状态只有三种，必须学会分辨：device 表示正常，offline 表示设备掉线，unauthorized 表示设备未授权。

adb kill-server adb start-server

这两条是 ADB 的“重启大法”。当你看到命令卡在 waiting for device，或者设备的在线状态反复横跳时，先执行这两条，再插拔一次数据线，大部分问题都能自愈。

adb reboot

远程重启设备。做自动化测试前，用它把设备恢复到干净状态，比手动重启方便得多。

除了这三条，我每次拿到一台新设备还会顺手确认四个参数：

adb shell getprop ro.product.model adb shell getprop ro.build.version.release adb shell wm size adb shell wm density

它们依次返回设备型号、Android 系统版本、屏幕分辨率和像素密度。做屏幕适配分析、确定目标 App 运行环境时，这些参数就是你的“环境身份证”。

3.2 应用管理：安装、卸载、查包、捞包

这一组命令是整个逆向流程中使用频率最高的部分，没有之一。先说安装：

adb install C:\apps\demo.apk

如果需要覆盖安装并保留应用数据，加 -r 参数：

adb install -r C:\apps\demo.apk

如果希望允许降级安装，比如从版本 2.0 退回 1.9，加 -d：

adb install -r -d C:\apps\demo.apk

如果想要安装完成后直接授予所有运行时权限，加 -g：

adb install -g C:\apps\demo.apk

卸载应用要注意，参数是包名，不是应用名：

adb uninstall com.example.demo

查看设备装了什么包：

adb shell pm list packages

按关键词过滤，Windows 命令行用 findstr，macOS/Linux 用 grep：

adb shell pm list packages | findstr demo

找目标 App 的 APK 路径：

adb shell pm path com.example.demo

输出通常是 package:/data/app/com.example.demo-xxxx/base.apk 这样的格式。拿到路径后用 pull 拉回本地：

adb pull /data/app/com.example.demo-xxxx/base.apk C:\apps\base.apk

这一套连招下来，你从只知道一个包名，到本机多了一个完整的 APK 文件，总耗时不会超过一分钟。这就是逆向工作流里最高频的入口动作，建议多练几遍。

3.3 文件传输：只记住两条对称命令

文件传输就两条命令，方向相反：

adb push 本地路径 设备路径 adb pull 设备路径 本地路径

实际例子：

adb push C:\test.txt /sdcard/test.txt adb pull /sdcard/log.txt C:\data\

这里要提一个低级但常见的坑：路径包含空格时，必须用双引号把整个路径包起来。比如 C:\Program Files\demo.apk，就要写成：

adb push "C:\Program Files\demo.apk" /sdcard/demo.apk

另外，设备路径推荐统一走 /sdcard/ 目录作为中转。直接向 /data/ 目录推送文件几乎都会因为权限不足而失败，没必要和系统权限较劲。

3.4 Shell 命令：进入设备内部世界

执行：

adb shell

你会进入设备内部的 Linux shell 环境，这时你可以像在 Linux 终端一样操作。如果只是想临时执行一条命令而不进入交互模式，直接在 adb shell 后面跟命令：

adb shell ls /sdcard adb shell cat /proc/cpuinfo

逆向分析时，我常用这些 shell 命令：

• ps -A：查看所有进程列表
• top：查看实时 CPU 占用
• netstat -tunap：查看网络连接
• ls -al：查看目录及详细文件信息
• su：切换 root 用户（前提是你的设备已经 root）

shell 模式下还能模拟用户输入，这在自动化埋点、自动遍历页面时极其好用：

adb shell input keyevent KEYCODE_HOME adb shell input keyevent KEYCODE_BACK adb shell input tap 540 1280 adb shell input swipe 540 1280 540 400 200

tap 后面的两个数字是屏幕上的像素坐标，swipe 的最后一位是滑动耗时，单位毫秒。坐标可以通过开发者选项里的“指针位置”功能获取，打开后点击屏幕，屏幕顶部会实时显示触摸坐标，非常方便。

3.5 日志采集：logcat 是设备黑匣子

Android 运行时的系统日志、应用日志、崩溃堆栈，全部通过 logcat 输出。最基础的用法：

adb logcat

实时打印日志，刷屏速度惊人，所以更常用的其实是这几个带参数的姿势：

adb logcat -c adb logcat -d adb logcat -d -t 50 adb logcat -s TagName

-c 清空历史日志；-d 输出已有缓存日志后自动退出；-t 50 表示只输出最近 50 行；-s 后面跟标签名，可以只看某个 Tag 的日志。

抓崩溃日志的典型姿势：

adb logcat -d | findstr "FATAL"

macOS/Linux 把 findstr 换成 grep。日志量太大的时候，建议重定向到文件：

adb logcat -d > app_log.txt

然后慢慢在文本编辑器里搜索关键词。直接盯着滚动终端看日志，眼睛迟早会花。

4. 强制屏幕方向与 App 交互：你早晚用得上的组合技

平时手工转手机测横屏很容易，但自动化或者远程操作时，你就需要让设备瞬间改变屏幕方向。这一节把方向控制和 Activity 启动放在一起讲，因为它们组合起来可以解决很多模拟器、深度页面、横竖屏适配的验证问题。

4.1 用 wm 和 settings 两条路线控制方向

先看当前屏幕基本参数：

adb shell wm size adb shell wm density

方向控制的命令有两套，建议都记住，因为它们在不同系统版本和厂商 ROM 上的表现不一样。

第一套走 settings 配置：

adb shell settings put system accelerometer_rotation 0 adb shell settings put system user_rotation 0

第一行关闭自动旋转，第二行把手动方向设为 0。第二行的参数 0 到 3，分别代表 0 度、90 度、180 度、270 度旋转状态。

第二套走 wm 命令：

adb shell wm user-rotation lock 1

这条把屏幕锁定在 90 度方向。在部分原生 Android 系统上很有效，但在一些厂商深度定制的 ROM 上可能不生效。如果你发现命令执行没有反应，就改用第一套 settings 方式。

恢复自动旋转：

adb shell settings put system accelerometer_rotation 1 adb shell wm user-rotation unlock

一个实用小技巧：改变方向后如果界面卡片没有立刻刷新，可以执行一次：

adb shell input keyevent KEYCODE_POWER

关屏再点亮，大部分设备在亮屏后都会重新应用方向参数，省得你去手动折腾屏幕开关。

4.2 启动指定 Activity：直达深链页面

做逆向分析时，你经常遇到“主界面能进，某个深层页面怎么都点不进去”的困境。这时候有两种路径：要么靠人肉点击找入口，要么直接用 am 命令拉起目标页面。显然是后者更香。

基本格式：

adb shell am start -n 包名/Activity全称

实例：

adb shell am start -n com.example.demo/.MainActivity

如果 Activity 全称是 com.example.demo.MainActivity，而包名也是 com.example.demo，可以简写为上面的形式。如果 Activity 位于子包名路径下，则要写全：

adb shell am start -n com.example.demo/com.example.demo.ui.SplashActivity

还可以在启动时附带参数：

adb shell am start -n com.example.demo/.MainActivity --es key "value" --el start_time 123456

--es 传字符串，--el 传长整数。这在测试带参数跳转的页面时非常关键。

另一个实用变体是 -W 参数：

adb shell am start -W com.example.demo/.MainActivity

-W 表示等待启动完成，并输出启动耗时信息。后面你如果用 Frida 做启动阶段 Hook，这个命令就能帮你准确判断启动时序。

4.3 实时查看当前前台应用

怀疑某个弹窗、悬浮球是哪个应用拉起来的？用一条命令直接看当前焦点窗口：

adb shell dumpsys window | grep mCurrentFocus

输出里通常包含类似 com.example.demo/com.example.demo.MainActivity 这样的信息，一看就知道谁在前台。

如果想看更详细的 Activity 调用栈：

adb shell dumpsys activity top

这条命令会输出当前顶部的 Activity 及其关联信息。在逆向分析弹窗广告、强制跳转问题的时候，它是定位“幕后黑手”的好帮手。

5. 逆向实战中 ADB 的正确打开方式

单独的命令你已经见过了，但这还不够。真正的工作流是把命令串成一条流水线，从目标定位到样本采集，从崩溃复现到日志分析，一气呵成。我挑三个最常见场景，带你过一遍完整流程。

5.1 场景一：5 分钟内弄到目标 App 的安装包

假设你看到一款 App 的新功能很值得研究，但你手里没有渠道包，最好的来源其实是已经安装该 App 的设备本身。操作步骤：

1. 手机连电脑，执行 adb devices 确认设备在线；
2. 执行 adb shell pm list packages | findstr 关键词，找到精确包名；
3. 执行 adb shell pm path 包名，拿到 base.apk 路径；
4. 执行 adb pull 路径 本地目录，把文件拉到电脑；
5. 对本地文件执行一次校验，避免传输损坏。

相比去各种非官方下载站点碰运气，这种自己从设备导出的方式来源可信、版本精确，做样本比对分析时更有说服力。

5.2 场景二：捕捉应用启动瞬间的关键日志

典型场景是这样：目标页面点击后闪退，崩溃堆栈可能一闪而过，但你不知道它到底在什么阶段崩的。这时可以按四步走：

1. 清空旧日志：adb logcat -c
2. 启动目标应用：adb shell am start -n 包名/主Activity
3. 等待 2 到 3 秒，让初始化链路完整跑完
4. 导出日志：adb logcat -d > startup.log

然后在日志文件里搜索 FATAL、Exception、ClassNotFoundException、Process 等关键词。如果没搜到明显的崩溃信息，就切到另一个视角，执行 adb shell dumpsys activity top 查看 Activity 是否真的成功启动。有些崩溃发生在 Activity 实例化之前，日志中只会留下“Process ... has died”之类的片段，这时候结合 am start -W 的启动时长一起分析，能更快定位问题阶段。

5.3 场景三：用 monkey 做轻量自动化遍历

写复杂自动化脚本太费时间的时候，monkey 就是现成的“乱拳打死老师傅”工具。它会向目标应用随机发送事件流，包括点击、滑动、按键、系统事件：

adb shell monkey -p com.example.demo -v 500

-p 指定目标包名，-v 意为 verbose，500 是打算发送的事件数量。如果应用不稳定，大概率会在随机事件中崩溃。崩溃发生时，monkey 会在输出末尾打印 error 信息，再配合 logcat 就能抓个正着。

增加 -s 参数可以固定随机种子：

adb shell monkey -p com.example.demo -s 12345 -v 500

同一个种子会生成完全相同的事件序列。这样在修复某个崩溃之后，你还能用同一套事件流验证问题是否真的被解决，而不需要靠运气复现。

6. 常见问题排查与我的踩坑经验

最后这部分，是实战中最常遇到的五类坑。很多问题都不是命令记不住，而是环境或状态不干净，我按优先级给你列好排查路径。

6.1 unauthorized 状态怎么解决

unauthorized 说的是设备连上了，但用户没有授权 USB 调试。常见原因有两个：第一次连接时手机弹窗被手滑点掉了，或者手机屏幕锁着，弹窗根本没弹出来。

处理顺序：

1. 拔掉数据线；
2. 手机上进入开发者选项，点“撤销 USB 调试授权”；
3. 重新插线，在弹窗上勾选“始终允许”，点击允许；
4. 执行 adb devices，状态应当变为 device。

如果还是 unauthorized，执行 adb kill-server 和 adb start-server 重置服务，然后再查一次设备列表。

6.2 多版本 ADB 服务冲突

我在 2.4 节提过，这里再给一个更完整的处理办法。当系统提示“检测到电脑上同时运行了多个版本的 adb 服务，版本不一致”时，核心思路是把旧的/冲突的 adb 进程全部清理掉。可以在任务管理器里搜 adb，把所有相关进程结束，同时在服务列表里查看有没有名为 adb 的服务残留。清理完毕后执行 adb start-server 重建服务，问题就会消失。如果你同时装了 Android Studio、第三方模拟器和独立的 platform-tools，建议只保留一个版本的 adb，并把它在所有终端工具里的路径统一。

6.3 设备显示 offline 的排查顺序

offline 状态的问题比 unauthorized 更杂，常见诱因包括数据线不支持数据传输、USB 接口供电不足、ADB 服务与 adbd 版本不匹配等。我的排查顺序：

1. 换数据线，优先换原装线；
2. 换电脑 USB 口，优先笔记本后置口或台式机机箱背面接口；
3. 执行 adb kill-server 和 adb start-server；
4. 拔插设备重启一次调试通道；
5. 换一台电脑交叉验证，定位到底是设备问题还是电脑问题。

按这个顺序能解决 90% 以上的 offline，少走很多弯路。

6.4 模拟器连接不上

用 Android Studio 自带模拟器时，设备列表里一般会自动出现 emulator-5554 这样命名的设备。如果没有，可以手动连接：

adb connect 127.0.0.1:5555

模拟器的调试端口通常在 5555 到 5585 区间，多个模拟器同时运行时端口会递增。使用第三方模拟器时，先检查它的设置里有没有单独提供 ADB 调试开关，很多模拟器默认关闭，并不是你没连对端口。

写到这里，今天的 ADB 工具基石就算打完了。我个人实际摸索下来的体会是，ADB 这个工具真不用死记命令，关键在于建立“遇到问题先反应出对应命令”的条件反射。能一次拉包、一次定位、一次复现，效率就上来了。明天开始进入 APK 结构拆解和 Jadx 静态分析，到时候 pm 和 pull 这两个动作会成为你每天都要重复的基本功。现在就把设备连一次，把上面的流程完整走一遍，别偷懒，明天你会感谢今天的自己。