1. 项目概述：为什么要在WSL里折腾ADB？

如果你是一个经常在Windows和Linux之间切换的Android开发者，或者是一个喜欢折腾各种手机工具、自动化脚本的极客，那么“在WSL里安装ADB”这个需求，你大概率已经遇到过，或者即将遇到。ADB，全称Android Debug Bridge，是Google官方提供的、与Android设备进行通信的瑞士军刀。从最基本的安装卸载应用、传输文件，到高级的屏幕截图、录屏、甚至刷机、调试系统底层，都离不开它。

那么问题来了：Windows本身就有完善的ADB工具链，为什么还要费劲在WSL里再装一套？这背后其实有几个非常实际的痛点。首先，开发环境的一致性。很多Android开发的核心工具链，比如Gradle构建脚本、某些自动化测试框架，或者你写的Shell/Python脚本，在纯Linux环境下运行是最顺畅、最“原生”的。在Windows的CMD或PowerShell里调用这些脚本，常常会遇到路径分隔符（\vs/）、环境变量、甚至字符编码的“玄学”问题。把ADB装进WSL，意味着你的整个开发、调试、自动化流程都可以在一个统一的Linux环境中完成，脚本写起来顺手，排错也简单。

其次，终端操作的效率与体验。WSL提供的终端（无论是Windows Terminal还是其他）配合Zsh、Bash等Shell，在命令补全、历史记录、管道操作等方面的体验，对于习惯Linux命令行的人来说，远比Windows传统终端要友好得多。在WSL里直接敲adb命令，感觉更“对味”。

最后，也是最重要的一点：USB设备的穿透问题。这是WSL使用ADB最大的拦路虎，也是本文要重点攻克的核心。WSL本身是一个在Windows上运行的Linux兼容层，它默认无法直接访问宿主机的USB硬件。这意味着，即便你在WSL里安装了ADB，当你用USB线连接手机时，WSL里的ADB服务也“看”不到你的设备。解决这个“最后一公里”的连接问题，正是整个安装配置过程中的关键所在。

所以，这个项目不仅仅是运行一条apt install命令那么简单。它是一个系统工程，目标是在WSL这个“套娃”环境里，搭建一个能无缝识别并调试真实Android设备的完整ADB工作环境。接下来，我会带你一步步拆解，从原理到实操，从安装到排错，彻底搞定它。

2. 核心思路与方案选型：USB连接是灵魂

在WSL里配置ADB，核心任务可以拆解为两个独立又关联的部分：在WSL内部安装ADB客户端与守护进程，以及建立WSL与Windows宿主机之间USB设备的通信桥梁。前者很简单，后者才是真正的挑战。

2.1 WSL内部ADB安装方案

在Linux发行版中安装ADB，通常有三种主流方式：

1. 使用发行版包管理器（推荐）：例如在Ubuntu/Debian系的WSL中，直接使用apt安装adb和android-sdk-platform-tools-common包。这是最干净、最易于管理（更新、卸载）的方式，也是官方推荐的做法。
2. 手动下载SDK Platform-Tools：从Google开发者网站下载包含ADB的压缩包，解压后手动配置环境变量。这种方式更灵活，可以获取最新版本，但需要手动管理更新。
3. 通过Snap等通用包管理器：在某些发行版中也可以通过Snap安装。

对于WSL环境，我强烈推荐第一种方式——使用系统包管理器安装。原因在于，WSL环境通常用于开发，保持与标准Linux发行版一致的管理习惯，能减少很多不必要的麻烦。通过apt安装，所有文件都会放在标准位置（如/usr/bin/adb），依赖关系也会自动处理。手动下载的方式虽然可行，但在WSL中管理路径和更新略显繁琐，除非你有特定版本需求。

2.2 USB连接方案选型：TCP/IP vs USB/IP

要让WSL里的ADB识别到USB设备，我们必须借助Windows宿主机的力量。主流方案有两个：

