企业官网建设流程全解析

前阵子整理移动端调试工具箱，把几个旧版本adb单独抽出来做了归档，1.0.31是被翻出来频率最高的一份。很多人不理解：Android SDK Platform Tools版本号都迭代到三十几、四十多了，系统自带的adb也一路跟着更新，为什么还有人专门找一个2015年前后的老版本？因为这个版本在兼容老旧设备、精简体积、稳定脚本行为上有实打实的价值，并不是"不会用新版"才去翻老古董。这篇既是adb 1.0.31下载仓库的配套说明，也是一份从环境配置到常用命令的完整上手文档：下载源怎么选、环境怎么配、设备怎么连、命令怎么用、老版本会遇到哪些坑，一次讲完。

我会尽量用实际操作里验证过的结论来讲，凡是"可能是XX"的地方都会直接标注存疑，不给你画饼。如果你手头正好有旧平板、电视盒子、老安卓手机，或者你只是想找一个干净的adb命令行工具来跑自动化脚本，这篇应该能帮上忙。

1. 为什么还有人专门找adb 1.0.31这种老版本

1.1 1.0.31在adb版本谱系里的位置

adb的版本号体系和platform-tools的版本号并不是同一个数字。adb 1.0.31这个内部版本大约对应platform-tools r23系列，是Android 5.x到6.x时代用得非常广泛的一个小版本。它的特点是干净：解压后只有几个核心文件，总大小才几MB，不依赖Java环境、不需要装SDK Manager，双击就能跑。那时候的adb已经集成了fastboot、screencap、logcat、uiautomator dump等一系列常用能力，对绝大多数调试需求来说，功能上并不残缺。

很多人误以为"版本越新越强"，其实adb这类命令行工具的核心接口十几年没大变过。1.0.31能执行的常用命令，新版也能执行；而新版带的一些新协议、新特性，老版本用不上也不影响普通调试。这就像一个用了十年的螺丝刀，杆身可能有点旧，但拧普通螺丝照样顺手。

1.2 老版本的核心价值在哪里

老版本能在下载仓库里长期占一个位置，原因不外乎三点：

• 体积小：完整windows版压缩包通常只有几MB，放到U盘里、拷到没有网络的机器上随时能用，不占资源。
• 命令行为稳定：对于自动化脚本来说，最怕的不是功能少，而是行为变来变去。1.0.31的输出格式、退出码、报错信息都比较固定，脚本写好了不容易跑崩。
• 对旧设备友好：家里翻出来的旧安卓手机、老平板、电视盒子，系统版本往往停在Android 4.x到6.x，用老版本adb连接握手成功率反而更高，很少出现"新工具连旧设备"的兼容性折腾。

我在给老电视盒子刷机、给旧手机做自动化测试时，遇到连接不畅的情况，换成1.0.31九成都能解决。这不是玄学，是老协议和老设备之间的兼容性确实更好。

1.3 什么情况下不建议用这个老版本

我也得把丑话说在前面。如果你要处理的是Android 13、14这种新机型，或者要使用无线调试、配对码连接、新版模拟器这些新生态功能，1.0.31会显得吃力。它不认识新的无线配对协议，部分厂商定制系统对旧握手协议也未必友好，可能出现设备能识别但执行命令卡住的情况。

新老版本混装才是更靠谱的做法。电脑上保留一个旧版1.0.31，再留一份最新的platform-tools，按需求切换，而不是指望一个版本吃遍所有场景。

2. 一个靠谱的adb 1.0.31下载仓库里应该有什么

2.1 一个完整的资源包至少要有这些文件

先说什么叫"完整"。下载一个adb 1.0.31的包，解压后至少要看到如下几个核心文件，以Windows版为例：

• adb.exe：主程序
• AdbWinApi.dll：Windows下的adb依赖库
• AdbWinUsbApi.dll：USB通信依赖库
• fastboot.exe：刷机模式工具，通常一起打包
• 可能还有NOTICE.txt、source.properties等说明文件

