企业官网建设流程全解析

先用一个很多人都经历过的场景开场：手机插到 Linux 电脑的 USB 口，敲下adb devices，结果设备列表空空如也。然后你开始在网上搜“Linux ADB 安装”“adb 驱动”之类的关键词，下载了一堆所谓的一键工具，甚至有人建议你去装个虚拟机再绕回 Windows，最后折腾一晚上还是没通。其实问题大概率不在驱动，而在 Linux 对 USB 设备的权限模型。这篇指南就围绕 Linux 系统下 ADB 环境的完整安装步骤和基础设置展开，从零开始带你把环境配置到能正常使用的状态，顺便把安装过程中最容易踩的坑提前排掉。

不管你是做 Android 开发、做自动化测试，还是只想让电脑帮忙管理手机里的文件、批量安装应用，ADB 都是绕不开的底座。文章会覆盖最常用的安装方式、udev 权限配置、首次连接授权、常见报错排查，以及装好之后真正高频使用的命令。最后还会用实际排障经验讲讲那些文档里不会写的细节，适合刚接触 Linux 的新手，也适合从 Windows 转向 Linux 的开发者快速对齐。

1. 为什么在 Linux 上装 ADB 值得花时间

1.1 ADB 到底能干什么

ADB 全称 Android Debug Bridge，是 Android 官方的调试桥接工具。它既不只是一个“装 APK 的工具”，也不仅仅是开发者专属，它负责打通电脑和 Android 设备之间的通信通道，让你能用命令行做很多图形界面做不到的事。

我自己的使用场景大概有这几类：调试自己写的 App 时看logcat日志、抓取线上 bug 的日志反馈；做自动化测试时用脚本批量控制真实手机；帮朋友从吃灰的旧手机里导出照片和文件；甚至有些按键映射、键盘映射工具，本质上也是通过 ADB 把电脑按键模拟成手机触摸事件。简单说，只要你需要把 Android 设备和电脑深度协同，ADB 就是那条必经之路。

1.2 新手在 Linux 上装 ADB 常见的卡点

很多人在 Windows 上装 ADB 很顺利，因为 Windows 有统一的驱动安装逻辑：下载驱动、安装、重启、识别设备。但到了 Linux 上，这套经验不通用。最常见的卡点有三个：

• 找不到设备，adb devices输出是空的，没有序列号；
• 显示了设备，但状态是unauthorized，授权弹窗没出来或者被手滑拒绝了；
• 显示了设备也授权了，但提示no permissions，普通用户没有读取 USB 设备的权限。

这三个问题都不是“装坏了”，而是没理解 Linux 的 USB 权限模型。Windows 的“ADB 驱动”是一套闭源的驱动程序包，而 Linux 下的“驱动”更多是内核自带的 USB 识别逻辑，配合用户态的 udev 规则来开放访问权限。理解了这一点，后面配置起来就不会瞎试。

2. 安装前必须清楚的三件事

2.1 platform-tools 与 SDK 的关系

先帮大家把名词对齐。Android SDK 是一整套开发工具，里面包含了很多组件，ADB 只是其中一个。Google 并没有为 ADB 单独发布压缩包，而是把它和其他调试工具一起打进了一个叫platform-tools的组件里，里面除了adb还有fastboot、etc1tool、make_f2fs等工具。

这就带来一个实际影响：你不管用哪种方式安装，本质上拿到的都是platform-tools这个包，只是来源不同。明白这层关系后，就不会出现“我明明安装了 ADB，但是找不到 fastboot 怎么办”这类疑问，因为两者是捆绑在一起的。

2.2 手机上要打开的开关和 USB 模式

很多时候电脑端安装完全没问题，问题出在手机端没设置对。第一次连 USB 之前，你需要在手机上打开两个开关：

• 开发者选项：一般路径是“设置 → 关于手机 → 版本号”，连续点击版本号 7 次，就会提示进入开发者模式。不同品牌的入口略有差别，比如小米通常在“更多设置”里，三星在“软件信息”里，华为在“关于手机”里，但大逻辑都是连点版本号。
• USB 调试：进入开发者选项后，找到“USB 调试”并打开。部分手机还有二级开关，比如“USB 调试（安全设置）”“仅充电模式下允许 ADB 调试”，建议有的话一并打开。