方案一：TCP/IP连接（最常用、最稳定）这是目前公认的最佳实践。其核心原理是：在Windows宿主机上运行ADB服务器，并让其监听一个TCP端口（如5037）。然后，在WSL内部，我们配置ADB客户端去连接这个位于Windows端的服务器。这样，所有USB设备的枚举、连接、通信都由Windows端的ADB服务负责，WSL端的ADB客户端只是作为一个“远程控制台”发送指令。这种方式的优势非常明显：

• 稳定可靠：利用了Windows原生对USB设备的完美支持，避开了WSL直接访问USB的复杂性和不稳定性。
• 配置简单：只需要在Windows和WSL两端做简单的网络配置即可。
• 支持热插拔：设备连接Windows后，WSL端能立即识别。
• 一机多端：同一个ADB服务器可以被多个客户端（如WSL、Windows命令行）同时连接。

方案二：USB/IP项目（原生但复杂）这是一个开源项目，旨在通过网络共享USB设备。理论上，你可以在Windows端将USB设备“共享”出来，然后在WSL端作为一个网络USB设备“连接”上去。这种方式更“原生”，WSL系统会认为直接连接了一个USB设备。然而，在实践中，我强烈不推荐新手或追求稳定性的用户使用此方案。原因如下：

• 配置极其复杂：需要在Windows端安装驱动、配置服务，在WSL端编译或安装客户端内核模块。
• 稳定性欠佳：对设备和系统版本敏感，容易出现连接断开、驱动冲突等问题。
• 性能开销：所有的USB数据都要经过网络协议封装和解封装，有一定性能损耗。

结论：毫不犹豫地选择TCP/IP连接方案。它完美地契合了WSL的设计哲学——与宿主机Windows协同工作，而不是试图取代它。我们接下来的所有步骤，都将围绕这个方案展开。

3. 详细安装与配置实操

我们将整个流程分为三个阶段：Windows端准备、WSL端安装、以及最终的连接与验证。

3.1 第一阶段：Windows宿主机的准备

这一阶段的目的是在Windows上建立ADB服务器，并确保它能被WSL访问。

步骤1：安装或更新Windows版ADB如果你已经在Windows上使用过ADB（例如通过Android Studio），那么它可能已经存在。但为了确保版本一致性和最佳兼容性，建议从官方渠道获取。

1. 访问 Google Android开发者网站 ，下载“SDK Platform-Tools for Windows”压缩包。
2. 解压到一个你喜欢的路径，例如D:\Android\platform-tools。记住这个路径。
3. （关键）将ADB添加到Windows系统环境变量PATH中：
   • 在Windows搜索框输入“环境变量”，选择“编辑系统环境变量”。
   • 点击“环境变量”按钮。
   • 在“系统变量”部分，找到并选中Path变量，点击“编辑”。
   • 点击“新建”，将你的platform-tools目录路径（例如D:\Android\platform-tools）添加进去。
   • 一路点击“确定”保存。
4. 验证：打开一个新的Windows命令提示符（CMD）或PowerShell，输入adb version。如果能看到版本号输出，说明安装成功。

步骤2：配置Windows防火墙（允许ADB通信）这是让WSL能够连接到Windows ADB服务器的关键一步。ADB服务器默认监听本机的5037端口。我们需要确保Windows防火墙允许入站连接（至少来自本机）。

1. 以管理员身份打开Windows PowerShell。
2. 运行以下命令，为ADB服务器创建防火墙入站规则：

   New-NetFirewallRule -DisplayName "ADB Server (TCP-In 5037)" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 5037

   这条命令创建了一条规则，允许任何来源（包括WSL）的TCP连接访问本机的5037端口。

   注意：如果你对安全有极高要求，可以将-Action Allow改为更严格的规则，但家庭或开发环境通常允许即可。

步骤3：启动Windows ADB服务器并设置为TCP模式

1. 在刚才的PowerShell或新的CMD中，执行以下命令：

   adb kill-server # 先停止可能已存在的服务器 adb -a -P 5037 nodaemon server start # 在5037端口启动服务器，并允许网络连接

   • -a参数表示在所有网络接口上监听。
   • -P 5037指定端口。
   • nodaemon和server start以前台模式启动服务器。
