企业官网建设流程全解析

简介：adb 1.0.39 Windows 版工具包面向 Android 开发、测试与安全分析人员，提供在 Windows 上连接和管理真机或模拟器的命令行环境，可用于设备调试、文件传输、日志抓取、应用安装卸载、shell 操作与自动化测试等场景。压缩包共 1716 个文件，约 9.53MB，除 adb、fastboot 相关 exe/dll 可执行组件外，还包含大量 html 文档、py 分析脚本、js/css 前端资源、md 说明、json 配置及测试脚本，并附带 systrace/atrace 性能采样与 Chrome 性能剖析相关材料，便于排查启动耗时和系统调用问题。已有 416 人学习下载。其价值在于把设备管理、日志分析、性能采集和脚本化测试所需的工具与参考材料集中在一处，读者可据此搭建 Windows 调试环境，理解 platform-tools 的目录组织，并借助示例脚本与文档快速定位连接、驱动、日志及性能问题，适合需要查漏补缺的中级开发者与安全测试人员。

1. 一个版本号引出的麻烦：adb 1.0.39 windows版 值得单独装一遍

某开发者接了个活，要在测试机上做 android 安全评估的前期摸底，拿到手的就是一个 adb 1.0.39 windows版 的压缩包。解压、敲adb devices，屏幕一直挂着 unauthorized。换线、换口、重启手机，折腾一下午才发现问题并不在手机上：PATH 里排在前面的 adb.exe 是别的工具自带的，版本对不上，两个 server 抢同一个 5037 端口。

adb 本身只有一个 exe 加两个 dll，看起来最没有安装成本，实际却是少数几个把状态藏在后台、依赖藏在驱动层、还特别怕多版本共存的命令行工具。装得干净，一条命令就出序列号；装得脏，offline、unauthorized、server version doesn't match 会轮着来。android 安全评估这类活儿要反复开关调试、反复抓日志、反复装包卸包，设备连不稳，后面全是空谈。下面按装前核对、落地安装、参数配置、翻车排查、装完验收的顺序走一遍。

2. 装前把账算清：adb 1.0.39 的版本定位与 Windows 依赖清单

动手解压之前，有三件事必须先确认：这个版本号对应哪一代 platform-tools、Windows 这边缺什么运行库和驱动、以及准备放在哪个目录。这三件事里任何一件没想清楚，后面都会以“玄学问题”的形式回来找你。

2.1 先认版本：1.0.39 属于哪一代 platform-tools

很多人以为adb version输出的就是 platform-tools 的版本，其实两者不是一套编号。platform-tools 是按 28.0.x、30.0.x、33.0.x 这样递进的，里面包的 adb 才是 1.0.39、1.0.41 这种。1.0.39 大致出现在 platform-tools 28.0.x 那一批里，年头不短，adb version会打两行：

adb version # Android Debug Bridge version 1.0.39 # Version <commit-id>-android

第二行的 commit 号每次构建都不同，不用纠结。真正要记的是这个版本“会什么、不会什么”，因为 android 安全评估里有些操作是要靠新子命令撑起来的：

所以选型逻辑很简单：如果你手里是 USB 连着的老设备、板卡、或者某个脚本明确锁定了这个版本的行为，1.0.39 够用而且稳；如果你想用同一套命令覆盖新机器上的无线调试，那 1.0.39 会让你在adb pair这一步直接卡死，因为这条子命令根本不存在。我一般的做法是两套并存，一旧一新放在不同目录，靠 PATH 顺序切换，绝不把两个 adb.exe 混进同一个文件夹。

提示：判断当前用的是哪一份，永远用where.exe adb（PowerShell 里必须写全.exe，否则会被解析成 Where-Object 别名），而不是凭印象。

2.2 Windows 侧的前置条件：系统、运行库、驱动

Windows 10/11 的 x64 版本基本开箱即用，32 位系统要留意AdbWinApi.dll的位数是否匹配，位数不对的典型报错是“无法启动此程序，因为计算机中丢失 AdbWinApi.dll”，看着像缺文件，其实是加载失败。运行库方面，adb.exe对 VC++ 运行库有依赖，常见做法是先装一遍 VC++ 2015-2022 运行库合集，省得后面排查时多一个变量。