除了这两个开关，USB 连接模式也很关键。很多手机默认是“仅充电”模式，在这种模式下部分设备根本不会被 ADB 识别。插上手机后，下拉通知栏，把 USB 连接方式改成“文件传输 / MTP”模式，再试adb devices。这看起来是一个很基础的操作，但我见过太多人卡在这一步，换线换口折腾半天，最后发现是 USB 模式没切。

2.3 Linux 下的“驱动”不是 Windows 那种驱动

Linux 系统装 ADB 时搜索“adb 驱动”，很容易被引入误区。Linux 内核几乎涵盖了主流 Android 设备的 USB 枚举协议，只要用的是近几年的发行版，插上手机后系统一般都能识别到这个 USB 设备的存在。你可以用lsusb验证，如果能看到类似Google Inc.或手机厂商英文字样的条目，说明内核层面已经识别了，不需要装任何“驱动”。

但内核识别了不代表你的用户能访问它。Linux 对 USB 设备有权限管控，默认情况下只有 root 用户能直接读写设备节点。ADB 工具以普通用户身份想把命令发给手机，必须通过 udev 规则把设备节点权限放开。这就是 Linux 下和 Windows 最大的区别：Windows 纠结的是“驱动装没装”，Linux 纠结的是“规则配没配”。这篇文章后续会把 udev 规则单独讲透。

3. 三种安装方式，我建议你这样选

3.1 包管理器安装：最快但不是最优

如果你用的是 Debian/Ubuntu，一条命令就能装好：

sudo apt install adb

Fedora/RHEL 系的命令是：

sudo dnf install android-tools

Arch 系的命令是：

sudo pacman -S android-tools

这种方式的好处是快、依赖自动处理、升级跟着系统走。但它有一个不能忽视的短板：版本往往比较旧。官方 platform-tools 更新很频繁，比如 Android 11 引入了无线调试配对后，旧版 ADB 的配对支持并不完整；再比如某些新机型的 USB Vendor ID 或协议细节变化，旧版本可能兼容性不好。所以我的建议是：临时用一下、或者手头没有别的安装条件，用包管理器没问题；但如果你要长期做开发、调测试设备，建议看下一种方式。

3.2 官方 platform-tools 手动安装：推荐

从 Google 官方渠道下载platform-tools压缩包，解压后配置环境变量，这种方式更可控。优点是版本永远保持最新、命令完整、不依赖系统源维护者的更新节奏，而且解压出来的adb、fastboot和 SDK 完全一致，很少出现“命令存在但行为诡异”的问题。

缺点是升级需要自己做，新版本发布后你得手动重新下载覆盖。不过这个成本很低，一次下载加解压就一分钟。下面整个实操部分默认采用这种方案。

3.3 源码编译：什么情况下才需要考虑

还有一种方式是直接从 AOSP 源码编译 ADB。坦率说，普通用户完全没有必要这么做，编译环境本身就要搭很久，而且 AOSP 的构建系统不是随便 clone 下来就能跑。真正需要源码编译的场景只有一个：你要修改 ADB 源码本身，比如给 ADB 增加自定义命令、调整协议实现，或者目标平台不是常规的 x86_64/aarch64 Linux，需要交叉编译到某个工控板或嵌入式设备上。

如果你只是想把环境装好用起来，跳过源码编译，别在这上面浪费时间。

三种方式对比如下：

4. 完整实操：下载、解压、配 PATH、首次连接

4.1 下载官方 platform-tools 压缩包

官方地址可以在 Android Developers 网站的 platform-tools 发布页找到。提供了 Linux、Windows、macOS 三个平台的压缩包，我们选 Linux 版本。这里我建议直接使用固定链接，方便在终端里下载：

wget https://dl.google.com/android/repository/platform-tools-latest-linux.zip