2. 执行后，命令行会挂起，显示* daemon not running; starting now at tcp:5037，这表示服务器已在后台运行并监听。你可以按Ctrl+C中断这个前台命令，服务器会转入后台继续运行。或者，更简单的方式是直接运行adb start-server，它会以后台守护进程方式启动。

至此，Windows端的准备工作就完成了。你的Windows现在是一个正在监听5037端口的ADB服务器。

3.2 第二阶段：WSL内部的安装与配置

现在，我们切换到WSL的Linux环境中。

步骤1：更新软件源并安装ADB

1. 打开你的WSL终端（例如Ubuntu）。
2. 首先更新包列表，然后安装adb和相关的工具包：

   sudo apt update sudo apt install android-tools-adb android-tools-fastboot

   android-tools-fastboot通常会和adb一起安装，用于设备刷机等操作，建议一并安装。

步骤2：配置WSL的ADB客户端连接至Windows默认情况下，WSL中的adb命令会尝试启动一个本地（WSL内部）的ADB守护进程。我们需要告诉它，去连接Windows那边的服务器。

1. 在WSL终端中，设置环境变量ADB_SERVER，指向Windows宿主机的IP地址和端口。这里有一个关键技巧：如何获取Windows在WSL网络中的IP地址？WSL2为Windows宿主机提供了一个特殊的域名：host.docker.internal（实际上源于Docker Desktop的遗留，但在WSL2中普遍可用）。更通用的方法是使用/etc/resolv.conf中指定的DNS服务器地址，它通常就是宿主机的IP。一个可靠的方法是使用grep命令：

   export ADB_SERVER=$(grep nameserver /etc/resolv.conf | awk '{print $2}'):5037

   这条命令会提取出宿主机的IP（例如172.25.32.1），然后拼接上端口号5037，赋值给ADB_SERVER环境变量。
2. 为了让这个配置永久生效，而不是每次打开终端都设置，我们需要将上面这行命令添加到你的Shell配置文件中。
   • 如果你使用Bash（默认），编辑~/.bashrc文件：

     echo "export ADB_SERVER=\$(grep nameserver /etc/resolv.conf | awk '{print \$2}'):5037" >> ~/.bashrc

   • 如果你使用Zsh，编辑~/.zshrc文件：

     echo "export ADB_SERVER=\$(grep nameserver /etc/resolv.conf | awk '{print \$2}'):5037" >> ~/.zshrc

3. 让配置立即生效：

   source ~/.bashrc # 或 source ~/.zshrc

4. 验证环境变量是否设置成功：

   echo $ADB_SERVER

   你应该能看到类似172.25.32.1:5037的输出。

3.3 第三阶段：连接设备与功能验证

现在，激动人心的时刻到了——连接你的Android设备。

步骤1：在Windows端连接并授权设备

1. 用USB数据线将你的Android手机连接到Windows电脑。
2. 在手机上弹出的“是否允许USB调试？”对话框中，勾选“始终允许”，然后点击“确定”。（如果没弹出，请确保手机的“开发者选项”和“USB调试”已开启）。
3. 在Windows的CMD或PowerShell中，运行adb devices。你应该能看到你的设备被列出，状态为device。这一步至关重要，它确保了Windows端的ADB服务器已经正确识别并建立了与设备的USB连接。

步骤2：在WSL端验证连接

1. 回到WSL终端。
2. 运行adb devices。
   • 如果一切顺利，你会看到和Windows端完全相同的设备列表，状态也是device。这证明WSL端的ADB客户端成功通过TCP连接到了Windows的ADB服务器，并获取了设备信息。
   • 如果看到* daemon not running. starting it now at tcp:5037然后报错，这通常意味着WSL的ADB试图自己启动一个本地守护进程。请再次确认ADB_SERVER环境变量是否正确设置并已生效。你可以手动指定服务器进行连接测试：

     adb -H $(grep nameserver /etc/resolv.conf | awk '{print $2}') devices

     -H参数用于指定ADB服务器的主机地址。

步骤3：执行ADB命令测试现在，你可以在WSL终端中运行任何ADB命令了，它们的效果和直接在Windows命令行中运行是一样的，因为背后操作的其实是同一个设备、同一个ADB服务器。