驱动是 Windows 上最容易翻车的一环。Win10 之后系统自带的通用 ADB 接口驱动有时候能直接把设备认出来，设备管理器里会显示成一个正常的 ADB 设备；认不出来的时候会挂在“其他设备”下面带黄色感叹号，或者只被识别成 MTP 传输设备。这时候adb devices会是空的，很多人以为是端口问题，其实是驱动没装。处理顺序是：先在设备上把开发者选项和 USB 调试打开，插上线看设备管理器有没有变化；没变化就换一根能传数据的线（很多随机附带的线只供电）、换一个 USB 口（优先主板后置的 USB 2.0 口）；还不行就装设备厂商提供的 USB 驱动，让设备管理器手动指向驱动目录。

设备侧还有两个开关值得提前说明：一个是“USB 调试”，另一个是部分定制系统里藏得更深的“USB 调试（安全设置）”，后者不开，模拟点击、安装应用这类操作会被拦。这两项在 android 安全评估场景里是常规操作，但前提永远是你对这台设备有明确授权，只在自己的测试机或客户书面许可的设备上开。

2.3 目录规划：别把 adb 丢进 Program Files

目录这件事，装之前五分钟想清楚，能省后面五小时。三个硬性要求：路径不能有空格、不能有中文、不要放在需要管理员权限才能写的目录下。

我习惯固定用D:\dev\platform-tools，把所有版本相关的工具都收在D:\dev下面。这样将来要同时放一份新版，就是D:\dev\platform-tools-new，切换时只改 PATH 顺序，不动文件。另外提一句杀软：adb.exe因为要做端口监听和进程注入类操作，偶尔会被启发式规则误杀，解压后被隔离的话，加个目录白名单比关防护靠谱。

3. 安装落地：解压、进 PATH、跑通第一条 adb devices

前面把账算清了，这一章全是手上的动作。整条链路是三段：文件放对位置、PATH 指对目录、server 起得来且设备认得出。任何一段断了，表现都是“adb 命令没反应”，但原因完全不同，所以要一段一段验。

3.1 解压与文件清单核对

拿到压缩包先解压到 2.3 定好的目录，然后核对文件。一份完整的 Windows 版最少要有这四个：

解压后先别急着配 PATH，直接在当前目录开一个终端跑一次：

# 在解压目录里直接执行，先排除「文件本身有问题」这个变量 cd D:\dev\platform-tools .\adb.exe version

能打出Android Debug Bridge version 1.0.39就说明文件是完整的、运行库也不缺。这一步失败就别往下走了，先解决 dll 和位数问题。这里有个小细节：PowerShell 里执行当前目录的程序必须写.\adb.exe，只写adb会去 PATH 里找，容易误命中别的版本，反而看不出问题。

3.2 环境变量：为什么我不推荐 setx

PATH 配置是这篇文章里最容易留下后遗症的一步。网上流传最广的写法是setx PATH "%PATH%;D:\dev\platform-tools"，这条命令有两个坑：一是它会把当前 PATH 展开后整体写入，用户变量和系统变量混在一起，写进去的内容可能翻倍；二是setx对值的长度有上限，PATH 长到一定程度会被截断，截断之后别的软件命令全部消失，症状是“装完 adb，Python 和 Node 都不能用了”。

我一般用 PowerShell 直接操作“当前用户”的环境变量，只追加、不覆盖、不动系统级：

# 把 adb 目录追加到「当前用户」的 PATH，已存在则跳过 $adbDir = 'D:\dev\platform-tools' $userPath = [Environment]::GetEnvironmentVariable('Path', 'User') if (($userPath -split ';') -notcontains $adbDir) { [Environment]::SetEnvironmentVariable('Path', "$userPath;$adbDir", 'User') Write-Host "已追加到用户 PATH：$adbDir" } else { Write-Host "PATH 中已存在，跳过" }

逻辑说明：GetEnvironmentVariable('Path','User')只读用户级变量，不会把系统级那一大串拖进来；-split ';' -notcontains做的是精确匹配，避免重复追加导致 PATH 越来越长；SetEnvironmentVariable(...,'User')不需要管理员权限，也不会影响机器上其他账户。

参数取舍上，用户变量和系统变量怎么选：单人使用的开发机，一律用用户变量，好处是不需要提权、出问题只影响自己、后续排查范围小；如果是共享的构建机、需要给多个账户用，才考虑写系统变量，但那种情况下更稳的做法是写一个setenv.bat在构建脚本里显式调用，而不是改全局。