如果后续 Google 调整了目录结构导致链接失效，就去官方页面点开 Linux 版本的下载按钮复制新地址。下载完成后，强烈建议先确认文件完整性和安全性，和官方页面公布的 SHA-256 校验值比对一下：

sha256sum platform-tools-latest-linux.zip

4.2 解压安装与环境变量配置

解压到/opt目录下，这是一个比较规范的做法，因为/opt就是留给第三方独立软件的：

sudo unzip platform-tools-latest-linux.zip -d /opt

解压后会得到/opt/platform-tools目录。然后把adb的路径加入 PATH，方便在任何目录下直接调用。如果你用的是 Bash，执行：

echo 'export PATH=$PATH:/opt/platform-tools' >> ~/.bashrc source ~/.bashrc

如果你用的是 Zsh，把上面的.bashrc换成.zshrc。写完环境变量后，在当前终端里执行：

adb version

如果看到Android Debug Bridge version 1.0.41以及后面的Version 35.0.2-xxx字样，说明环境变量已经生效。

这里顺便解释一下为什么选择改~/.bashrc而不是/etc/profile或/etc/environment。对于个人使用场景，写用户级的配置文件足够了，避免影响系统全局；而且 Bash 打开新终端时会读取~/.bashrc，比登录 shell 才加载的一些配置更符合日常操作习惯。如果你希望所有用户都能用 ADB，再考虑全局配置也不迟。

4.3 启动 adb server 并完成手机授权

ADB 是 client-server 架构。你敲的每个adb命令是 client，后台会有一个常驻的adbd server进程负责跟手机通信。首次执行adb devices时，系统会自动拉起 server。你也可以手动管理它：

adb start-server adb kill-server

把手机通过 USB 线连上电脑，确认手机端 USB 模式已经是“文件传输 / MTP”，然后执行：

adb devices -l

第一次连接时，手机屏幕上会弹出一个“允许 USB 调试吗”的授权对话框，建议勾选“始终允许”，再点确定。然后重新执行adb devices -l，设备状态应该从unauthorized变成device。状态为device后，运行：

adb shell echo ok

如果返回ok，说明电脑和手机之间的通道已经完整打通。

4.4 安装验证的几个检查点

我给这套安装过程定了几个明确的检查点，方便你判断自己进行到了哪一步：

1. adb version能正常输出版本号，说明程序和 PATH 配置没问题；
2. adb devices -l能看到设备序列号且状态为device，说明 USB 识别和授权没问题；
3. adb shell echo ok能返回输入的内容，说明 shell 通道可用；
4. 断开 USB 数据线后，adb devices输出会失去设备，这是正常现象，不代表安装失败。

这四个点全部通过，你的 Linux 下 ADB 环境就算真正完成了。

5. 基础设置：udev 规则与授权管理

5.1 先学会用 lsusb 找到手机厂商 ID

当你发现adb devices能看到设备但提示no permissions，或者设备列表偶尔能出、偶尔为空，大概率是 udev 规则没有配好。配置规则前，第一步是找到你手机的 USB Vendor ID。

先把手机拔掉，执行：

lsusb

记住当前列表，然后插入手机再执行一次，新增的那一条就是你的设备。它的输出大概长这样：

Bus 001 Device 003: ID 12d1:107a Huawei Technologies Co., Ltd.

这里的12d1就是 Vendor ID，也叫厂商 ID，107a是 Product ID。厂商 ID 一般由 USB 标准组织分配，同一家厂商的设备通常共用同一个 Vendor ID。比如常见的 Google 是18d1，三星是04e8，华为是12d1，小米是2717。但不要只记供应商列表，以你电脑上lsusb实际输出为准，不同型号、不同时期的产品编码总会有些变化。

5.2 编写 udev 规则并让系统重载

udev 是 Linux 的设备管理服务，它可以根据自定义规则在设备接入时自动设置权限。我们需要新建一个规则文件，把 Android 设备的访问权限放开：

sudo nano /etc/udev/rules.d/51-android.rules

规则内容按这个格式写，把自己的 Vendor ID 替换进去：

SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", MODE="0666", GROUP="plugdev"