• 获取设备信息：adb shell getprop ro.product.model
• 安装APK：adb install /path/to/your/app.apk(注意：WSL中的路径是Linux路径)
• 拉取文件：adb pull /sdcard/DCIM/Camera/ ~/Pictures/
• 截图：adb exec-out screencap -p > screenshot.png

尝试几个命令，感受一下在熟悉的Linux终端里直接操控Android设备的畅快感吧！

4. 进阶配置与自动化脚本

基础功能打通后，我们可以追求更优雅、更自动化的体验。

4.1 编写一键连接脚本

每次打开WSL都要手动启动Windows的ADB服务器有点麻烦。我们可以写一个简单的Shell脚本来自动化这个过程。 在WSL的~/bin/目录下（如果没有可以创建，并确保~/bin在PATH中），创建一个文件叫adb-connect：

#!/bin/bash # 获取Windows主机IP WINDOWS_IP=$(grep nameserver /etc/resolv.conf | awk '{print $2}') # 检查Windows端ADB服务器是否在运行 if ! nc -z $WINDOWS_IP 5037 2>/dev/null; then echo "Windows ADB server is not running. Attempting to start it..." # 通过Windows的wsl.exe命令来启动Windows端的ADB服务器 # 这里假设你的Windows ADB也在PATH中 /mnt/c/Windows/System32/wsl.exe -d "$(wsl.exe -l -q | head -1)" -- adb start-server sleep 2 # 给服务器一点启动时间 fi # 设置环境变量并列出设备 export ADB_SERVER="$WINDOWS_IP:5037" adb devices

给脚本添加执行权限：chmod +x ~/bin/adb-connect。以后只需要在WSL里输入adb-connect，它就会帮你检查并尝试启动服务器，然后列出设备。

4.2 处理WSL2 IP地址变化问题

WSL2的虚拟网络IP地址（即/etc/resolv.conf里的nameserver）在每次WSL重启后可能会发生变化。这会导致我们之前设置的ADB_SERVER环境变量失效。有几种应对策略：

1. 动态获取（推荐）：就像我们在.bashrc里做的那样，每次启动Shell时动态获取IP。这是最省心的方法。
2. 在Windows端配置ADB服务器监听0.0.0.0（adb -a -P 5037 nodaemon server start已经做了），然后在WSL端使用固定的主机名host.docker.internal:5037。这个主机名通常能解析到正确的IP。你可以尝试在WSL中设置：

   export ADB_SERVER=host.docker.internal:5037

   如果这个域名在你的WSL中无法解析，则仍需使用动态获取IP的方法。

4.3 无线调试（进阶玩法）

既然我们已经建立了TCP连接，那么无线调试就变得非常简单。前提是手机和电脑在同一个局域网内。

1. 在Windows端操作：先用USB连接手机，然后在Windows的CMD中执行：

   adb tcpip 5555 # 将设备切换到TCP/IP模式，监听5555端口

2. 断开USB线。
3. 获取手机的无线局域网IP地址（在手机设置-关于手机-状态信息里查看）。
4. 在WSL端连接：

   adb connect 手机IP地址:5555

   例如：adb connect 192.168.1.100:5555
5. 连接成功后，在WSL中运行adb devices，你会看到两个设备条目：一个是通过ADB_SERVER连接的USB设备（由Windows代理），另一个是直接通过TCP连接的无线设备。你可以通过adb -s 设备序列号来指定操作哪个设备。

5. 常见问题与深度排错指南

即使按照步骤操作，你也可能会遇到一些问题。这里汇总了最常见的坑和解决方案。

5.1 问题：WSL中adb devices显示为空或报错

排查思路与步骤：

1. 检查Windows端设备状态：

   • 首先，永远先在Windows的CMD/PowerShell里运行adb devices。这是所有问题的根源。如果这里也看不到设备，问题出在Windows端的USB连接上。
   • 可能原因：USB线仅充电、手机未授权、电脑USB口或驱动问题、手机开发者选项未开启。
   • 解决：换线、换口、在手机上重新授权、重启ADB服务（adb kill-server&&adb start-server）、安装通用ADB驱动。

