简介：adb 1.0.39 Windows版是面向Android开发者与安全研究人员的官方平台工具包，可在Windows下连接、调试和管理Android设备或模拟器，解决驱动识别、设备通信与应用部署等常见问题。压缩包共包含1716个文件，大小9.53MB，以Python脚本（343个）、HTML文档（587个）、JavaScript/CSS资源、JSON配置、可执行程序及atrace/systrace分析数据为主，既提供adb、fastboot等核心命令行工具，也附带设备追踪、性能剖析与自动化测试所需的辅助脚本；目录中的HTML说明、Python工具脚本与各类数据文件为二次开发或深度调试提供了完整参考。已有416人学习下载。通过这份工具包，用户可完成设备识别与USB/Wi-Fi连接、APK安装卸载、shell命令执行、日志抓取、进程管理，以及基于atrace/systrace的Chrome性能分析和系统调用追踪；还可利用恢复模式相关工具进行系统更新与备份恢复。适合需要在Windows环境上进行应用调试、系统分析与安全评估的开发者使用。

1. adb 1.0.39 Windows 版：安全排查工作台的第一步

很多人把 adb 1.0.39 windows 版当成一个老掉牙的调试工具，觉得新版本遍地都是，没必要回头看。但真正做过 Android 安全排查的人会告诉你，这个版本的 adb 在 Windows 上反而是最稳的一批——它不依赖 Android Studio 全家桶，解压就能跑，兼容从 Android 5 到 Android 10 的绝大多数设备，干安全检查的活儿绰绰有余。这篇笔记写给两类人：一是要给设备做安全状况确认的工程师，二是刚接触 Android 调试、想绕过图形界面直接看系统状态的开发者。我会把安装、配置、命令、坑位一次说清，保证你照着敲能落地。

2. 安装与驱动：从解压到设备可见的三个关键动作

2.1 解压与 PATH 配置：先把 adb.exe 请进命令行

拿到 adb 1.0.39 windows 版的压缩包后，第一步不是双击运行，而是把它放在一个固定目录并配置环境变量。我一般习惯放在 D 盘根目录下，路径不带中文、不带空格，避免后续命令行解析出幺蛾子。比如解压到D:\adb，目录下能看到adb.exe、AdbWinApi.dll、AdbWinUsbApi.dll、fastboot.exe这几个关键文件。

接下来配置 PATH。在 Windows 搜索框输入“环境变量”，打开“编辑系统环境变量”，在“系统变量”里找到 Path，新增一行D:\adb。配置完成后，重开一个 CMD 窗口，敲下面的命令验证：

adb version

正常输出会包含Android Debug Bridge version 1.0.39字样。如果提示“不是内部或外部命令”，说明 PATH 没生效，要么重开终端，要么检查路径是否写错。还有个更省事的做法：直接在 adb 所在目录按住 Shift 右键，选择“在此处打开 PowerShell 窗口”，然后执行.\adb version，这样连 PATH 都不用配，适合临时用一下的场景。

配置 PATH 的意义不只是让你少敲几个斜杠，而是让其他工具能自动调用 adb。比如后面做安全脚本、批量抓包、自动化取证时，脚本直接调adb命令，不用每次写完整路径，这才是工程化的基础。

2.2 驱动与授权：设备可见性从 0 到 1 的必经之路

接上 Android 设备后，先敲adb devices看状态。常见结果是List of devices attached下面空空如也，或者显示unauthorized。前者说明驱动有问题或 USB 调试没打开，后者说明手机上弹了授权框但你没点允许。

1.0.39 这个版本对老设备的识别比新版更宽松，但 Windows 下的驱动仍然是头号坑。我的做法是：先用设备自带的 USB 驱动装上，装不上再去装通用的 ADB 驱动。部分国产设备连接后会在设备管理器里显示为带黄色感叹号的未知设备，右键更新驱动，手动指向解压目录里的usb_driver文件夹，大概率能解决。

真正让设备“可见”的最后一步是手机上打开开发者选项里的 USB 调试。这一步每个品牌藏得深浅不一，但逻辑一样：设置里连点版本号七次，激活开发者选项，然后打开 USB 调试开关。首次连接时手机弹窗问“是否允许 USB 调试”，勾选“始终允许”，点确定。

提示：如果设备显示unauthorized，说明授权记录被清掉了或者之前误点了拒绝。解决方法是拔掉 USB 线重插，同时撤销 USB 调试授权重来一遍，后面避坑章节会细说。