经常有人在网上下载到残缺包，运行时报"由于找不到AdbWinApi.dll，无法继续执行代码"。这不是系统坏了，是资源包不完整。判断仓库是否靠谱，先看它有没有把这些依赖dll放齐，再看有没有提供版本核对信息。

2.2 三步核实版本真伪

版本号是可以造假的，下载后第一件事就是验证。操作很简单：

1. 把解压后的目录打开，在地址栏输入cmd并回车，在当前目录打开命令行。
2. 输入adb version并按回车。
3. 如果输出包含Android Debug Bridge version 1.0.31，说明资源包对得上版本；如果显示别的版本号，说明这个仓库的标注有问题。

另外，如果资源页提供了文件的MD5或SHA256校验值，下载后建议顺手算一下。Windows可以用certutil -hashfile 文件名 SHA256来对一下哈希，这一步能过滤掉绝大多数被篡改的文件。

2.3 下载渠道与安全提醒

必须强调一句：adb本身是Android官方提供的免费命令行工具，"免费下载"是它的天然属性，不需要花一分钱。网上那些把"免费下载"当卖点、还让你注册登录或者关注公众号才能拿链接的渠道，反而要提高警惕。

我推荐的优先级是：

• 官方路径：Android开发者网站上的SDK Platform Tools页面，这是最稳的源头。
• 可信镜像：一些长期维护的GitHub仓库或开发者个人站，会保留历史版本，一般有清晰的README和版本说明。
• 不推荐：第三方下载站、网盘搬运，容易捆绑广告软件或篡改文件。

下载完解压之后，先杀毒软件扫一遍，再确认目录里没有多出奇怪的exe或脚本。正经的adb包里文件数量很少，多出来的东西大概率有问题。

3. 环境配置的完整过程：解压、加Path、过验证

3.1 Windows下的环境变量配置步骤

拿到合格的资源包之后，第一步是把它放到一个固定的目录，然后让命令行认识它。我的建议是先把整个文件夹解压到一个无中文、无空格的路径，比如C:\adb。放在中文路径下，某些老脚本和批处理会解析出错，这不是危言耸听，我踩过。

接下来配置环境变量：

1. 按Win + R，输入sysdm.cpl打开系统属性。
2. 切到"高级"选项卡，点"环境变量"。
3. 在"用户变量"里找到Path，双击编辑，新建一行，填C:\adb。
4. 全部点确定，关掉当前命令行窗口，重新开一个新的cmd。
5. 输入adb version，能看到版本信息就成功了。

注意，配置完Path之后必须重开命令行窗口，旧窗口不会自动刷新环境变量。如果你用的是PowerShell、Windows Terminal，同理，要完全关闭再打开。

3.2 macOS和Linux下怎么配

macOS和Linux下原理相同，只是路径写法不一样。把解压后的文件夹放到一个你常用的可执行目录，比如macOS下放到/usr/local/bin，Linux下放到/usr/local/bin或~/.local/bin，或者在你自己的shell配置里加一行PATH：

export PATH=$PATH:/path/to/adb_folder

之后执行adb version验证。如果提示权限不足，先给adb和fastboot加执行权限：

chmod +x adb fastboot

macOS首次运行还可能在"系统偏好设置-隐私与安全性"里弹"已阻止"的提示，去点一下"仍要打开"就行。

3.3 手机端打开USB调试的前置准备

电脑端配好只是开始，手机端不开调试模式，一切白搭。通用路径是：设置 -> 关于手机 -> 连点"版本号"7次，直到提示"已进入开发者模式"；然后回到设置，进入开发者选项，打开USB调试。

不同品牌的入口和额外限制差别很大，我列几个常见的：

手机插上电脑后，第一次连接会弹出"是否允许USB调试"的授权框，记得勾选"始终允许"，再点确定。

3.4 常见配置报错与处理