这条规则的含义是：当检测到 USB 设备且 Vendor ID 匹配时，把设备节点权限设为0666（所有用户可读写），并将属组设为plugdev。保存文件后重载规则：

sudo udevadm control --reload-rules sudo udevadm trigger

然后重新插拔 USB 线，再次执行：

adb devices

如果截图不了就检查设备节点权限：

ls -l /dev/bus/usb/001/003

看到类似crw-rw-rw-的权限位，说明规则已经生效。

这里有个容易踩的细节：规则文件名的数字前缀不要随便写。udev 会按文件名字母顺序加载规则，数字小的优先，一般建议使用50或51开头，确保它能覆盖掉某些发行版自带的权限规则。还有，插拔一次不够确定生效的话，建议把手机重启一次，有些设备的 USB 枚举逻辑比较顽固，必须重新插拔或重启后才读取新规则。

5.3 授权不生效与 unauthorized 的处理

有一种情况是：udev 规则也配了、权限也对了，但adb devices里设备一直是unauthorized，手机也不弹授权框。这通常是 ADB 的 RSA 密钥认证出了问题。

ADB 的安全机制是：电脑生成一对 RSA 密钥，首次连接时把公钥发给手机，手机上弹出的确认框其实是让你确认是否信任这台电脑的密钥。如果你之前点了“拒绝”，或者手机端撤销了 USB 调试授权，电脑和手机之间就没有建立信任关系。

处理方式分两步。手机端：进入开发者选项，点击“撤销 USB 调试授权”，把历史信任全部清掉。电脑端：删除本机已有的 ADB 密钥，让 ADB 生成一把新钥匙：

rm ~/.android/adbkey rm ~/.android/adbkey.pub adb kill-server adb start-server

然后拔插 USB，手机会再次弹出授权框，这次记得勾选“始终允许”。我试过很多次，这么操作后基本都能解决 unauthorized 问题。

5.4 无线调试与端口映射、代理重置

基础设置里无线调试也算比较高频的需求。如果你使用的是 Android 11 及以上版本，可以选择官方的无线调试，无需插线也能连接：

1. 手机打开“无线调试”开关；
2. 点击“使用配对码配对设备”，会显示配对码和端口；
3. 电脑端执行：

adb pair <手机IP>:<配对端口>

根据提示输入配对码，完成配对后再用：

adb connect <手机IP>:<无线调试端口>

连接成功后再执行adb devices，就能看到状态为device的设备。

如果是 Android 10 或更早的系统，可以用传统方式：先用 USB 连接手机，执行：

adb tcpip 5555

然后拔掉 USB，再通过局域网连接：

adb connect <手机IP>:5555

无线调试刚上手的时候，常见问题是adb connect一直卡在offline。原因通常有两个：一是手机和电脑不在同一个网段，比如电脑连着有线网、手机连着访客 Wi-Fi；二是上一次连接的端口已经失效。先确认网络互通，再重新 connect 一下。

另外，很多人在调试过程中会用 ADB 设置端口转发或代理，结果某天发现连接异常、命令卡顿，这时可以考虑是否是代理残留导致。可以执行以下命令确认并重置代理设置：

adb shell settings get global http_proxy adb shell settings delete global http_proxy adb shell settings put global global_http_proxy_host :0 bash

如果你的场景里确实配置过代理，重置后一般能恢复正常通信，这也是基础设置的一部分，提前了解一下省得后面踩坑。

6. 高频报错排查：从 adb devices 空列表开始

6.1 排障顺序，别一上来就动规则

adb devices输出为空的时候，很多人的第一反应是去重装驱动、改规则，但这样很容易把好的配置改坏。我自己的排障顺序非常固定，从底层到上层一层层排除：

1. 先看手机物理连接：换一根数据线、换一个 USB 口。这一步能排除掉 30% 的问题，尤其是那种“可以充电但不能传数据”的线，特别常见；
2. 检查手机 USB 模式：通知栏下拉，务必切到“文件传输 / MTP”，别用“仅充电”；
3. 检查手机端授权弹窗：很多时候设备其实已经识别了，但授权框被系统收起来了，解锁手机看看；
4. 重启 ADB 服务：执行adb kill-server && adb start-server；
5. 执行lsusb看内核是否识别到设备，没识别到优先考虑线材和 USB 模式；
6. 如果lsusb能识别但adb devices仍然空，再考虑 udev 规则的问题。