2.3 验证环境：adb devices 的输出你真的看懂了吗

驱动装好、授权点掉之后，adb devices的输出就是一个分水岭。正常的输出长这样：

List of devices attached ABC12345678 device

device状态代表设备处于正常调试模式，可以收发命令。如果看到offline，问题在后面。如果看到unauthorized，就是授权问题。如果下面完全空白，检查驱动和 USB 数据线——很多时候是线只能充电不能传数据，换根线立刻好。

这一步值得多说两句。很多人习惯一上来就adb shell，结果卡在设备状态上，绕半天没找到原因。我的习惯是：先adb devices确认状态，再adb shell getprop ro.product.model确认拿到的是不是目标设备，然后才开始正式排查。这套前置流程在安全检查场景里尤为重要——你不知道面前这台设备到底是什么型号、什么系统版本，贸然跑命令容易出误判。

3. 核心命令实战：用 adb 看清 Android 设备里发生了什么

3.1 应用层排查：列出可疑包与最近打开的活动

安全检查的第一件事，是搞清设备上装了什么。adb shell pm list packages可以列出所有应用包名，但这个命令输出几百行，排查效率太低。我一般配合grep过滤关键信息：

adb shell pm list packages | grep -i "test\|debug\|unknown"

这条命令会筛选出包名里带 test、debug、unknown 的应用，往往可疑应用都藏在这些命名里。还可以用-3参数只看第三方应用，系统应用全部隐藏：

adb shell pm list packages -3

为什么要区分三方应用和系统应用？因为预置的系统应用一般不太可能是不法应用，但第三方应用来源不明、权限可疑的话，就值得逐个检查。看到可疑包名后，进一步看它的详细信息：

adb shell dumpsys package <包名>

命令里的<包名>换成你怀疑的那个，比如adb shell dumpsys package com.example.suspect。输出里重点看几个字段：versionName版本信息、requested permissions申请了哪些权限、firstInstallTime安装时间。如果某个应用申请了短信、通讯录、定位、录音权限，但它的功能看起来完全用不到这些，基本可以拉高警报了。

3.2 行为层排查：dumpsys 里藏着进程和服务的运行真相

静态的包信息只能说明应用“要了什么权限”，要知道它“正在干什么”，必须看动态行为。dumpsys activity activities能列出当前前台和后台的活动栈，直接暴露最近在跑哪些界面：

adb shell dumpsys activity activities | grep -E "mResumedActivity|topResumedActivity"

输出里的mResumedActivity就是当前屏幕上正在运行的应用。如果它跟用户正在操作的应用对不上，说明可能有界面劫持或者悬浮窗覆盖。

再进一步用dumpsys appops查看应用的实际操作记录，这个命令能告诉你哪个应用在后台偷偷调用了定位、麦克风、摄像头：

adb shell dumpsys appops | grep -E "Camera|Microphone|Location" | head -50

head -50用来限制输出行数，避免刷屏。这条命令的精髓在于它查的不是权限声明，而是真的“用过”的记录。权限声明是申请，操作记录是事实，后者才是定性的关键。我在一次模拟项目X的安全排查里，就是靠这条命令发现某个应用在凌晨时段反复调用麦克风，才追踪到问题。

如果怀疑应用在做网络请求，可以通过下面的命令查看当前所有 TCP 连接：

adb shell cat /proc/net/tcp

这个文件是 Linux 内核的 TCP 连接表，输出的是十六进制格式，需要转换。更直观的方式是用adb shell netstat -tlnp，不过注意部分系统版本对netstat支持有限，/proc/net/tcp反而是通用性最强的。

3.3 数据提取：pull 与备份的轻量取证姿势

排查过程中发现了可疑文件、可疑数据库，需要从设备里取出来分析。adb pull是基础手段：

adb pull /data/data/com.example.suspect/databases/app.db D:\evidence\

命令里的/data/data/<包名>/是 Android 应用私有数据目录，普通文件管理器看不到，但通过 adb 可以取出来。需要注意的是，部分设备上未 root 时无法直接读取/data/data目录，这时可以退而求其次，用adb backup做整机备份：

adb backup -apk -shared -f D:\evidence\backup.ab

-apk表示同时备份应用安装包，-shared备份共享存储，-f指定输出文件路径。备份产出的.ab文件是 Android Backup 格式，需要专门的解析工具提取内部数据。这套组合拳在无法 root 的设备上依然能拿到有效证据，属于安全取证里的常规操作。

