很多从 Windows 转到 Ubuntu 的 Android 开发者第一个不适应的往往不是 IDE而是 ADB。在 Windows 上装 ADB下载压缩包、解压、加环境变量三步就结束了。到了 Ubuntu 上很多人会卡在“包名是什么”“设备没权限”“一直 unauthorized”这些看起来很小、却极其磨人的问题上。更麻烦的是网上的教程版本混乱有的让你装android-tools-adb有的让你装adb有的直接让你去下载 platform-tools新手很容易被绕晕。先说一个明确判断在 Ubuntu 中安装 ADB 这件事本身并不难真正的分水岭在安装之后的设备连接与权限授权。很多教程只教到adb version能输出版本号就结束了但读者真正想解决的问题是手机连上电脑后能跑adb devices、能装 APK、能抓日志。这篇文章会把安装、配置、连接、授权、排错这条完整链路讲清楚并且在最后给出我在实际工程中认为比较稳妥的实践建议。读完本文你能完成三件事第一在自己的 Ubuntu 机器上装好可用的 ADB 工具第二成功连接 Android 手机、模拟器或开发板并完成授权第三遇到no permissions、unauthorized、offline这类高频报错时知道按什么顺序排查。这篇文章以 Ubuntu 22.04 LTS 为主要演示环境但绝大多数操作同样适用于 20.04、24.04 等版本。1. 为什么要在 Ubuntu 上安装 ADB先想清楚一个问题你装 ADB 到底是为了什么不同人的需求完全不同但最终都会落到同一个工具上。对于 Android 应用开发者来说ADB 是日常调试的基础设施。你要装测试包、清缓存、看日志、模拟点击、抓取系统状态这些都离不开adb命令。没有 ADBAndroid Studio 的很多能力也会被削弱因为 IDE 底层依然是通过 ADB 与设备通信。对于自动化测试工程师来说ADB 是脚本与设备之间的桥梁。Appium 等框架通过 ADB 驱动设备执行操作CI 环境里跑测试任务也需要 ADB 预先连接设备。很多时候测试环境是 Linux 服务器不装好 ADB整个流水线就跑不起来。对于嵌入式、智能硬件开发者和极客用户来说ADB 是进入设备系统的钥匙。开发板、电视盒子、智能音箱、车机系统很多都基于 Android 或类 Android 系统厂商会开放 ADB 调试接口。通过adb shell可以直接在设备上执行命令、查看日志、拷贝文件效率远高于在设备端手动操作。这里有一个很多教程没有点破的事实Ubuntu 下装 ADB重点不是“安装”这个动作而是安装之后怎么解决设备识别和权限问题。Windows 下设备驱动通常由厂商提供安装包装完就能识别。Linux 下依靠 udev 规则和 USB 权限体系如果没有正确配置即使 ADB 安装成功设备也会显示为no permissions或干脆不出现。这一点会在第 6 章详细展开。什么读者最适合看这篇文章我认为是以下几类第一次在 Linux 上做 Android 开发的初学者、需要在 CI 或远程服务器上配置 ADB 的测试开发工程师、以及玩开发板和智能硬件的爱好者。如果你只是想在 Ubuntu 上用模拟器跑adb命令这篇文章同样适用。2. ADB 是什么——先理解再动手ADB 全称 Android Debug Bridge中文通常翻译为“安卓调试桥”。它不是一个单一的程序而是一套客户端-服务端-守护进程的通信架构。从组成上看ADB 包含三个部分组成部分角色说明adb client客户端运行在电脑上用户敲击的adb命令就是这个客户端adb server服务端后台进程管理客户端与设备之间的通信负责发现和监控设备adbd守护进程运行在 Android 设备上接收来自电脑端的命令并执行当你执行adb devices时实际发生的流程是客户端启动或连接本机的 adb serverserver 通过 USB 或网络找到设备再与设备上的 adbd 建立通信最后把设备列表返回给客户端。这个架构设计的好处是多个客户端命令可以复用同一个 server 连接效率更高状态管理也更集中。缺点是当 server 状态异常时设备可能显示为offline或干脆无法连接这时候第一反应应该是重启 adb server而不是重启电脑。ADB 的工作模式主要有两种。一种是 USB 模式。手机通过 USB 线连接电脑这是最常用、最稳定的方式。只要驱动和权限没问题adb devices就能看到设备。另一种是无线模式适合已经通过 USB 连接过一次、并执行过adb tcpip命令的设备。之后可以在同一局域网内通过网络连接设备适合调试手表、电视盒子这类不方便一直插线的设备。用一个类比来帮助理解ADB 就像是你和 Android 设备之间的一座桥。你的电脑是桥的一端设备是另一端桥上的管理和调度由 adb server 负责。如果桥没搭好——也就是 server 没有正确识别设备——那么你在这边喊破嗓子设备那边也听不见。弄清楚了 ADB 的底层架构再去看安装步骤你会更容易理解每一步到底在做什么。比如配置环境变量是为了让 shell 能找到 adb client配置 udev 规则是为了让当前用户有权限访问 USB 设备接受 RSA 指纹是为了建立电脑与设备之间的信任关系。这些步骤不是割裂的而是一条完整链路。3. 环境准备与前置条件在开始安装之前先检查一下环境是否满足条件。很多安装失败并不是因为步骤不对而是前置条件没准备好。3.1 Ubuntu 系统版本本文以 Ubuntu 22.04 LTS 为主要演示环境。20.04、24.04 的操作基本一致只是在软件包名称上略有差异后面会专门说明。先确认系统版本lsb_release -a如果输出中的Release是22.04或24.04使用sudo apt install adb即可。如果是 20.04 或更早版本软件源里对应的包名是android-tools-adb。写到这里我要特别提一句很多人在 22.04 上执行sudo apt install android-tools-adb发现提示找不到包于是怀疑是源的问题其实不是只是包名变了。这是新手最容易困惑的细节。3.2 Android 设备开启 USB 调试准备一台 Android 手机或平板作为测试设备。在设备上开启“开发者选项”和“USB 调试”这是连接的前提。不同品牌、不同 Android 版本路径略有不同但通用路线是打开“设置”找到“关于手机”。连续点击“版本号”7 次直到提示已进入开发者模式。返回设置主界面进入“开发者选项”。打开“USB 调试”开关。如果设备是电视盒子、开发板等非手机设备一般也有对应的开发者模式入口通常在“设置 - 关于”里连点版本号。具体路径可以在设备厂商的官方文档中确认。3.3 检查 USB 线缆与接口这一步极其重要但常常被忽略。很多所谓的“连不上设备”最后的罪魁祸首是一根只能充电、不能传数据的 USB 线。判断方法很简单把手机连接到电脑在手机端看 USB 连接选项里是否出现“文件传输”或“MTP”模式。如果只有“充电”大概率是线的问题换一根数据线再试。另外建议优先使用电脑机箱后置 USB 接口尤其是台式机。前置接口可能供电不足或信号质量差导致设备识别不稳定。3.4 准备必要工具安装过程中需要用到wget、unzip、vim或nano等工具。Ubuntu 桌面版一般自带wget但unzip可能需要单独安装sudo apt update sudo apt install -y unzip如果后续要编辑 udev 规则文件nano对新手更友好没有安装的话可以用下面的命令sudo apt install -y nano环境准备看起来琐碎但确实验证下来是省时间的。跳过这一步直接装 ADB 的后果是装到一半发现解压工具没有或者设备连上后无法识别排查半天才发现是线的问题。4. Ubuntu 安装 ADB 的三种方式在 Ubuntu 中安装 ADB最常见的有三种方式从易到难分别是apt 软件包安装、官方 platform-tools 手动安装、源码编译安装。我建议普通用户优先使用前两种其中 apt 方式最简单官方手动方式最灵活。4.1 方式一apt 软件包安装推荐新手apt 安装最大的优点是省心。依赖关系由包管理器处理升级也方便而且安装完的adb命令直接进入系统 PATH不需要额外配置环境变量。Ubuntu 22.04 及更新版本执行sudo apt update sudo apt install adbUbuntu 20.04 及更早版本执行sudo apt update sudo apt install android-tools-adb如果提示找不到包可以先执行sudo apt update刷新软件源再检查包名是否与系统版本对应。这里有一个需要提醒的点apt 仓库中的 ADB 版本通常落后于 Google 官方发布的版本。对于日常调试影响不大但如果你的设备 Android 版本较新或者需要用到最新修复的 bug建议改用下面的手动方式。安装完成后先验证一下adb version如果输出版本信息说明安装成功。4.2 方式二官方 platform-tools 手动安装推荐进阶官方手动来源是 Google 发布的 Android SDK Platform-Tools 压缩包里面包含adb、fastboot等工具。这种方式优点是版本最新、来源可靠缺点是安装路径和环境变量需要自己配置。第一步下载最新版 platform-tools。官方下载地址始终保持 latest 链接下载前建议先确认网络环境可以正常访问dl.google.comcd ~/Downloads wget https://dl.google.com/android/repository/platform-tools-latest-linux.zip第二步解压并移动到统一管理目录。我习惯把这类手动安装的工具放在/opt下方便多用户共用unzip platform-tools-latest-linux.zip sudo mv platform-tools /opt/第三步配置环境变量。使用以下命令打开~/.bashrcnano ~/.bashrc在文件末尾添加一行export PATH$PATH:/opt/platform-tools保存后执行source ~/.bashrc然后验证adb version如果输出版本信息说明安装成功。这种方式的优点是可以随时手动更新整个platform-tools目录且与 Android Studio 自带的 SDK 工具解耦。4.3 方式三源码编译安装不推荐普通用户从 AOSP 源码编译 ADB 需要下载完整源代码、配置编译环境耗时很长。对绝大多数场景来说收益远低于成本。如果不是在研究 ADB 源码实现或者定制工具没有必要走这条路。这里不过多展开。4.4 三种方式对比安装方式难度版本优点缺点apt低随系统版本命令自动进 PATH升级方便版本可能滞后官方 platform-tools中最新版本新路径可控需要手动配环境变量源码编译高最新可定制耗时长依赖复杂我的建议是刚开始接触 Ubuntu 和 ADB 的读者直接用 apt 方式先把流程跑通这时候没必要在环境变量上给自己增加负担。等到需要更新版本或做更深入的调试时再切换到官方 platform-tools 方式。两个方式可以共存但要注意 PATH 顺序避免误用了旧版本。5. 环境变量配置与安装验证环境变量配置只对手动安装方式必要但这一章值得单独写因为“命令找不到”是 Ubuntu 下仅次于设备权限的高频问题。5.1 理解 PATH 机制当你在终端输入adb时shell 会按照 PATH 环境变量中定义的目录顺序逐个查找名为adb的可执行文件。如果找不到就会提示adb: command not found。apt 安装的adb位于/usr/bin/adb这个目录默认就在 PATH 中所以不需要额外配置。手动安装如果放在/opt/platform-tools则必须把这个目录加入 PATH。5.2 配置方法网上有很多配置环境变量的教程但写法五花八门有的写~/.bashrc有的写~/.profile有的写/etc/profile。这里做一个区分~/.bashrc仅对当前用户的 bash 终端生效每次打开终端都会加载是个人使用时的首选。~/.profile仅对当前用户生效在登录 shell 时加载。如果使用某些非 bash 的桌面终端可能需要配置这个文件。/etc/profile全局生效所有用户都会加载需要 sudo 权限一般不推荐普通用户修改。对于大多数开发者来说把 export 语句追加到~/.bashrc末尾就足够了echo export PATH$PATH:/opt/platform-tools ~/.bashrc source ~/.bashrc配置完成后用which adb确认命令来源which adb如果输出/opt/platform-tools/adb说明 PATH 配置正确。如果输出/usr/bin/adb说明系统优先使用了 apt 版本。5.3 同时存在多个 adb 时如何取舍当你既安装了 apt 版又手动安装了官方版系统会按照 PATH 顺序选择先找到的那个。排查问题时要先确认当前实际使用的是哪个 adb否则可能出现“我觉得我已经升级了但实际跑的仍然是旧版本”的情况。确认当前使用路径which adb adb version如果发现当前路径不是自己想要的可以通过调整~/.bashrc中的 PATH 顺序来解决。一般来说把官方platform-tools目录放在 PATH 前面可以优先使用版本较新的官方工具export PATH/opt/platform-tools:$PATH这里把/opt/platform-tools放在前面覆盖了后面/usr/bin中的同名命令。5.4 验证安装结果无论使用哪种安装方式最终都要验证两个信息版本和可执行性。adb version预期输出类似Android Debug Bridge version 1.0.41 Version 35.0.2-12147458只要输出了版本号说明 ADB 工具已经安装成功。接下来要验证的才是重点——能否连接设备。6. 连接 Android 设备并完成授权这一章是全文的核心。很多人在前面安装都很顺利到了adb devices这一步就卡住了。不要着急这一章的排查思路能帮你解决大部分问题。6.1 连接 USB 并查看设备 ID先用 USB 线将手机连接到电脑然后在终端执行lsusb输出中会列出所有连接的 USB 设备。找到你的手机厂商对应的一行例如 Google 的设备可能是Bus 001 Device 004: ID 18d1:4ee7 Google Inc. Nexus/Pixel18d1就是设备的 vendor ID后面会用到。不同厂商的 vendor ID 不同请以lsusb实际输出为准。6.2 配置 udev 规则Linux 下如果未配置规则普通用户访问 USB 设备时经常会被拒绝ADB 设备会显示为no permissions。这一步就是解决权限问题的。创建一个 udev 规则文件sudo nano /etc/udev/rules.d/51-android.rules文件内容如下请将18d1替换为你在上一步查到的 vendor IDSUBSYSTEMusb, ATTR{idVendor}18d1, MODE0666, GROUPplugdev保存后执行sudo chmod ar /etc/udev/rules.d/51-android.rules sudo udevadm control --reload-rules sudo udevadm trigger然后拔出 USB 线重新插入再执行adb kill-server adb deviceskill-server的目的是让 adb server 重新读取设备状态这一步在设备权限变更后尤其重要。6.3 接受 RSA 指纹授权如果一切顺利第二条命令执行后手机屏幕上会弹出一个“允许 USB 调试吗”的对话框并显示电脑的 RSA 密钥指纹。勾选“始终允许使用这台计算机进行调试”点击允许。然后在电脑端再次执行adb devices输出中的设备状态应该是device而不是unauthorized或offlineList of devices attached XXXXXXXX device记住这个状态的差异device表示设备连接正常且已授权unauthorized表示设备已识别但尚未授权offline表示设备通信异常通常需要重启 adb server 或换线。6.4 无线连接方式某些场景下不方便使用 USB 线比如调试电视盒子、手表或者设备在远程机房。无线连接需要先通过 USB 建立信任关系。第一步USB 连接设备并确认adb devices显示设备正常。第二步让 adb 以 TCP 模式监听某个端口adb tcpip 5555第三步查看设备在局域网中的 IP 地址。可以在设备上打开“设置 - WLAN - 查看详情”也可以直接在 adb shell 中执行adb shell ip addr show wlan0找到类似192.168.1.100的地址后拔出 USB 线执行adb connect 192.168.1.100:5555如果连接成功adb devices中会显示192.168.1.100:5555且状态为device。无线方式适合日常调试但第一次连接必须用 USB 完成授权这是 Android 系统层面的安全设计。6.5 连接模拟器如果你使用的是 Genymotion、Linux 版 Android 模拟器或者第三方模拟器ADB 连接方式略有不同。大多数模拟器会自动注册到 adb server启动后直接执行adb devices通常就能看到模拟器设备。如果看不到可以尝试使用模拟器提供的 adb connect 端口例如adb connect localhost:5554不同模拟器的默认端口不同请以模拟器官方文档为准。7. ADB 常用命令与典型开发场景安装和连接都成功后接下来看一些日常开发中经常用到的命令。这里不做全量命令手册式罗列只挑能解决实际问题的核心场景。7.1 设备管理查看已连接的设备adb devices -l-l参数会显示设备的型号、系统版本等详细信息在多设备场景下很有用。当同时连接多个设备时指定目标设备执行命令adb -s 设备序列号 shell序列号可以通过adb devices查看。重启 adb server 的标准操作遇到设备状态异常时先用这招adb kill-server adb start-server7.2 安装与卸载应用安装 APK 是最高频的需求之一adb install app.apk如果要安装到指定设备并允许降级安装adb -s 设备序列号 install -r -d app.apk-r表示覆盖安装保留数据-d表示允许版本降级。卸载应用adb uninstall com.example.package这里的包名是应用的 applicationId不是应用名称。可以通过以下命令查看手机上已安装的包名adb shell pm list packages7.3 文件传输从电脑推送到设备adb push local_file.txt /sdcard/从设备拉取到电脑adb pull /sdcard/screenshot.png ~/Desktop/这个操作在抓取日志和导出崩溃现场时非常有用。7.4 日志分析查看实时日志adb logcat按标签过滤只看某个模块的输出adb logcat -s AndroidRuntime:E清除旧日志再从某个关键操作开始抓取adb logcat -c7.5 截图与录屏截图并直接拉回电脑adb exec-out screencap -p screenshot.png录屏 10 秒adb shell screenrecord --time-limit 10 /sdcard/demo.mp47.6 进入 shell 执行命令进入设备 shelladb shell不进入交互模式直接执行单条命令adb shell getprop ro.build.version.release查看设备 CPU 架构这在选择二进制文件时很有用adb shell uname -m8. 常见问题与排查方法这一章把我在日常使用中遇到的高频问题整理成表方便你按图索骥。每个问题都给出了从最可能原因开始的排查路径。问题现象可能原因排查方式解决方案adb: command not foundADB 未安装或 PATH 未配置执行which adb查看是否存在安装 ADB 或配置 PATHno permissions (user in plugdev group; are your udev rules wrong?)缺少 udev 规则或权限不足执行lsusb查看 vendor ID配置 udev 规则并重载unauthorized设备未接受 RSA 指纹授权查看手机屏幕是否有调试弹窗在手机上勾选允许调试offlineadb server 状态异常或 USB 不稳定执行adb kill-server后重试重启 adb server换 USB 线设备未出现在adb devicesUSB 线不支持数据传输更换数据线更换为支持数据传输的 USB 线设备列表为空但lsusb能看到USB 调试未开启或模式不对检查设备开发者选项开启 USB 调试切换 USB 模式执行adb devices卡住无输出adb server 进程异常查看是否被系统防火墙拦截杀掉 adb 进程后重试这里特别说明一个常见误区adb: createfilew nul failed: 系统找不到指定的文件这个报错通常出现在 Windows 的 cmd 或 PowerShell 中原因是命令中使用了 Linux 风格的nul设备重定向而 Windows 识别不了。如果你在 Ubuntu 下看到这个提示先确认一下是不是用错了终端或者复制了 Windows 下的脚本。真正在 Linux 下运行 ADB不应该出现这种报错。另一个值得关注的问题是adb devices显示两个设备其中一个是模拟器另一个是实体手机。此时所有命令默认会在多个设备之间选择如果不加-s参数会提示more than one device/emulator。解决办法就是指定序列号adb -s emulator-5554 shell排查问题最忌讳的是没有章法地乱试。建议按这个顺序来先确认 ADB 是否安装成功再确认 USB 线是否支持数据传输然后检查设备是否开启调试接着配置 udev 规则最后看 RSA 授权状态。绝大多数问题都出在这五步之内。9. 最佳实践与工程建议工具装好只是起点怎么用得更稳、更规范是工程师之间拉开差距的地方。这里分享几点实践建议。9.1 固定使用官方 platform-tools 版本apt 版本胜在方便但如果你处于长期开发状态并且需要和 Android Studio 的 SDK 工具保持一致性建议改为官方 platform-tools。原因有两个一是版本更新及时可以跟上 Android 新版本二是fastboot等工具也跟着一起更新刷机场景下不会出现版本不匹配的问题。升级官方 platform-tools 的方式也很简单下载最新压缩包覆盖/opt/platform-tools即可最终命令路径无需变化。9.2 把常用调试命令封装成脚本日常开发中经常重复的 ADB 操作可以写成简化脚本。例如在~/.bashrc中增加函数function apk_install() { adb install -r $1 } function apk_uninstall() { adb uninstall $1 } function screen_cap() { adb exec-out screencap -p screen_$(date %Y%m%d_%H%M%S).png }这样执行apk_install app.apk、screen_cap就会自动带上常用参数减少重复输入。9.3 使用 udev 规则时按厂商区分如果你有多个品牌的测试机不要把所有设备都配成同一套规则。更推荐的方式是每类设备单独写一行或单独规则文件方便隔离和排查。例如SUBSYSTEMusb, ATTR{idVendor}18d1, MODE0666, GROUPplugdev SUBSYSTEMusb, ATTR{idVendor}2a70, MODE0666, GROUPplugdev注意修改规则后不仅要在电脑端 reload还要重新插拔 USB 线让设备重新枚举规则才会生效。9.4 关注安全与授权边界ADB 一旦授权电脑就拥有了对设备的高权限控制能力包括安装应用、读取文件、执行 shell 命令。因此有几点提醒第一不要随意在公共电脑上连接个人手机并勾选“始终允许”。如果只是临时调试可以在授权时取消勾选“始终允许”这样断开后授权就会失效。第二连接到未知的电脑时留意设备端弹出的 RSA 指纹提示。只接受你自己可信电脑的授权请求。第三涉及adb shell下的高权限操作时先在测试设备上验证避免在生产设备上误删数据或改坏系统配置。特别是adb shell rm这类危险命令务必确认路径后再执行。9.5 在 CI 环境中使用 ADB 的注意事项如果你的 ADB 要在 CI 服务器或 Docker 容器中运行有几个额外配置需要注意Docker 容器内使用 USB 设备通常需要--privileged参数或绑定设备节点否则adb devices看不到实体设备。如果使用无线连接模拟器或远程设备需要确保容器网络与目标设备互通。另外CI 环境建议使用稳定的 platform-tools 版本并在构建脚本中固化版本号避免某天 Google 更新压缩包后构建环境出现意外变化。10. 总结与后续学习方向这篇文章从实际痛点出发讲清楚了三条主线Ubuntu 下 ADB 的安装方式、设备连接授权的完整链路、以及高频问题的排查思路。如果你完整跟着操作了一遍现在应当能独立完成从零安装 ADB、连接手机、接受授权、执行调试命令的整个过程。把整篇文章浓缩成一句话Ubuntu 安装 ADB 不难难的是理解安装之后的设备识别与权限机制只要掌握了 udev 规则、RSA 授权和 adb server 状态管理这三个关键点绝大多数坑都能迎刃而解。接下来的学习方向建议按需选择如果做 Android 应用开发可以深入学习adb shell am和adb shell pm命令掌握通过命令行启动 Activity、管理应用权限等高级能力。如果从事自动化测试可以研究adb shell input和adb shell sendevent这对模拟点击和按键事件很有帮助。如果玩嵌入式设备建议补充fastboot工具的使用它与 ADB 配合用于刷机和分区操作。另外建议收藏一份官方的platform-tools更新地址和 ADB 命令参考文档需要时随时查阅。实际工程中把 ADB 用熟是一项长期收益很高的投入它会让你的 Android 开发调试效率提升一个档次。