2. 检查Windows ADB服务器是否在运行并监听：

   • 在Windows PowerShell中运行：netstat -ano | findstr :5037
   • 你应该能看到类似TCP 0.0.0.0:5037 0.0.0.0:0 LISTENING的行。如果没有，说明服务器没启动，回到3.1步骤重新启动。

3. 检查WSL到Windows的网络连通性：

   • 在WSL终端中，运行：ping $(grep nameserver /etc/resolv.conf | awk '{print $2}')
   • 如果能ping通，说明网络是通的。如果不通，检查WSL网络配置，或者尝试重启WSL（在PowerShell中wsl --shutdown然后重新打开）。

4. 检查ADB_SERVER环境变量：

   • 在WSL中运行echo $ADB_SERVER，确认输出格式是IP:5037（例如172.25.32.1:5037），而不是localhost:5037或其他。
   • 如果变量未设置或错误，请检查你的.bashrc或.zshrc文件，并执行source命令。

5. 检查防火墙规则：

   • 确认3.1步骤中创建的Windows防火墙入站规则是“启用”状态。可以在“Windows Defender 防火墙与高级安全”中查看。

6. 使用详细模式调试：

   • 在WSL中运行adb kill-server（这会杀掉WSL可能错误启动的本地守护进程）。
   • 然后运行adb -H $ADB_SERVER devices来显式指定服务器连接。加上-L参数可以输出更详细的日志：

     adb -L tcp:5037 -H $(grep nameserver /etc/resolv.conf | awk '{print $2}') devices

     观察错误信息。

5.2 问题：adb命令执行慢或超时

• 可能原因：WSL2的虚拟网络在某些情况下有性能问题或DNS解析慢。
• 解决：
  • 尝试在Windows主机文件中为宿主机IP添加一个静态主机名。编辑Windows的C:\Windows\System32\drivers\etc\hosts文件（需要管理员权限），添加一行，例如：172.25.32.1 wsl-host。然后在WSL的ADB_SERVER中使用wsl-host:5037。
  • 检查WSL的/etc/resolv.conf，如果里面有nameserver 172.25.32.1，可以尝试在WSL中禁用自动生成此文件，并设置一个静态DNS。但此操作较复杂，非必要不推荐。

5.3 问题：同时使用Windows和WSL的ADB命令冲突

• 现象：在WSL里操作设备时，Windows端的ADB可能断开连接，或者设备状态显示为offline。
• 原因：ADB协议本身允许一个服务器管理多个客户端，但某些操作（如adb logcat的持续输出）可能会产生冲突。本质上，两者连接的是同一个ADB服务器，冲突概率较低，但并非完全不可能。
• 解决：这通常不是配置错误。如果遇到问题，可以尝试只从一个客户端进行活跃的、独占性的操作（如logcat,shell）。对于普通的安装、文件传输命令，交替使用通常没有问题。

5.4 问题：WSL1和WSL2的区别

• WSL1：采用翻译层架构，与Windows共享网络栈。这意味着WSL1中的localhost就是Windows的localhost。在这种情况下，你甚至可以将ADB_SERVER设置为localhost:5037或127.0.0.1:5037。配置更简单，但WSL1对Linux内核特性的支持不如WSL2完整。
• WSL2：基于Hyper-V的轻量级虚拟机，拥有独立的Linux内核和虚拟网络。因此必须使用宿主机的虚拟网络IP（通过/etc/resolv.conf获取）进行通信。这也是本文主要针对的环境。

  如何查看你的WSL版本？在PowerShell中运行wsl -l -v。

整个配置的核心，其实就是理解并搭建好“WSL客户端 -> TCP/IP网络 -> Windows ADB服务器 -> USB物理连接 -> Android设备”这条通信链路。一旦链路打通，剩下的就是享受在高效Linux环境下进行Android开发和调试的便利了。这套方案经过长期实践，非常稳定，几乎可以媲美在原生Linux上使用ADB的体验。