企业官网建设流程全解析

1. 为什么要折腾：CentOS 7 上装 ADB 的真实场景

先说结论：如果你的工作流里压根没有安卓设备，这条折腾路上的每一步都是多余的。但如果你的日常里有以下几种需求之一，那 CentOS 7 上配置 ADB（Android Debug Bridge，安卓调试桥）就远远不是“装个工具”那么简单，它往往是一个自动化工作流的起点。

我见过最多的几类场景：

• 自动化测试集群：某公司内部跑着一批安卓真机，全部通过 USB 连接在一台 CentOS 7 服务器上，定时执行 UI 自动化脚本。没有 ADB，这套体系寸步难行。
• 持续集成流水线：构建产物打包成 APK 后，由服务器通过 ADB 安装到指定设备上做冒烟测试。CentOS 7 这类老系统作为构建节点依然大量存在。
• 设备管理平台：需要批量获取设备序列号、机型、安卓版本、电池状态，甚至远程执行 shell 命令。服务器端的 ADB 就是唯一的入口。
• 个人折腾：手头有个淘汰下来的安卓手机，想把它变成 Linux 服务器上的一个“外设”，跑脚本、做监控、抓日志。这个我也干过，后文会提到怎么玩。

先解释一下 ADB 到底是什么，方便完全没接触过的读者直接跟上。ADB 是安卓官方提供的一套命令行调试工具，它采用客户端-服务端架构：一个 adb client 跑在你输入命令的终端里，一个 adbd 服务端跑在安卓设备里，中间还有一个 adb server 作为守护进程负责两者之间的通信。连接方式可以是 USB，也可以走网络（TCP/IP）。在 Linux 服务器上装好 ADB，本质上就是把 client 和 server 这两部分搞定，让服务器能通过 USB 或者网络“指挥”安卓设备。

把标题里的“安装”二字拆开看，它其实隐含了三个层面的问题：第一，怎么把 adb 这个二进制文件放到系统里；第二，怎么让普通用户有权限操作 USB 设备；第三，怎么让系统重启之后 adb 还能正常干活。很多人只解决了第一个问题，后面两个没处理，结果就是adb devices永远看不到设备，然后跑过来问为什么。

这篇文章会按真实操作顺序，把环境准备、安装方式选择、权限配置、常见问题排查整个串起来，顺手附上我个人踩过的一些坑。CentOS 7 虽然已经进入生命周期末尾，但在很多机房和公司内部系统里依然坚挺，所以这套操作短期之内不会过时。

2. 装之前必须想清楚的两件事

很多人上来就yum install adb，结果发现报错或者装出来根本不是自己想要的版本。其实在敲命令之前，有两个问题值得先花两分钟想清楚。

2.1 你需要的到底是哪个“ADB”

安卓官方的 build-tools 里面包含 adb，但是如果你只需要调试工具本身，单独下载 platform-tools 就够了，不用把整套 build-tools 拉到服务器上。

CentOS 7 自带的软件源里通常没有 adb 包，即便通过 EPEL（Extra Packages for Enterprise Linux）仓库找到了，版本也往往比较老。ADB 有一个比较气人的问题：新版本的 adb client 一般兼容旧版本的 adbd，但旧版本的 client 碰到新版本的 adbd 时，有时候会有莫名其妙的通信问题。如果你手头的设备是近几年的机型，系统是 Android 12 或者更高，老版本 ADB 很可能出现device offline或者连接不稳定。所以我的建议是，如果没有特殊兼容性要求，尽量用官方发布的 platform-tools 最新版。

另外有个容易混淆的东西叫 adb 和 adbd。前者是电脑上跑的命令行工具，后者是设备端跑的守护进程。你在这台 CentOS 机器上装的是前者。设备端你不用管，它出厂自带了，除非你做的是一些深度定制。

2.2 USB 连接和网络连接的操作差异

CentOS 7 服务器最常遇到的坑不是软件装不上，而是设备插上之后系统压根不认。这涉及三个层次：