这套顺序看起来简单，但能帮你节省大量时间。我见过不少人前两步还没做，就跑去改了半天的 udev 规则，最后发现只是线材不支持数据传输。

6.2 常见报错与解决方案对照表

表格里这些现象，90% 的情况都是第一行和第三行，先把物理层和授权层解决，再深入系统设置。

6.3 一个排障案例：USB 默认“仅充电”导致找不到设备

分享一个我实际遇到过的案例。之前在一台 Fedora 机器上帮朋友配置 ADB，他使用的是某款国产手机，我按老流程操作：

1. 确认开发者选项和 USB 调试已经打开；
2. lsusb能识别到设备，Vendor ID 都正常；
3. 配置好 udev 规则，重载后重新插拔；
4. adb devices仍然什么都没有。

当时的怀疑对象从线材到规则全部过了一遍，最后发现手机的通知栏显示“正在通过 USB 充电”，点进去才发现 USB 配置默认是“仅充电”，而且这款手机在“仅充电”模式下不会弹出 USB 调试授权窗。把它切到“传输文件”模式后，授权弹窗立刻出现，adb devices也正常显示了设备。

这个案例给所有人的提醒是：当adb devices无输出且lsusb能识别到设备时，先看一眼手机通知栏的 USB 工作模式，不要急着去动配置文件。很多国产系统的默认 USB 模式就是“仅充电”，这一点 Windows 上也一样存在，只是 Windows 的驱动安装过程往往会在中途提示你切换模式，而 Linux 下没有这种引导，更容易被忽略。

7. 装好后值得掌握的基础操作和脚本技巧

7.1 按场景分类的常用命令

环境搭好之后，真正经常用的命令其实就那二十来条。我按使用场景分组列一下，方便大家直接查：

• 设备连接与信息查看：

  • adb devices -l查看已连接设备及型号信息；
  • adb shell getprop ro.product.model查看设备型号；
  • adb shell wm size查看屏幕分辨率；
  • adb shell wm density查看屏幕密度。

• 应用安装与管理：

  • adb install -r app.apk安装 APK，-r表示覆盖安装；
  • adb uninstall <包名>卸载应用；
  • adb shell pm list packages列出所有已安装应用包名；
  • adb shell pm clear <包名>清空应用数据，这个在测试 App 首次启动流程时非常实用。

• 文件传输：

  • adb push <本地文件> /sdcard/把电脑文件推送到手机；
  • adb pull /sdcard/<手机文件> <本地目录>把手机文件拉到电脑。

• 模拟操作：

  • adb shell input tap x y模拟点击；
  • adb shell input swipe x1 y1 x2 y2模拟滑动；
  • adb shell input text "hello"模拟输入文本；
  • adb shell input keyevent KEYCODE_HOME模拟按键（比如返回、Home 键）。

这里特别说一下input text。它有一个限制：只支持英文字符和数字，中文或特殊符号往往打不进去。如果你确实需要向手机中输入中文，常规办法是安装一个 ADB 键盘类应用，然后用它作为输入法配合adb shell input text来输入，这就是“ADB 键盘”类工具的基本原理。

7.2 日志、截图、录屏怎么抓

日常开发和 bug 反馈里，使用频率最高的 ADB 命令应该算logcat：

adb logcat -v threadtime > app.log

这样可以把日志实时输出并保存到文件里。-v threadtime会显示线程和详细时间信息，排问题时定位更准确。如果你只想看某个进程的日志，可以配合--pid参数：

adb logcat --pid=$(adb shell pidof -s <应用包名>)

先清空旧日志再复现问题，也是常见套路：

adb logcat -c adb logcat -v threadtime > fresh.log

截图和录屏对于提交 bug 或写文档都是标配操作：

adb shell screencap -p /sdcard/screen.png adb pull /sdcard/screen.png adb shell screenrecord /sdcard/screen.mp4