改完之后必须重开一个终端窗口，旧窗口不会刷新环境变量，这是另一条血泪经验：

# 新开窗口执行，确认命中的是哪一份 adb where.exe adb # 期望输出：D:\dev\platform-tools\adb.exe

如果where.exe adb打出多行，说明机器上还有别的 adb，顺序就是 PATH 里的顺序。这时候先别管，第 5 章会专门处理多版本打架的问题。

3.3 启动 server 并完成首次授权

adb 的架构是客户端-服务端一体的：你敲的每条adb命令其实是个客户端，它去连本机 5037 端口上的 server 进程，server 再去连设备。所以“命令没反应”经常是 server 那一层的事。

# 先杀掉可能残留的旧 server，再显式启动一个新的 adb kill-server adb start-server # 启动成功会输出：* daemon started successfully # 列出设备，-l 会带上型号和传输方式，信息更全 adb devices -l

第一次连设备时，手机上会弹一个“允许 USB 调试吗”的对话框，勾选“一律允许”再确定。这个授权的凭据存在两个地方：电脑侧在%USERPROFILE%\.android\adbkey和adbkey.pub，设备侧记在系统的授权列表里。两边对不上，就会一直 unauthorized。

# 看一眼密钥目录里有什么，正常情况下应该有 adbkey 和 adbkey.pub explorer "$env:USERPROFILE\.android"

如果adb devices -l输出的状态是device，这一章就算过了，可以进第 4 章做配置。如果输出是unauthorized、offline或者干脆空白，先别改任何配置，直接跳到第 5 章对照排查，因为这三类现象对应的原因完全是三个方向。

4. 参数与配置：让 adb 1.0.39 在 android 安全评估场景下稳定干活

装通只是及格线。真正天天用的时候，痛点会变成：每次换机器都要重新点授权弹窗、接了多台设备每条命令都要加-s、日志抓一半终端被占住、以及安全评估时需要的那批只读查询命令记不住。这一章把这些固定下来。

4.1 adbkey 与授权白名单：处理好那个反复弹窗

%USERPROFILE%\.android\这个目录是 adb 的用户级配置目录，除了密钥，还可能有adb_usb.ini（厂商 VID 白名单，老设备才需要）。adbkey是私钥，adbkey.pub是公钥，设备侧存的是公钥。

常见的省事做法是把adbkey和adbkey.pub拷到另一台机器的同一位置，这样换电脑不用重新点授权。这个做法在个人测试机上没问题，但在团队环境里要慎重：私钥等同于这台机器对设备的调试身份，拷来拷去等于把身份散出去了。我一般的处理是每台机器自己生成，需要批量授权时统一走一条命令重来一遍。

# 授权状态异常时的标准重置动作：删密钥 -> 重启 server -> 重新插线授权 adb kill-server Remove-Item "$env:USERPROFILE\.android\adbkey","$env:USERPROFILE\.android\adbkey.pub" -ErrorAction SilentlyContinue adb start-server adb devices

逻辑说明：删掉本地密钥后，server 会重新生成一对新的，设备侧的旧公钥失效，所以下次插线一定会重新弹窗，这比在设置里一层层找“撤销 USB 调试授权”快得多。-ErrorAction SilentlyContinue是给第一次使用、文件本来就不存在的情况留的余地。

注意：删密钥会清掉这台机器对所有设备的授权记录，如果同时还连着别的测试机，需要一起重新授权。

4.2 环境变量与多设备：把常用参数固化下来

adb 认几个环境变量，用好了能省掉大量重复参数。1.0.39 这个版本对下面这几个都支持：

ANDROID_SERIAL是最值得立刻用起来的一个。接了模拟器和真机之后，adb install、adb logcat全都会报more than one device/emulator，每次加-s又容易写错序列号：

# 只在当前终端会话生效，换窗口就失效，适合临时切换 $env:ANDROID_SERIAL = "ABCDEF1234567890" adb shell getprop ro.product.model # 需要长期固定的话，用用户级环境变量 [Environment]::SetEnvironmentVariable('ANDROID_SERIAL', 'ABCDEF1234567890', 'User')