第一层是硬件层，服务器前置 USB 接口经常供电不稳定，尤其当你用一个延长线或者 USB HUB 连接多台设备时，建议使用后置接口、独立供电的 HUB，或者像某些机架式服务器那样使用带电源的 USB 扩展卡。

第二层是内核层，CentOS 7 默认的 usb_storage 驱动和 usbhid 驱动会尝试把安卓设备当成存储设备或者 HID 设备来识别。虽然大部分情况下没有冲突，但偶尔会遇到设备被 modprobe 异常驱动干扰的情况，这时候dmesg里能看到大量 USB 错误日志。

第三层是权限层，这也是最普遍的。Linux 下的 USB 设备默认只允许 root 访问，普通用户要操作它，需要配置 udev 规则。很多人装完 adb 之后还要用 root 跑，就是因为没有做这层配置。

如果用网络连接模式，上述三层问题都能绕开，但前提是 Android 设备上打开了”无线调试”或者通过adb tcpip 5555切换到了 TCP 模式。内网环境里网络连接往往比 USB 更稳定，后面专门讲。

3. 动手安装：两个方案分别怎么选

我推荐两种方式：一种是用包管理器装现成的，省心但版本受限；另一种是手动下载官方二进制，麻烦一点但完全可控。实操中，我几乎只推荐后者，但前者在某些特殊情况下也有它的价值。

3.1 方案一：通过 EPEL 仓库安装（省心但版本较旧）

先装 EPEL 仓库：

sudo yum install -y epel-release

然后直接搜包：

yum search adb

正常情况下你能看到android-tools这个包，它包含 adb、fastboot 等工具。安装命令：

sudo yum install -y android-tools

装完之后验证：

adb version

这个方案的最大优点是干净，卸载方便，而且依赖关系由 yum 自动处理。但正如前面说的，版本可能比较老。另外在部分最小化安装的 CentOS 7 系统上，直接装 android-tools 有可能因为依赖问题报错，比如缺少libgcc或者某些 32 位库，不过这种情况在标准安装里很少遇到。

3.2 方案二：手动下载官方 platform-tools（强烈推荐）

先到 Android 开发者官网找到 Linux 版 platform-tools 的下载地址。目前获取方式基本是访问官方下载页，上面会有一个可以直接 curl 的 zip 包地址。拿到地址后，在服务器上执行：

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

如果没有 wget，用 curl 也行：

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

解压：

unzip platform-tools-latest-linux.zip

解压完会得到一个platform-tools目录，里面有两个关键文件：adb和fastboot。接下来把这两个二进制放到系统的 PATH 路径下。我习惯放在/usr/local/bin：

sudo cp platform-tools/adb /usr/local/bin/ sudo cp platform-tools/fastboot /usr/local/bin/

然后给它们可执行权限：

sudo chmod +x /usr/local/bin/adb /usr/local/bin/fastboot

为什么要放在/usr/local/bin？因为 CentOS 7 的默认 PATH 包含这个目录，而且它跟系统自带的/usr/bin不冲突，后续升级只需要覆盖这两个文件即可。有些同学想把它放到/opt或者自己创建的目录，然后在/etc/profile.d/下写一个脚本加 PATH，也完全可以，但多一个步骤就多一个出错的机会。我的原则是：能用默认路径就用默认路径，少一些自定义，服务器上出问题的概率低一些。

其实还有第三种思路：如果你不是非要用系统级的安装，直接在你自己的用户目录下解压 platform-tools，然后给~/.bashrc加个 alias 或者直接调用全路径，也能跑起来。这种方式对没有 root 权限的账号来说是最友好的。

3.3 验证安装的正确姿势

装完之后先验证一下版本：

adb version

正常输出类似：

Android Debug Bridge version 1.0.41 Version 34.0.4-10944825

版本号里的1.0.41是协议版本，所有现代 adb 都是这个值，不用太纠结。关键看后面的Version数字，这个数字越大，说明工具越新。

接下来启动 adb server：

adb start-server

然后试着看看设备：

adb devices -l

这个时候如果你还没连接设备，会看到：

List of devices attached

空荡荡的列表。别急，插上设备，继续往下看权限配置。

4. 权限配置：这一步决定了你能否正常使用