如果是需要批量提取文件，建议在电脑上建一个证据目录，每台设备建一个子目录，按设备序列号命名，避免多台设备的数据混在一起。用adb get-serialno获取设备序列号，然后在脚本里动态拼接路径，是我的习惯做法。

4. 无线调试与多设备管理：脱离数据线的排查切换

4.1 开启无线调试：一条命令把排查场景从工位搬到现场

设备不方便一直插着 USB 线的时候，无线调试是救命功能。前提是电脑和设备连接同一个局域网，且网络环境可控。操作极其简单，USB 连接状态下先执行一条命令切换监听端口：

adb tcpip 5555

执行成功后，设备会在 5555 端口监听 adb 连接。此时拔掉 USB 线，在电脑上连接设备的局域网 IP：

adb connect 192.168.1.100:5555

192.168.1.100换成设备实际的局域网 IP，可以在设备的 Wi-Fi 设置里查看。连接成功后再敲adb devices，会看到192.168.1.100:5555 device的条目。

这个场景对做多设备批量排查来说效率提升明显。比如接收一批设备做系统状态确认，不需要挨个插线、授权、敲命令，只要预先通过 USB 完成第一次授权，之后全部走无线通道。省下的时间足够把每条排查命令多跑两遍。

注意：无线调试只适合在可信局域网内使用。adb 的 5555 端口没有任何加密认证，在公网上暴露等于把自己的设备后台拱手送人。排查任务结束后记得执行adb disconnect断开连接。

4.2 多设备并行：-s 参数解决“两只手机抢一个 adb”的冲突

接了多台设备时，直接敲adb shell会报错more than one device。解决方式是用-s参数指定设备序列号或 IP 地址：

adb -s ABC12345678 shell dumpsys battery adb -s 192.168.1.100:5555 shell dumpsys battery

-s后面跟的参数就是adb devices列表里显示的序列号或 IP 端口。批量场景下写个循环脚本是常规操作，在 Windows 上用for循环也能实现，但我在 PowerShell 里用得更多：

$devices = adb devices | Select-String "device$" | ForEach-Object { ($_ -split "\s")[0] } foreach ($d in $devices) { adb -s $d shell getprop ro.product.model }

这段脚本先筛选出状态为device的设备列表，再逐个拉取机型信息。注意第一行adb devices的输出里有表头List of devices attached，Select-String "device$"可以过滤掉表头，只留下真实设备条目。

多设备并行排查时还有个容易忽略的问题：授权。每台设备首次连接都会弹授权框，需要人工点击。批量接设备前，一定要提前把所有设备都授权一遍，否则脚本跑到一半卡在unauthorized状态，你都不知道是哪台掉链子。

4.3 连接状态排查：5037 端口就是 adb 的唯一入口

电脑端的 adb 服务默认监听 5037 端口，所有 adb 命令都通过这个端口与设备通信。排查无线连接问题时，经常遇到“设备列表能看到但连不上”的情况，这时候先检查 5037 端口状态：

netstat -ano | findstr 5037

findstr是 Windows 下的文本过滤工具，等价于 Linux 的grep。如果输出里能看到LISTENING状态的进程，且 PID 是 adb.exe 的进程号，说明服务正常。如果端口被其他程序占用，后面避坑章节会给到具体处理方案。

另外两个高频补救命令值得记一下：

adb kill-server adb start-server

先杀后启，重启 adb 服务。这个组合在遇到连接假死、设备无响应、无线连不上的时候有奇效，成本低、速度快、不破坏已有配置。我几乎每次排查前都会先跑一遍adb kill-server清理状态，避免上次连接的残留问题干扰判断。

5. 避坑指南：adb 1.0.39 在 Windows 上的五个常见翻车点

5.1 设备状态显示 offline，后接任何命令都报错

• 现象：adb devices显示设备序列号但状态是offline，adb shell无法执行。
• 原因：设备端 adbd 服务出现假死，或者 USB 连接不稳定，部分老系统在 adb 1.0.39 版本下容易触发这个问题。
• 解决：先拔掉 USB 线重插，然后执行adb kill-server再adb start-server，重连后看状态。如果仍然 offline，重启设备的 USB 调试开关，或直接重启设备。我的经验是三板斧之后 80% 能恢复，剩下 20% 是数据线本身质量问题，换线解决。