逻辑说明：序列号用adb devices第一列的内容，长度和格式各机型不同，别凭记忆敲。把变量设成会话级还是用户级，取决于这台机器是不是专用测试机——专用机就固化，共用机就临时设，用完Remove-Item Env:\ANDROID_SERIAL清掉，避免下次连错设备。

ADB_SERVER_SOCKET属于救急手段。5037 被手机助手类工具或模拟器后台进程占住时，adb start-server可能静默失败，这时可以换个端口让 adb 自成一套：

# 让 adb server 监听 5038，绕开 5037 的占用 $env:ADB_SERVER_SOCKET = "tcp:localhost:5038" adb kill-server adb start-server adb devices

注意这个变量必须让客户端和 server 看到同一份值，所以要么在同一个终端里设完再启 server，要么写进用户环境变量。只给客户端设、server 还是老端口，表现是命令一直超时。

4.3 安全评估常用的只读命令组合

android 安全评估的前期摸底，大部分动作其实是只读查询：这台设备的构建类型是什么、有没有全局可调试、装了哪些第三方应用、目标应用的调试开关和备份开关是什么状态。这些用 adb 1.0.39 全都能做，而且不改动设备。

# 1) 设备构建属性：判断这是工程机还是量产机 adb shell getprop ro.build.type # user / userdebug / eng adb shell getprop ro.debuggable # 1 表示全局可调试 adb shell getprop ro.secure # 0 表示 adbd 以 root 权限运行 # 2) 列第三方应用，圈定评估范围 adb shell pm list packages -3 # 3) 看目标应用的调试与备份标记 adb shell dumpsys package com.demo.app | grep -iE "debuggable|allowBackup"

参数说明：-3只列第三方应用，系统应用那几百个包没必要每次都刷屏；dumpsys package <包名>输出该应用的完整状态，其中flags段会带DEBUGGABLE、应用信息里会有allowBackup，这两项是评估时最先看的。Windows 下没有 grep，用 PowerShell 的Select-String等价替换：

# 同一条查询的 PowerShell 写法 adb shell dumpsys package com.demo.app | Select-String -Pattern "debuggable|allowBackup"

抓日志也是高频动作，但adb logcat默认会一直挂着终端，很容易把整个会话占死：

# -d 抓完即退出，-v threadtime 带时间戳和线程，-s 只保留指定 tag adb logcat -d -v threadtime -s ActivityManager:E > am.log

-d是关键参数，表示 dump 完就返回，适合脚本化和一次性的问题复现；-v threadtime的输出格式在事后对时间线时比 brief 格式好用得多；-s后面跟tag:级别，能把无关日志直接过滤掉，减少后续肉眼筛查的量。这一整套命令的前提始终没变：设备是自己的，或者有明确书面授权。

5. 避坑排查：adb 1.0.39 在 Windows 上五个高频翻车现场

adb 的报错信息普遍偏“黑匣子”，同一句device not found可能是驱动、可能是线、也可能是端口。这一章按现象、原因、解决三段式记五条踩过的坑，遇到问题先对号入座，别一上来就重装。

5.1 连不上、认不出、授权反复弹：设备侧三条

坑一：adb devices一直显示 unauthorized，手机上却不弹授权框。

现象是设备列出来了，但状态卡在 unauthorized，删 key、重启 server 都不弹窗。原因通常有两个：一是之前点过“一律允许”之后又在系统里撤销了，但设备侧的授权记录没清干净；二是部分定制系统把 USB 调试拆成了两个开关，“USB 调试”开了、“USB 调试（安全设置）”没开，弹窗逻辑就不完整。解决办法是按顺序来：先在开发者选项里点“撤销 USB 调试授权”，再删本地adbkey、重启 server、重新插拔线；还不行就去开发者选项里把两个调试开关都打开，然后把 USB 连接模式从“仅充电”切到“文件传输”，很多机器只在文件传输模式下才走完整的 ADB 授权流程。

坑二：设备管理器里带黄色感叹号，adb devices空白。

现象是插上线毫无反应，命令行什么都不输出。原因是 Windows 没找到匹配的 ADB 接口驱动，设备被当成未知设备挂着，这时候 adb 根本没有可用通道，查端口、查 PATH 全是白费。解决顺序：换一根确定能传数据的线，换主板后置 USB 口；打开设备管理器看有没有带感叹号的条目；有的话右键更新驱动，手动指向设备厂商提供的 USB 驱动目录；实在找不到驱动，先装一遍通用 ADB 驱动再试。判断有没有救回来的标准很简单——设备管理器里出现正常的 ADB 设备条目，再去跑adb devices。