配置过程中最常见的报错是'adb' 不是内部或外部命令，这个基本是Path没生效或者目录填错，重开命令行再试。另一个高频问题是电脑上装过其他版本的adb、模拟器自带的adb也在运行，报了adb server version mismatch，意思是电脑上当前的adb server和客户端版本对不上。解决方法是先杀掉所有adb进程：

adb kill-server tasklist | findstr adb

把残留的adb.exe进程结束后，重新执行设备连接。多个adb版本混装时，最好在脚本里写死你用哪个目录的adb，不要只靠Path。

4. 连接设备与授权：unauthorized这类“第一道坎”的排查链路

4.1 adb devices的四种状态分别代表什么

连接设备后输入adb devices，正常情况下会看到List of devices attached下面列出一个设备编号加状态。状态常见有四种：

对新手来说，device是唯一能继续操作的状态。剩下三种都需要处理。

4.2 unauthorized的完整排查链路

unauthorized是问得最多的一个问题，很多人的设备明明插着、驱动也装了，就是卡在未授权状态。我一般按这个顺序排查，从头到尾走一遍基本能解决：

1. 先换数据线和USB口。看起来像废话，但至少有一半的"连不上"问题出在劣质充电线上。普通充电线没有数据传输能力，只能充电，必须要用支持数据传输的线。
2. 看手机有没有弹出授权框。如果弹了，勾选"始终允许使用这台计算机进行调试"，再点确定。
3. 没弹授权框怎么办。进入开发者选项，点"撤销USB调试授权"，拔掉数据线重插，这时系统应该会重新弹授权框。
4. 重启adb服务。在电脑上依次执行：

adb kill-server adb start-server adb devices

5. 查端口占用。adb服务默认监听5037端口，如果被其他程序占住，授权流程也可能异常。Windows下用：

netstat -ano | findstr 5037

找到占用端口的进程PID后，去任务管理器结束它，再重启adb。 6.重启手机和电脑。如果上面都不行，把手机和电脑都重启一遍，再重试。

这套流程我执行过无数次，绝大多数unauthorized都能在第四步之前解决。真正需要重启设备的场景很少。

4.3 连接第三方模拟器的差异

如果你用的是夜神、MuMu、雷电这类安卓模拟器，连接方式有点特殊。模拟器自带一个adb实现，端口也跟实体机不一样。直接用官方adb连接时，一般用adb connect 127.0.0.1:端口号，各模拟器常见端口如下：

端口可能随版本变化，连接失败时以模拟器设置页显示的端口为准，或者在任务管理器里查看模拟器进程监听的端口。夜神自己也带了一个nox_adb.exe，如果你装的是老版本adb连不上夜神，可以直接用夜神目录下的nox_adb.exe devices来操作，本质是adb的一层封装。

4.4 老版本连接新设备时的取舍

Android 10之后的设备，用1.0.31连接，基础命令（screencap、logcat、install）大多能跑通，但要有两个心理准备。一是厂商定制系统可能对旧协议握手不友好，偶尔出现adb devices能识别，执行命令时卡住没有任何响应；二是Android 11之后新增的无线调试配对码功能，老版本adb完全不支持。这时老老实实用USB线连接，或者先USB连一次，执行adb tcpip 5555，再adb connect 设备IP:5555走传统无线adb方式。

5. 高频ADB命令实战：截图、日志、UI与文件传输

5.1 截图保存到电脑

"adb截图保存电脑"是我见过最常用的需求。最简单的一条命令：

adb exec-out screencap -p > screen.png

注意Windows用户要分两种情况：在cmd里执行没问题，但在PowerShell里直接执行，重定向符>会把截图文件按文本方式编码，生成出来的png往往打不开。PowerShell环境建议这样写：

cmd /c "adb exec-out screencap -p > screen.png"

或者改用两步方案，先在手机上截屏再拉回电脑：

adb shell screencap /sdcard/screen.png adb pull /sdcard/screen.png .

第二种方案更稳，适用于所有平台，也适合脚本里批量截图。如果你同时连了多个设备，需要给命令加-s 设备序列号参数，对应截图保存成不同文件名，避免互相覆盖。