adb devices看不到设备，九成原因不是 adb 本身的问题，而是 USB 权限问题。在 CentOS 7 上，新插入的 USB 设备属于 root 所有，默认 660 权限，当前普通用户根本没资格访问它。解决方法是配置 udev 规则。

4.1 查看设备接入情况，确认 USB ID

插上安卓设备后，先用 lsusb 看看设备有没有被识别：

lsusb

输出里会有一行类似：

Bus 001 Device 002: ID 18d1:4ee7 Google Inc. Nexus/Pixel Device

看到厂商 ID（冒号前那串十六进制数）和生产 ID（冒号后那串），心里就有底了。比如常见的18d1是 Google，很多 Pixel 和 Nexus 设备都是用这个；其他的像 OnePlus 是2a70，Samsung 的有些是04e8，小米的部分设备是2717。如果你不确定自己设备的 ID 是什么，插上设备后直接看lsusb里多出来的那一行的第一列数字即可。

4.2 创建 udev 规则，让系统放行 USB 设备

用 root 创建/etc/udev/rules.d/51-android.rules：

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

写入以下规则：

SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", MODE="0666", GROUP="adbusers"

这里注意三件事：

第一，idVendor的值要跟你 lsusb 看到的厂商 ID 一致。如果你有多台不同品牌的设备，可以写多条规则，或者用通配符。不过通配符有风险，不建议写ATTRS{idVendor}=="*"，等于把所有 USB 设备的权限都放开了，服务器上的存储设备也跟着遭殃。

第二，GROUP="adbusers"这种方式需要先创建一个用户组：

sudo groupadd adbusers sudo usermod -aG adbusers $(whoami)

然后把 udev 规则里的 group 设置成这个组。这样凡是属于这个组的用户都能操作符合条件的 USB 设备。如果你只是想当前用户能用，也可以直接把 GROUP 设置成你的用户名。但服务器上以后可能有别的同事也要用，建组是更规范的做法。

第三，改完 udev 规则后要重新加载：

sudo udevadm control --reload-rules sudo udevadm trigger

然后拔掉设备重新插上，确保 udev 规则重新应用。

一个更实用的小技巧：很多教程只让你修改/etc/udev/rules.d/下的文件，但 CentOS 7 允许多个目录挂载 udev 规则。你如果不想动系统目录，可以放到/etc/udev/rules.d/同级的其他位置，然后在主配置里 include。但这属于进阶玩法，常规场景直接改规则文件足够。

4.3 重启 adb server，把权限变化应用进去

插好设备之后，先看看现在的状态：

adb devices

如果你能看到类似：

List of devices attached 18a1b2c3d4e5 device

说明权限配置生效了。如果显示的是unauthorized，那就是设备屏幕上的 RSA 指纹授权弹窗没确认。安卓从 4.2.2 开始，任何新主机连接设备时都会要求你在设备端确认信任。用 USB 连接时，设备屏幕上会弹一个对话框，问你是否允许 USB 调试，勾选”始终允许”，点确定，然后执行：

adb kill-server adb start-server adb devices

基本就能看到device状态了。

4.4 关于 SELinux 的一个重大注意事项

CentOS 7 默认开着 SELinux，这个玩意偶尔会拦截 adb server 访问 USB 设备。虽然我遇到过的情况不算多，但确实有同事被坑过：设备明明插上了，udev 规则也写了，权限也给了，adb devices就是看不到。排查半天，最后发现是 SELinux 的deny_ptrace策略卡住了。

遇到这种情况，可以先临时关闭 SELinux 试试：

sudo setenforce 0

如果这样操作之后 adb 能识别设备了，那就确认是 SELinux 的问题。更稳妥的解法是调整策略类型，而不只是简单关闭。把 SELinux 完全关掉对于生产环境的服务器来说不是一个负责任的选择。你可以针对 adb 的相关域做审计：

sudo ausearch -m avc -ts recent | grep adb

看看有没有 avc 拒绝日志，然后根据日志内容生成对应的放行策略。不过说实话，日常使用中我见到的绝大多数情况都不是 SELinux 的问题，所以这一步只作为排查方向列出来，先别急着怪它。

