简介adb 1.0.39 Windows 版是一份面向 Android 应用开发者、测试与安全研究人员的命令行工具包用于在电脑与真机或模拟器之间建立调试通道解决设备连接、应用安装卸载、日志抓取与进程控制等日常需求。压缩包共 1716 个文件主体为 adb、fastboot 等 exe 可执行程序及配套 dll 依赖另有大量 html 文档、py 与 js 脚本、css 样式与 json 配置承载 systrace、adb_profile_chrome 等性能采集与可视化组件md、txt 说明与 license、readme 文件则交代版本与使用约定整体约 9.53MB。已有 416 人学习下载。读者可直接获得可用的 Windows 平台工具链并借由附带的 atrace 采样数据、systrace 模板与性能分析脚本理解无线连接、logcat 实时日志、备份恢复与模拟输入等操作背后的实现细节适合需要在真实设备上排查问题、做自动化测试或搭建调试环境的中级开发者查阅。1. adb 1.0.39 Windows 版一个不肯退休的调试桥adb 1.0.39 Windows 版这几个字在很多人的移动硬盘里对应的是 2016 年前后的一份 platform-tools 快照——压缩包解开只有adb.exe、两个AdbWin*.dll、fastboot.exe和一份说明文件。它没有adb pair不会自己发现网络里的设备甚至在某些新系统上会提示一堆看不懂的协议错误但在 USB 直连的老测试机上做 Android 安全自查——确认应用是不是 debuggable、导出组件有没有裸奔、备份策略是不是形同虚设——它依然够用而且行为稳定到可以写进脚本。某实验室的回归测试机跑的就是这套东西理由很简单换版本要重跑一遍全部用例收益却只是多几个用不上的子命令。这篇笔记按“这份包是什么、怎么在 Windows 上落地、怎么用它读出可核对的安全清单、哪里会翻车”四段推进适合手上一批不再升级的测试机、又需要把工具版本钉死的从业者。2. 拆包看结构三个进程、两个 DLL 和一次版本取舍2.1 client、server、adbd一条链路上其实有三个程序很多人把 adb 当成一个整体出问题时就会乱试。实际上敲下adb devices之后发生的事是分层的命令行里跑的是 client它只在几毫秒内活着client 发现本地 5037 端口没有服务就拉起一个常驻的 server真正跟手机对话的是设备固件里自带的 adbdPC 端的版本完全管不到它。这个分层决定了一件关键的事——PC 端用 1.0.39 去连一台 2020 年以后出厂的手机adb devices、adb shell、adb pull这些基础能力大概率仍然可用因为 client 与 adbd 之间的传输协议多年没动过缺的只是后来新增的子命令和对新特性的支持。我习惯在动手前先确认这条链路的三个节点是不是只有一份。Windows 上最常见的翻车不是设备坏了而是机器里躺着三份不同版本的 adb.exe谁先被PATH找到就用谁结果 server 一会儿是这个版本、一会儿是那个版本。# 确认 server 是否在跑、占的是哪个端口 adb start-server netstat -ano | findstr 5037 # 打印版本1.0.39 的输出里会明确写 Android Debug Bridge version 1.0.39 adb version第一行是幂等的server 已在跑时什么也不做第二行在 Windows 上查 5037 的监听进程输出最后一列是 PID配合tasklist /FI PID eq pid就能知道是哪个程序在占坑第三行除了看客户端版本也顺带确认二进制本身没坏——如果它直接报错而不是打印版本号问题就落在下一节的 DLL 上。2.2 AdbWinApi.dll 与 AdbWinUsbApi.dll缺一个就打不开这两个文件是 Windows 独有的一层胶水。AdbWinApi.dll负责 USB 设备的枚举和描述符读取AdbWinUsbApi.dll是 WinUSB 后端负责真正搬运数据。它们必须和adb.exe待在同一目录而且是配套的——用新版的 DLL 去配旧版的 exe运气好只是连不上设备运气差直接弹0xc000007b。我见过最典型的错误是把adb.exe单独复制进C:\Windows\System32觉得这样随处可用结果每次调用都提示“计算机中丢失 AdbWinApi.dll”。文件作用缺失或错配时的表现adb.execlient server 二合一命令不存在where adb找不到AdbWinApi.dllUSB 枚举、设备描述符启动即报“丢失 AdbWinApi.dll”AdbWinUsbApi.dllWinUSB 数据通道能启动但adb devices永远空fastboot.exe刷机模式下的另一套协议与 adb 无关可单独保留判断方法很朴素where adb找到路径之后直接看那个目录里有没有这两个 DLL。没有就是包没解全或者被安全软件悄悄隔离了——这种情况在离线内网机器上尤其常见隔离之后没有任何提示只觉得“adb 装了但不работает”。实际判断还是看目录别猜。2.3 什么情况下该留 1.0.39什么情况下必须换掉把版本选择讲成“新旧之争”没有意义正确的问法是你的工作流依赖的是协议还是特性。依赖协议连接、shell、pull/push、install、logcat的1.0.39 足够依赖特性无线配对、增量安装、mDNS 发现的就必须换。能力adb 1.0.39后续版本USB 连接、shell、文件传输支持支持adb backup整包备份支持但多数场景产出空包同样受限无线调试配对配对码方式不支持支持局域网设备自动发现不支持支持增量安装不支持支持老设备与旧驱动兼容性好一般与老脚本的输出格式兼容好有变化风险所以我的取舍是做授权范围内的安全自查、跑在固定测试机上、脚本输出要能逐年对比的留 1.0.39需要连 Android 11 以后的无线调试、或者 CI 里跑增量安装的直接换新。这里没有任何“安全性差异”的考量——adb 本身这几年的改动集中在功能不在于修补漏洞把老版本说成“不安全”是吓唬人把新版本说成“一定更好”也不成立版本选错带来的时间成本远大于收益。还有一条边界值得提前说清楚Android 11 之后很多机型默认关闭了“USB 调试安全设置”无线调试必须走配对码流程而配对是 client 侧的能力1.0.39 里根本没有这个子命令。遇到这种机器正确做法是先用 USB 连一次、adb tcpip 5555把 adbd 切到网络模式再adb connect。这条路在 1.0.39 上是通的因为它复用的还是老协议。3. Windows 落地把 adb devices 从黄色感叹号跑到 device 状态3.1 目录规划与 PATH让机器里只剩一个 adb第一步不是插手机是清理环境。把包解到一个固定路径比如D:\tools\platform-tools-1.0.39路径里不要有中文和特殊符号——空格本身在现代 Windows 上问题不大但一堆老脚本没给变量加引号遇到空格就断。然后把这个目录加到用户级PATH的最前面注意是“最前面”否则它会输给 IDE 自带的 adb。# 把 1.0.39 放到 PATH 最前面只影响当前会话确认无误再写进用户环境变量 $env:Path D:\tools\platform-tools-1.0.39; $env:Path # 验证应当只输出一行且指向刚才那个目录 where.exe adb # 确认版本与 DLL 都在 adb version Get-ChildItem D:\tools\platform-tools-1.0.39 -Filter AdbWin*.dllwhere.exe会列出所有命中项如果输出两行以上说明机器里还有别的 adb要么删、要么改名成adb.bak别留着当备胎——备胎就是下一次版本错配的源头。第三行的版本输出是后续所有排错的基准出问题时第一句话应该是“版本是多少”而不是“连不上”。持久化写进环境变量时我一般用图形界面改完必须新开一个终端才生效很多人改完在旧窗口里反复试得出“改了没用”的结论。这一步的血泪经验是改环境变量之后先跑where adb跑通了再插设备。3.2 驱动与授权黄色感叹号、unauthorized 与 adbkey设备侧先做三件事打开开发者选项、打开 USB 调试、把 USB 连接模式从“仅充电”改成“传输文件”。第三件最容易被忽略——部分机型在仅充电模式下根本不暴露 adb 接口插上去只会充电设备管理器里干干净净让人以为线坏了。PC 侧的判断点在设备管理器。插上手机后看有没有出现带黄色感叹号的未知设备或者一个叫ADB Interface的条目。有感叹号就是驱动问题装厂商驱动或者手动指定 WinUSB没有感叹号但adb devices里是空的多半是线或者口的问题换 USB 2.0 口试一次往往就好了这个玄学在 USB 3.x 控制器上至今有效。# 彻底重启一次服务端避免旧 server 缓存了错误的设备状态 adb kill-server adb start-server # -l 会带出设备型号与传输方式老版本若不认这个参数就去掉 adb devices -l # 首次连接会弹 RSA 指纹勾选一律允许后应看到 device 而不是 unauthorizedkill-server之后再start-server是为了让 server 重新枚举 USB很多“明明插着却看不到设备”的情况到这一步就恢复了。adb devices -l的-l是 long 模式多输出 product、model、device 三列方便在多台机器里认出目标如果 1.0.39 对这个参数报错直接去掉不影响主流程。授权状态有四种含义完全不同device是正常unauthorized是设备端没确认指纹offline是 adbd 起来了但握手失败通常要重新插拔no permissions在 Windows 上少见基本等于驱动没装对。授权记录存在%USERPROFILE%\.android\下的adbkey和adbkey.pub反复弹窗又确认不掉的时候把这个目录里的两个文件删掉、kill-server再插一次比任何教程都好使。注意这会清掉所有已授权设备共用机器上要提前打招呼。3.3 多设备与串号-s 与环境变量测试架上同时挂三四台机器是常态这时任何一条 adb 命令都会报more than one device/emulator然后什么都不做。解决办法是显式指定串号串号就是adb devices第一列那串字符。# 指定设备执行串号从 adb devices 第一列取 adb -s 0123456789ABCDEF shell getprop ro.product.model # 整段脚本只对一台机器生效时用环境变量更省事 set ANDROID_SERIAL0123456789ABCDEF adb shell getprop ro.build.version.release-s是逐条指定写起来啰嗦但不会误伤ANDROID_SERIAL是会话级默认值一次设置后续所有命令都跟着走适合把一组检查串成批处理。我一般在批处理开头设环境变量中间需要临时切机时再用-s覆盖两种方式混用不会有冲突因为命令行参数的优先级更高。4. 读设备状态包、组件、备份、日志四条取证线这一章是整份包真正的价值所在。adb 1.0.39 的命令集不大但足够把一台设备上的应用安全姿态读成一份可核对、可存档、可 diff 的清单。前提是知道每条命令读的是哪一层、输出里哪些字段才是结论。4.1 包清单四个过滤器把设备分成几堆pm list packages是最基础的一条但只用裸命令等于没查。四个过滤器组合起来才能看出问题-3只列第三方、-s只列系统、-d只列被禁用的、-e只列启用的。做自查时我通常先看“被禁用的系统应用”因为那是厂商预装被停用的部分往往还留着组件出口再看“第三方包里带 test 字样的”那是历史遗留的测试包常年没人维护。# 第三方应用按包名排序方便两次结果对比 adb shell pm list packages -3 | sort # 被禁用的包这里面常有不该存在的预装残留 adb shell pm list packages -d # 单个包的详情权限、签名摘要、安装来源都在这里 adb shell dumpsys package com.demo.apppm list packages的输出格式是固定的package:包名所以sort之后可以直接和上一次的结果做文本比对新增一个包就是新增一个风险面。dumpsys package的输出很长直接在终端里看会刷屏正确姿势是重定向到文件再过滤下一节展开。需要提醒的是-d和-e是互斥状态同一时刻一个包只会在其中一边如果某个包两边都出现说明中间有安装或禁用操作正在发生重新跑一次即可。这种小概率抖动在频繁装卸的测试机上很常见别急着下结论。4.2 组件导出从 dumpsys 里挑出 exportedtrue应用被外部拉起的入口只有那么几类带 intent-filter 的 Activity、Service、BroadcastReceiver、ContentProvider。它们是否对外可达取决于android:exported而这个值在dumpsys package的输出里是明文的。自查的逻辑很直接——导出了、又没有permission保护的组件就是这个应用暴露给全设备的攻击面。# 把整包信息落到文件避免在终端里翻页 adb shell dumpsys package com.demo.app dump_demo.txt # Windows 侧过滤只留导出相关行和上下文 findstr /i /n exported permission dump_demo.txt第一步重定向发生在 PC 端dumpsys的输出原样落到本地文件编码不会出问题。第二步用findstr在 PC 侧过滤/i忽略大小写/n带行号——行号很关键因为exportedtrue和它所属的组件名往往隔着好几行没有行号就得靠肉眼回溯。看到exportedtrue之后往上找最近的组件声明行往下找有没有permission两个都确认了才算判断完整。这里有个容易误判的点exportedtrue但声明了android:permission且该权限是 signature 级的实际外部应用也进不来属于“看起来危险、实际安全”。反过来exportedfalse的组件如果所在进程被同签名的应用共享也未必绝对隔离。所以结论要写成“导出且无保护”不要写成“导出了所以有问题”。4.3 调试与备份debuggable、allowBackup 怎么实证android:debuggabletrue是自查里优先级最高的一个标志因为一旦为真任何拿到设备的人都能用run-as直接读应用私有目录。实证方法比读清单更可靠直接试着进去。# 能进去并打印 uid说明 debuggable 为真 adb shell run-as com.demo.app id # 从 dumpsys 里再确认一次标志位作为交叉验证 adb shell dumpsys package com.demo.app | findstr /i flagsrun-as在非 debuggable 的应用上会直接返回package not debuggable这个报错就是结论不需要再查别的。第二条命令里的flags行会列出DEBUGGABLE、SYSTEM、STOPPED等标志两个结果对得上才算证据链闭合。备份这一条要格外小心。adb backup在 1.0.39 上是存在的但 Android 9 之后绝大多数应用已经无法通过这条路径导出数据命令会“成功”返回产出的文件只有一千字节左右本质是个空壳。# -f 指定输出文件-apk 表示连安装包一起打包多数场景不需要 adb backup -f demo.ab com.demo.app # 看文件大小1KB 上下基本等于空包不能据此判断 allowBackup dir demo.ab所以判断allowBackup主要依据还是清单和dumpsys里的信息adb backup只作为一种辅助验证包体明显大于空壳才有讨论价值。把“备份失败”直接等同于“配置正确”是这类自查里最常见的错误结论之一。4.4 日志与截图logcat 过滤与二进制重定向的坑自查过程需要留证日志和截图是最直观的两类。logcat的关键是先把缓冲区清掉再复现否则拿到的是一堆历史噪声。# 清空缓冲区再按优先级过滤只留 W 以上 adb logcat -c adb logcat -v threadtime *:W # 截图走“先落盘再拉取”比直接重定向稳 adb shell screencap -p /sdcard/shot.png adb pull /sdcard/shot.png ./shot.png-c清空缓冲-v threadtime换成带线程和时间戳的格式方便和操作时间对齐*:W表示所有 tag 只输出 Warning 及以上噪声会少一个数量级。截图用两步走的原因是 Windows 的 PowerShell 在重定向时会做编码转换直接adb exec-out screencap -p shot.png拿到的图大概率打不开——文件头就被改坏了。这个坑我在第一次做取证的时候就踩过打开是一张全黑图排查了半天以为是设备问题。5. 避坑记录端口冲突、版本错配与二进制重定向的五次翻车5.1 连接层列表为空和命令卡死坑一adb devices一直空start-server卡住不返回。现象是命令敲下去光标一直闪等三十秒也没输出CtrlC 才退出。原因是 5037 端口被别的程序占了最常见的是各类手机助手、模拟器和某些 IDE 的后台服务它们内置了自己的 adb server 并且先启动了。解决办法是先定位再处理netstat -ano | findstr 5037 tasklist /FI PID eq 12345第一列输出最后一组数字是 PID第二行拿 PID 换进程名。确认是无关程序就关掉确实是工作需要的就改成“先启动 1.0.39 的 server 再启动它”谁先占坑谁说了算。这类冲突不会自己消失每台新机器都要查一遍。坑二设备管理器里有ADB Interface但状态是感叹号。现象是驱动装了一半设备能被系统识别却拿不到数据通道。原因是 Windows 给这个接口绑了错误的驱动可能是厂商的 MTP 驱动抢先匹配了。解决是在设备管理器里右键 → 更新驱动 → 从列表中选择 → 选 WinUSB 或厂商提供的 ADB 驱动装完拔插一次。别信那些让你去改注册表adb_usb.ini的老教程那套机制在 1.0.39 这个年代已经不生效了改了只会让问题更复杂。5.2 版本层server 与 client 对不上坑三报adb server version (xx) doesnt match this client (39)。现象是命令能跑但行为诡异偶尔报错偶尔又正常。原因是机器里有两份不同版本的 adbA 启动了 serverB 作为 client 连上去发现协议版本不一致于是尝试杀掉旧 server 重启自己的——如果旧 server 正被 IDE 用着IDE 那边就断了。解决顺序是where adb找出全部实例把非目标版本改名或删除adb kill-server再用目标版本start-server。我现在的习惯是把所有 IDE 里的 adb 路径都显式指向同一个目录宁可多配一次也不留给下一次玄学。5.3 输出与授权PNG 打不开、unauthorized 反复出现坑四截图重定向出来的 PNG 打不开。现象是文件生成了大小也对双击提示损坏。原因是 PowerShell 的会把字节流当文本处理插入 BOM 并转换换行。解决是改用“设备端落盘 adb pull”或者在 cmd 里用再或者用adb exec-out该子命令在老版本上是否可用需实测不可用就走落盘这条路。坑五授权弹窗点了允许下次插上还是unauthorized。现象是每次连接都要重新确认甚至确认了也不生效。原因通常是%USERPROFILE%\.android\下的adbkey权限异常或者被安全软件拦了写入也可能是换了 USB 口导致设备指纹变了。解决办法是删掉adbkey与adbkey.pubadb kill-server重新插拔并在弹窗里勾选“一律允许”。如果仍然反复检查该目录是不是只读或者被同步盘占用。这五个坑的共同点是报错信息都不指向真正的原因。所以排错顺序应该固定下来——先where adb确认版本唯一再netstat确认端口再adb devices -l确认状态最后才怀疑设备和线。把顺序固定住比记住一百条命令有用。6. 进阶固化把一次自查写成可 diff 的批处理单次手工检查的价值有限真正的价值在于“同一套检查跑两次能看出差异”。我一般会在测试机上放一个批处理把四条线的输出各自落到独立文件命名带日期跑完直接和上一次比。echo off setlocal set ADBadb set OUTout_%1 if %1 set OUTout_today mkdir %OUT% 2nul %ADB% devices -l %OUT%\01_devices.txt %ADB% shell getprop %OUT%\02_props.txt %ADB% shell pm list packages -3 | sort %OUT%\03_pkg3.txt %ADB% shell pm list packages -d %OUT%\04_disabled.txt %ADB% shell dumpsys package %OUT%\05_dump.txt echo done: %OUT%第一个参数是批次名不传就用默认值这样同一台机器可以保留多份快照。mkdir ... 2nul是为了让目录已存在时不报错Windows 批处理里2nul的作用就是把这类无关错误吞掉。五份输出的用途各不相同01看设备是否还是同一台02看系统版本和安全属性有没有被改过03看有没有新装的第三方包04看被禁用的组件有没有变化05是原始底料留给findstr做二次过滤。比对用系统自带的fc就够不用装任何东西fc /n out_0101\03_pkg3.txt out_0202\03_pkg3.txt/n会带行号输出差异一眼能看出多了哪个包、少了哪个包。我通常固定比对03和04两份前者对应“新装了什么”后者对应“什么被停用了”这两类变化最能说明设备被动过。有一处细节值得写进脚本注释out_%1里的日期别用%date%拼不同区域设置下格式不一样2024/01/05和01/05/2024会拼出带斜杠的路径直接失败。用批次名传参是最省心的做法谁跑谁负责命名。那次把dumpsys package直接甩进终端、滚了三屏才发现关键行在上面、回头又滚不回去之后我养成了一个习惯任何输出超过一屏的 adb 命令一律先重定向到文件再用带行号的过滤去看。这个习惯救过我很多次也让每次自查的结论都能被别人复核。希望帮到你。本文还有配套的精品资源点击获取