5.2 logcat抓取日志与过滤

调试App崩溃、查看系统日志都绕不开logcat。基本玩法：

adb logcat -v time > app.log

跑一会儿之后按Ctrl + C结束，所有日志带时间戳存到app.log。更专业的做法是先清空旧日志，再复现问题：

adb logcat -c adb logcat -v time > app.log

这样得到的日志干净，方便定位问题。如果只想看某个App的日志，先拿到它的进程ID：

adb shell pidof 包名

然后按进程号过滤：

adb logcat --pid=进程ID -v time > app_only.log

老设备上如果logcat本身不支持--pid，可以用adb logcat | grep 包名这种管道过滤，虽然会多抓一些噪声，但也能定位到关键崩溃信息。看到FATAL EXCEPTION、AndroidRuntime这类关键字，基本就是崩溃现场了。

5.3 uiautomator dump做UI层级分析

做自动化、做界面分析离不了uiautomator。标准用法：

adb shell uiautomator dump adb pull /sdcard/window_dump.xml .

或者直接指定输出路径：

adb shell uiautomator dump /sdcard/ui.xml adb pull /sdcard/ui.xml .

生成的xml里能看到当前界面的控件层级、坐标、文本，自动化脚本定位点击位置全靠它。

很多人遇到uiautomator dump用不了，先检查三件事。第一，屏幕是否处于锁屏或熄屏状态，锁屏状态下dump基本必失败，先点亮屏幕；第二，显式指定输出路径，很多设备不指定路径会报权限或路径错误；第三，报could not get idle state时，说明界面事件太频繁，稍等几秒重试，或者先随便点一下屏幕再执行。

5.4 push、pull与文件传输

电脑和手机之间传文件，比用MTP协议稳定得多：

adb push C:\test.apk /sdcard/ adb pull /sdcard/test.txt C:\

push是电脑往手机传，pull是手机往电脑拉。传整个目录也可以：

adb pull /sdcard/DCIM .

路径里有中文或空格时，用双引号把路径包起来，否则命令行会把空格当成分隔符解析错。老版本adb传大文件的表现反而稳定，没有新版本那些花里胡哨的额外检查，流程更干脆。

5.5 系统设置、电池模拟与无障碍权限

这类命令适合玩机党，但操作前要有心理准备，改坏了要自己能改回来。

设置屏幕刷新率，部分机型支持：

adb shell settings put system peak_refresh_rate 120 adb shell settings put system min_refresh_rate 120

改完一般立刻生效，但重启后可能恢复默认，属于正常的系统策略。

模拟电池状态，这是测试场景里非常好用的功能：

adb shell dumpsys battery set usb 0

这条命令会把电池信息里的USB连接状态改成未连接，用来模拟拔掉充电线后的行为。用完记得重置：

adb shell dumpsys battery reset

授予应用无障碍权限，手工点设置容易漏点，用adb一步到位：

adb shell settings get secure enabled_accessibility_services

先看当前已有的无障碍服务列表，记下旧值，然后写入你要开启的服务：

adb shell settings put secure enabled_accessibility_services 包名/服务名 adb shell settings put secure accessibility_enabled 1

注意，服务名的格式是包名/完整服务类名，不确定时可以先用dumpsys package 包名 | grep -A 5 accessibility查。改完了如果要恢复，把第一步查到的旧值写回去就行。

5.6 安装卸载、解除安装权限与冻结应用

安装APK：

adb install -r app.apk

卸载应用：

adb uninstall 包名

有些国产ROM默认限制USB安装，报INSTALL_FAILED_USER_RESTRICTED，说明需要在开发者选项里打开"USB安装"开关，或者尝试关闭安装校验：

adb shell settings put global verifier_verify_adb_installs 0

这个命令只是关闭安装校验器，不保证一定能绕过厂商的安装限制，具体以手机型号为准。

冻结应用是精简系统最重要的命令：

adb shell pm list packages -3 adb shell pm disable-user --user 0 包名