5.2 5037 端口被占用，adb 服务起不来

• 现象：执行adb start-server提示cannot bind to 127.0.0.1:5037。
• 原因：有其他程序抢占了 5037 端口，常见的是一些安卓手机助手类软件或之前异常残留的 adb 进程。
• 解决：用netstat -ano | findstr 5037找到占用端口的 PID，然后打开任务管理器找到对应进程结束掉。如果占用进程是另一个 adb.exe，直接全部结束再重启服务。从那以后，我遇到端口冲突第一反应都是先查进程树，而不是盲目重启电脑。

5.3 驱动显示安装成功，但 adb devices 始终空白

• 现象：设备管理器里没有黄色感叹号，但adb devices就是看不到设备。
• 原因：驱动版本和设备不兼容，或者设备默认的 USB 模式是纯充电模式，没有切换到传输数据模式。
• 解决：在手机上把 USB 连接模式改成“传输文件（MTP）”，部分设备还需要额外开启“USB 调试（安全设置）”里的“允许通过 USB 安装应用”。改完模式后再敲一次adb devices，多数情况能看到设备。如果还不行，手动卸载设备管理器里的 ADB 接口驱动，重装驱动后重启电脑。

5.4 授权弹窗不出现，或出现后误点了拒绝

• 现象：连接了数据线，设备上也打开了 USB 调试，但手机上就是不弹授权框，或者之前误点了“拒绝”，后面再连再也不弹了。
• 原因：设备的授权记录被锁定为拒绝状态，需要手动撤销授权记录。
• 解决：进入开发者选项，找到“撤销 USB 调试授权”，点击后重新连接设备，弹窗会再次出现。这里有一个细节：部分定制系统把“撤销授权”藏在“恢复默认设置”里，找不到就逐项翻找。误点拒绝后如果不撤销，插多少次线都没用，它不会再弹第二次。

5.5 无线调试连接成功，过一会儿自动断开

• 现象：adb connect成功，adb devices里也能看到设备，但过几分钟再敲命令就提示device offline或连不上。
• 原因：设备的 Wi-Fi 休眠策略导致网卡休眠，或局域网 DHCP 地址变动，也有可能是电脑端 adb 服务空闲超时。
• 解决：在设备开发者选项里打开“保持唤醒状态”，充电时屏幕不息屏，同时关闭 Wi-Fi 的休眠策略。还把设备的 IP 地址改成静态分配，避免 DHCP 租约到期换地址导致断连。无线调试适合短时操作，长时间批量任务还是优先走 USB。

6. 进阶验证：用 adb 给设备安全状态做一次十分钟体检

掌握了基础命令和排坑手段后，最后一个技巧是把前面零散的检查项整合成一条完整的体检链路。我的固定流程是四步走，总共不超过十分钟。

第一步，拉取设备关键身份信息：

adb shell getprop ro.product.model adb shell getprop ro.build.version.release adb shell getprop ro.secure

ro.secure的值值得多看两眼，如果为 0 说明 adbd 以 root 权限运行，这在生产设备上属于高风险信号。

第二步，检查当前 TCP/UDP 监听端口：

adb shell cat /proc/net/tcp adb shell cat /proc/net/udp

重点关注是否有本地端口在监听但对应进程是未知应用的情况。

第三步，检查 USB 调试授权列表，确认没有可疑设备获得过调试权限：

adb shell dumpsys usb

这条命令会输出 USB 调试授权状态，看mConnected和调试白名单信息。

第四步，也是最能留下痕迹的一步——记录设备当前状态快照：

adb shell dumpsys package > D:\evidence\package_list.txt adb shell getprop > D:\evidence\device_props.txt

把输出重定向到本地文件，方便后续对比、留档、做基线。之后再做安全复查时，重新生成一份快照，用文本对比工具 diff 一下，新增的应用、变化的系统属性一目了然。这套思路给了我很大帮助——我曾在一次模拟项目X的复查对比中，靠文件差异发现设备上多了一个隐藏系统应用，进而顺藤摸瓜找到了问题源头。

从那以后，我每次排查完设备都会强制生成一份快照留底，不管是单台还是批量设备，统一命名规则、统一存储位置。这不是什么高深技巧，就是多敲一条重定向命令，却在后续追溯时省过无数翻找的功夫。希望你也能把这份习惯带进自己的排查流程里，遇到说不清来路的设备时，先留档再动手，能做到有据可查。希望帮到你。

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