5. 网络调试模式：摆脱 USB 线的另一个思路

如果 USB 连接怎么弄都不顺，或者你需要同时管理几台放得比较远的设备，网络调试模式是很好的补充方案。安卓设备可以通过一条命令切换成 TCP 监听模式。

5.1 用 USB 连接一次，切换到 TCP 模式

前提是你已经能用 USB 连上设备。然后执行：

adb tcpip 5555

这条命令会让设备的 adbd 开始监听 5555 端口。之后拔掉 USB，用下面的命令连接：

adb connect <设备IP>:5555

这里的<设备IP>是安卓设备在局域网里的 IP 地址，可以在设备上的 Wi-Fi 设置里看到。连接成功后，adb devices会显示这个 IP 加端口号的条目，状态是device。

要注意的是，adb tcpip 5555这个命令在每次设备重启之后会失效。如果你希望设备长期通过网络接受 ADB 连接，可能需要借助一些第三方工具做开机自启，或者用 ADB 的 root 权限去修改系统属性。对于非 root 设备，最简单的思路是：每次需要连的时候，先在设备上用 USB 或者通过无线调试界面打开开关，再在网络请求里发起连接。这个方法对日常开发够用，但对无人值守的服务器场景来说还是要有点额外投入的。

5.2 多台设备同时连接的管理技巧

当你通过 USB 加上网络同时连了几台设备时，adb devices会列出所有设备。此时执行命令就需要指定设备序列号了：

adb -s <设备序列号> shell getprop ro.product.model

如果只连了两台，也可以用：

adb -s 192.168.1.50:5555 shell getprop ro.product.model

有一个非常实用的变量技巧，在脚本里遍历所有设备：

for device in $(adb devices | grep -w device | awk '{print $1}'); do echo "=== $device ===" adb -s $device shell date done

这个小循环能让你批量巡检所有在线的设备状态。后面进阶部分会展开讲更多批量操作玩法。

5.3 网络模式的常见坑：端口占用和连接状态漂移

TCP 模式用久了你会发现两个问题：

一是端口占用。5555 是默认端口，如果你有多个设备挂在同一台服务器上，只有一个能监听这个端口，其他设备要指定不同端口。操作方式是先adb tcpip 5556，然后连接时adb connect IP:5556。设备端的 adbd 可以同时监听多个端口吗？不行，tcpip命令会把原来的端口切走。所以多设备网络连接时，需要每台设备设一个独立的端口。

二是连接状态漂移。设备休眠、Wi-Fi 切换、网络波动，都会让adb connect的连接变成offline。这时候常规操作是先adb disconnect IP:5555再重新adb connect IP:5555，如果不行，就得先在设备上关掉再打开无线调试。

这两条经验不算什么高深技巧，但确实能帮你在排查问题时节省不少时间。

6. 常见问题排查：把能遇到的坑都摆出来

准备一张速查表，下面覆盖了我在 CentOS 7 上使用 ADB 时踩过或者帮别人排查过的绝大部分问题。

这里想单独说下no permissions这个报错里提到的plugdev组的关系。CentOS 7 默认没有plugdev组，很多系统教程是拿 Ubuntu 的思路写的，Ubuntu 里确实有 plugdev 组。在 CentOS 7 上，别去现造一个 plugdev 组，直接用你自己建的那个组就好。

另一个值得提醒的问题是关于 USB HUB 的。很多服务器管理员习惯把多台测试手机插在一个集线器上。便宜的无源 HUB 供电不足会间歇性掉线，表现为adb devices列表里的设备一会儿在，一会儿不在。我自己就碰到过一晚连掉三次的情况。解决方案只有两个：换有源 HUB，或者尽量用主板上的直连 USB 口。

还有一个常见但容易被忽略的情况：CentOS 7 服务器上的 USB 3.0 接口和部分安卓设备的 USB 2.0 兼容性有问题，插在蓝色接口上反而不识别，插黑色接口就很好。目前没找到特别规律的解释，遇到了就换接口试试，不用纠结原理。

7. 批量操作与后续玩法