冻结后应用图标会从桌面消失，想要恢复：

adb shell pm enable 包名

pm disable-user不是卸载，系统应用不会被删除，只是对当前用户停用，随时可以恢复，比root后删系统App安全得多。

6. 从机顶盒到自动化：几个高频特殊场景的实操与边界

6.1 老款电视和机顶盒的强制adb思路

老款创维如何打开adb，这个问题在论坛里一直有人问。不同型号的路径差异很大，但通用思路是相通的：先在设置里找"本机信息"或"关于"，用遥控器连按版本号或者确定键，看能否进开发者选项；部分老型号需要进工厂菜单才能看到adb开关，工厂菜单的进入方式依赖具体机型，网上对应型号的教程才准确。

机顶盒"强制adb"的原理也一样，adb功能是系统自带的，只是厂商把开关藏起来了。如果设置里实在是找不到adb开关，不要迷信来路不明的"强制开启工具"，那些工具往往要配合工程固件或者有系统漏洞风险，普通用户踩坑的代价远大于收益。

6.2 vivo等机型adb精简应用列表的思路

以vivo手机为例，"adb精简列表"本质上就是用pm命令找出可以冻结的系统内置应用，然后逐个disable。基础流程：

adb shell pm list packages | grep vivo adb shell pm list packages -3

把第三方程列出出来，把带vivo、bbk、i管家等关键字的应用列出来，就能拼出一份属于自己机型的精简候选列表。但要注意，每次只冻结两三个应用，然后重启看看系统是否正常。如果误禁了桌面（vivo桌面通常是com.bbk.launcher），手机会卡在启动界面进不去，这时候还是靠adb救回来：

adb shell pm enable com.bbk.launcher

所以动手之前，把pm list packages的完整输出保存到电脑上，这是你最重要的回滚依据。

6.3 新机（红米K70）用adb冻结应用是否可行

新机型用老版本adb冻结应用，通常是可以的，pm disable-user这个接口在Android 13、14上依然存在。但红米K70这种新机有两个限制要先知道。

第一，MIUI部分版本在开发者选项里多了一个"USB调试（安全设置）"开关，不打开它，pm disable-user会提示权限不够。第二，系统关键组件有保护级别，普通adb权限根本disable不了，遇到SecurityException就放弃，这是系统层面的保护，不是命令用错了。

另外提醒一点：新机能冻结的大多是自己安装的第三方应用和少量系统应用，不要指望能用adb把广告组件全部干掉，厂商也在不断收紧这块权限。

6.4 自动化脚本场景：从adb input到组合工具

关于"adb企业微信自动打卡"这类需求，本质是定时执行adb shell input tap 坐标、adb shell input text 文字、adb shell input swipe来模拟人工操作。从学习adb输入事件的角度，自己写一个自动点击demo完全够用，也能加深对input机制的理解。但把这类脚本用在真实考勤场景里，涉及企业应用账号的自动化操作，既有合规风险，也容易触发应用风控，不建议滥用。

真正值得花时间的是打造一套PC和安卓联动的自动化工具链。很多人盯着的qt + ffmpeg + adb路线，就是一个很好的方向：用adb实现手机端截屏、录屏（screenrecord），把数据传到PC，用ffmpeg做画面分析或录制处理，再用qt写一个控制界面。老版本adb的screenrecord在Android 4.4之后都已经很稳定，用来跑这个学习项目完全够用。

最后分享两个我自己的实操习惯。第一，我在电脑上会同时保留两个目录：一个放1.0.31，一个放最新的platform-tools，但不在系统Path里混用，而是用的时候直接切到对应目录执行，或者在脚本里写死绝对路径。这样永远不会出现"到底跑的是哪个adb"的混乱。第二，拿到任何一个adb下载包，先跑一次adb version，再拿同一台测试机跑一遍screencap、logcat、push/pull，确认这个包能正常干活，再放进自己的下载仓库。工具这东西，关键时候靠得住，比版本号新不新重要得多。