录屏默认时长上限 180 秒，配合--time-limit参数可以控制时长和分辨率，比如：

adb shell screenrecord --bit-rate 4000000 --time-limit 10 /sdcard/demo.mp4

7.3 多设备场景下的 adb -s

如果你手头连着好几台设备，直接执行adb shell会报错，提示有多台设备需要指定。这时候用-s参数加上设备序列号：

adb devices -l adb -s <设备序列号> shell

注意序列号不是厂商名，而是adb devices输出里的那一长串字符串，可能包含字母和数字。为了减少重复输入，你还可以设置环境变量ANDROID_SERIAL，指定默认设备：

export ANDROID_SERIAL=<设备序列号>

设置之后不带-s的命令都会默认作用于这台设备。这个技巧在跑自动化脚本时很省事。

7.4 批量安装 APK 的简单脚本

真实工作中经常遇到一次性要装几十个 APK 的情况，手动一个个执行adb install太痛苦。我一般用下面这个简单脚本，把 APK 都放在同一个目录下执行：

#!/bin/bash APKS=$(ls *.apk 2>/dev/null) if [ -z "$APKS" ]; then echo "当前目录下没有 APK 文件" exit 1 fi for apk in $APKS; do echo "正在安装: $apk" if adb install -r "$apk"; then echo "安装成功: $apk" else echo "安装失败: $apk" fi done

把内容保存为install_apks.sh，加上可执行权限：

chmod +x install_apks.sh ./install_apks.sh

脚本逻辑很简单，核心价值在于循环和失败提示。如果你要批量操作多台设备，可以嵌套一层for serial in $(adb devices | awk 'NR>1 && $2=="device" {print $1}'); do adb -s $serial install ...; done，稍加改造就是一个简易的多设备分发工具。

8. 只有实操过才会注意到的几个细节

8.1 别让 sudo 掺和进 ADB

很多人第一次遇到权限报错时，第一反应是加 sudo。sudo adb devices看似能解决问题，但实际上会引入一个新的坑：sudo 切换到了 root 用户，ADB 的密钥存在 root 的~/.android/下，和你普通用户的密钥不是同一份。这意味着你用sudo adb授权过的设备，在普通用户下大概率又会变成unauthorized，反过来也一样，两边互相抢授权，设备状态反复横跳。

正确做法是一开始就别用 sudo 执行 adb，而是配置好 udev 规则让普通用户能直接访问设备节点。如果已经误操作导致授权混乱，删掉~/.android/adbkey和/root/.android/adbkey两份密钥，重新走一遍授权即可。

8.2 版本冻结与升级策略

如果你正在做长期项目，ADB 版本不是越新越好。有时候项目团队里其他人用的还是旧版 platform-tools，你升级到新版后，某些命令的输出格式变了，脚本解析就会出现问题。比如adb devices -l的输出字段顺序在不同版本间可能会有调整，硬编码 awk 列数的脚本很容易在升级后失效。

我的建议是：装好之后把版本记录下来，比如存一个platform-tools-version.txt，里面写清楚版本号和下载日期。需要升级时，先看项目脚本有没有依赖命令输出格式，再决定是否升级。如果是个人开发环境，升级前最快的保险手段是先把当前版本压缩包留一份备份，出问题随时能回滚。

8.3 用完设备清理现场

最后提一个很多人不会注意但很重要的细节。ADB 连接是有后台服务常驻的，当你用完设备后，尤其是连接过别人手机、调试过不常用的设备，记得顺手执行：

adb kill-server

这样做有两个好处：一是释放后台进程占用的资源；二是在公共环境或办公电脑上，及时断开服务可以避免下一次任意手机插上后直接通过已授权的密钥进行指令操作。虽然不是通用的高风险问题，但这个习惯能让你少一些不必要的麻烦。

如果你准备长期做设备调试，还可以考虑把常用的 ADB 操作封装成 alias 或脚本，比如alias adb-model='adb shell getprop ro.product.model'，用完一次就顺手，省下不少重复输入的功夫。