ADB 装好、权限配好、设备连上之后，真正有意思的部分才刚开始。一台 CentOS 7 服务器上挂载一群安卓设备，能干的事情非常多，挑几个实际有用的场景说说。

7.1 批量安装 APK 到所有设备

假设你构建出了一个测试包app-debug.apk，要装到所有在线设备上：

for device in $(adb devices | grep -w device | awk '{print $1}'); do echo "Installing to $device" adb -s $device install -r app-debug.apk done

-r参数表示允许覆盖安装，保留数据。这是自动化测试简报里最常见的操作，几乎每个搞安卓自动化的人都写过这个循环。

7.2 批量抓取设备日志

设备出问题时候要抓 logcat，多设备时把所有日志按设备名分文件存储：

mkdir -p logs for device in $(adb devices | grep -w device | awk '{print $1}'); do adb -s $device logcat -c adb -s $device logcat > logs/${device}.log 2>&1 & done

注意最后那个&是让抓日志的任务后台跑，不然脚本会卡在第一个设备的日志流里出不来。另外，先logcat -c清掉缓存，能帮你拿到一个干净的时间窗口。

7.3 通过 scrcpy 远程控制设备

如果你需要在服务器端直接看到设备屏幕、操作设备，配套神器是 scrcpy。它需要 adb 已经正常连接设备，然后在服务器上跑：

scrcpy --serial <设备序列号>

没有图形界面的 CentOS 7 服务器跑 scrcpy 需要 X11 转发或者 VNC 环境，稍微有点绕。但如果你手头有个图形化的内网桌面环境，scrcpy 的体验会非常接近坐在设备前操作。对于远程问题排查和演示场景非常实用。

7.4 写一个简单的设备巡检脚本

日常维护中最烦的事情是设备偷偷掉线了没人发现。可以写个非常简单的巡检：

#!/bin/bash # 简单的 ADB 设备巡检脚本，线上失联设备直接告警 while true; do alive=$(adb devices | grep -w device | wc -l) total=8 if [ "$alive" -lt "$total" ]; then echo "$(date): 在线设备 $alive/$total，有设备掉线" # 这里可以接邮件或 IM 通知 fi sleep 60 done

这个脚本虽然简陋，但胜在直接有效。对一个跑着自动化任务的环境来说，及时知道设备掉线，往往比事后翻日志效率高得多。

8. 写到最后，一些个人经验和提醒

我在多台 CentOS 7 服务器上配过 ADB，也帮别人修复过各种稀奇古怪的问题。如果只给一条建议，那就是：从官方下载 platform-tools 并用 udev 规则配好权限，这套组合最稳，能绕开绝大多数网上流传的错误配置。

还有两点实操细节想多说一句。

第一，记得把adb和fastboot都放在系统路径里。fastboot 这个工具平时用得少，但一旦设备变砖需要刷机或者解锁 bootloader 时，它就是你唯一的救星。顺手放进去，占用不了多少空间。

第二，关于服务器重启的问题。服务器重启之后，adb server 不会自动启动，需要你手动执行adb start-server或者第一条 adb 命令会自动拉起。如果你希望开机自动连接所有设备，可以在/etc/rc.local里加一行：

/usr/local/bin/adb start-server

这个做法在 CentOS 7 上需要先确保 rc.local 有执行权限：

sudo chmod +x /etc/rc.d/rc.local

加了这行之后，服务器只要开机，adb server 就会准备就绪，设备插上就能用。

最后再说一个容易被忽略的小技巧：如果你有多台设备，每台设备在adb devices里看到的序列号跟设备里的设置不一定对得上，序列号可能是一串随机字符，也可能是设备型号。如果设备支持，你可以通过adb -s <序列号> shell settings put global device_name "自定义名称"来重命名设备，这样在批量管理时一眼就能看出哪台是哪台。这个操作不是所有设备都支持，但试一下总没坏处。

CentOS 7 + ADB 这套组合，说简单是真简单，几条命令就能跑起来；说麻烦也真麻烦，权限、SELinux、USB 供电、版本匹配，每个点都能卡住人。但只要把基础打牢，后面跑自动化也好，做设备管理也好，都会顺畅很多。