坑三：设备列出来了，但状态是 offline，kill-server 之后又变回 offline。

现象很迷惑：设备在，序列号也在，就是连不上 shell。原因多半是 server 和设备端的 adbd 版本或状态不同步，常见于频繁插拔、设备端 adbd 被系统休眠策略挂起、或者上一次调试会话异常中断。解决办法是先在设备上关掉再打开一次 USB 调试开关，然后在电脑侧adb kill-server再adb start-server；仍然 offline 就换口换线排除物理层，最后手段是重启设备。我遇到过一台机器必须“先拔线、再关调试、再开调试、最后插线”这个顺序才认，属于设备固件的怪癖，记下来就好，不用深究。

5.2 server 起不来、PATH 被写坏：系统侧两条

坑四：报adb server version (39) doesn't match this client (41); killing...然后无限循环。

现象是每条 adb 命令都先打一行版本不匹配，把 server 杀掉重启，然后又提示连不上。原因很明确：机器上存在多份 adb，客户端是一份、后台已经跑起来的 server 是另一份。典型的共犯是 IDE 自带的 adb、模拟器自带的 adb、以及某些手机助手类工具，它们会在后台自己拉一个 server，端口就是 5037。解决分三步：where.exe adb看当前命中的是哪份；全盘搜一遍adb.exe把清单列出来；把不需要的那几份从 PATH 里摘掉，或者干脆改名成adb_bak.exe让它彻底失效。做 android 安全评估的机器上，我只留一份 adb 在 PATH 里，其他工具一律配置成使用这一份，宁可多改一次配置，也不要留这个隐患。

坑五：用setx配完 PATH，别的命令全找不到了。

现象是装完 adb 之后，Python、Node、Git 集体失灵，where.exe python什么都没有。原因是setx对写入值有长度上限，PATH 太长会被截断，而它又是整体覆盖写，一截断就是永久性的。解决分两步：先在“系统属性 → 环境变量”的图形界面里看一眼用户 PATH 是不是缺了一大段；再从注册表HKCU\Environment的 Path 值里把内容捞回来，或者从另一台同配置机器上对照恢复。恢复之后改用[Environment]::SetEnvironmentVariable追加，改之前先把当前值复制到记事本里存一份，这是我现在改任何 PATH 之前的固定动作。

6. 装完怎么验：一份 adb 1.0.39 的自检清单

装完不等于装好。adb devices出一次device就收工，是绝大多数“第二天又连不上”的根源，因为它只验证了列表，没验证通道。我现在的做法是固定走一遍六步自检，从版本到文件传输全过一遍，任何一步失败都能立刻定位到是哪一层。

# 1. 版本层：确认命中的是哪一份 adb adb version where.exe adb # 2. 服务层：server 能干净地重启 adb kill-server adb start-server # 3. 设备层：能看到设备，且状态是 device adb devices -l # 4. 通道层：能真正进 shell 拿到数据 adb shell getprop ro.product.model # 5. 文件层：push 和 pull 双向都通 "adb-check" | Out-File -Encoding ascii .\adb-check.txt adb push .\adb-check.txt /data/local/tmp/adb-check.txt adb pull /data/local/tmp/adb-check.txt .\adb-check-back.txt # 6. 清理：别在设备上留垃圾 adb shell rm /data/local/tmp/adb-check.txt Remove-Item .\adb-check.txt,.\adb-check-back.txt

对应每一步的通过标准和不通过先看哪里：

第 5 步值得单独说一句：adb devices通而adb push不通，是很容易被忽略的状态，通常和目标目录不可写或者路径里混了中文有关。用/data/local/tmp作为落点是通用做法，这个目录 shell 用户可写，不涉及系统分区，用完删掉不留痕迹。

从那以后，我每次在一台新 Windows 机器上装完 adb，都会强制走一遍“kill-server → start-server → devices -l → shell getprop → push/pull”这套动作，一次做完也就两分钟，但能把 90% 的隐性故障提前暴露在装机阶段，而不是等到排查现场才翻车。希望帮到你。

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