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通常有三种主流方式使用发行版包管理器推荐例如在Ubuntu/Debian系的WSL中直接使用apt安装adb和android-sdk-platform-tools-common包。这是最干净、最易于管理更新、卸载的方式也是官方推荐的做法。手动下载SDK Platform-Tools从Google开发者网站下载包含ADB的压缩包解压后手动配置环境变量。这种方式更灵活可以获取最新版本但需要手动管理更新。通过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那么它可能已经存在。但为了确保版本一致性和最佳兼容性建议从官方渠道获取。访问 Google Android开发者网站 下载“SDK Platform-Tools for Windows”压缩包。解压到一个你喜欢的路径例如D:\Android\platform-tools。记住这个路径。关键将ADB添加到Windows系统环境变量PATH中在Windows搜索框输入“环境变量”选择“编辑系统环境变量”。点击“环境变量”按钮。在“系统变量”部分找到并选中Path变量点击“编辑”。点击“新建”将你的platform-tools目录路径例如D:\Android\platform-tools添加进去。一路点击“确定”保存。验证打开一个新的Windows命令提示符CMD或PowerShell输入adb version。如果能看到版本号输出说明安装成功。步骤2配置Windows防火墙允许ADB通信这是让WSL能够连接到Windows ADB服务器的关键一步。ADB服务器默认监听本机的5037端口。我们需要确保Windows防火墙允许入站连接至少来自本机。以管理员身份打开Windows PowerShell。运行以下命令为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模式在刚才的PowerShell或新的CMD中执行以下命令adb kill-server # 先停止可能已存在的服务器 adb -a -P 5037 nodaemon server start # 在5037端口启动服务器并允许网络连接-a参数表示在所有网络接口上监听。-P 5037指定端口。nodaemon和server start以前台模式启动服务器。执行后命令行会挂起显示* daemon not running; starting now at tcp:5037这表示服务器已在后台运行并监听。你可以按CtrlC中断这个前台命令服务器会转入后台继续运行。或者更简单的方式是直接运行adb start-server它会以后台守护进程方式启动。至此Windows端的准备工作就完成了。你的Windows现在是一个正在监听5037端口的ADB服务器。3.2 第二阶段WSL内部的安装与配置现在我们切换到WSL的Linux环境中。步骤1更新软件源并安装ADB打开你的WSL终端例如Ubuntu。首先更新包列表然后安装adb和相关的工具包sudo apt update sudo apt install android-tools-adb android-tools-fastbootandroid-tools-fastboot通常会和adb一起安装用于设备刷机等操作建议一并安装。步骤2配置WSL的ADB客户端连接至Windows默认情况下WSL中的adb命令会尝试启动一个本地WSL内部的ADB守护进程。我们需要告诉它去连接Windows那边的服务器。在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环境变量。为了让这个配置永久生效而不是每次打开终端都设置我们需要将上面这行命令添加到你的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让配置立即生效source ~/.bashrc # 或 source ~/.zshrc验证环境变量是否设置成功echo $ADB_SERVER你应该能看到类似172.25.32.1:5037的输出。3.3 第三阶段连接设备与功能验证现在激动人心的时刻到了——连接你的Android设备。步骤1在Windows端连接并授权设备用USB数据线将你的Android手机连接到Windows电脑。在手机上弹出的“是否允许USB调试”对话框中勾选“始终允许”然后点击“确定”。如果没弹出请确保手机的“开发者选项”和“USB调试”已开启。在Windows的CMD或PowerShell中运行adb devices。你应该能看到你的设备被列出状态为device。这一步至关重要它确保了Windows端的ADB服务器已经正确识别并建立了与设备的USB连接。步骤2在WSL端验证连接回到WSL终端。运行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安装APKadb 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环境变量失效。有几种应对策略动态获取推荐就像我们在.bashrc里做的那样每次启动Shell时动态获取IP。这是最省心的方法。在Windows端配置ADB服务器监听0.0.0.0adb -a -P 5037 nodaemon server start已经做了然后在WSL端使用固定的主机名host.docker.internal:5037。这个主机名通常能解析到正确的IP。你可以尝试在WSL中设置export ADB_SERVERhost.docker.internal:5037如果这个域名在你的WSL中无法解析则仍需使用动态获取IP的方法。4.3 无线调试进阶玩法既然我们已经建立了TCP连接那么无线调试就变得非常简单。前提是手机和电脑在同一个局域网内。在Windows端操作先用USB连接手机然后在Windows的CMD中执行adb tcpip 5555 # 将设备切换到TCP/IP模式监听5555端口断开USB线。获取手机的无线局域网IP地址在手机设置-关于手机-状态信息里查看。在WSL端连接adb connect 手机IP地址:5555例如adb connect 192.168.1.100:5555连接成功后在WSL中运行adb devices你会看到两个设备条目一个是通过ADB_SERVER连接的USB设备由Windows代理另一个是直接通过TCP连接的无线设备。你可以通过adb -s 设备序列号来指定操作哪个设备。5. 常见问题与深度排错指南即使按照步骤操作你也可能会遇到一些问题。这里汇总了最常见的坑和解决方案。5.1 问题WSL中adb devices显示为空或报错排查思路与步骤检查Windows端设备状态首先永远先在Windows的CMD/PowerShell里运行adb devices。这是所有问题的根源。如果这里也看不到设备问题出在Windows端的USB连接上。可能原因USB线仅充电、手机未授权、电脑USB口或驱动问题、手机开发者选项未开启。解决换线、换口、在手机上重新授权、重启ADB服务adb kill-serveradb start-server、安装通用ADB驱动。检查Windows ADB服务器是否在运行并监听在Windows PowerShell中运行netstat -ano | findstr :5037你应该能看到类似TCP 0.0.0.0:5037 0.0.0.0:0 LISTENING的行。如果没有说明服务器没启动回到3.1步骤重新启动。检查WSL到Windows的网络连通性在WSL终端中运行ping $(grep nameserver /etc/resolv.conf | awk {print $2})如果能ping通说明网络是通的。如果不通检查WSL网络配置或者尝试重启WSL在PowerShell中wsl --shutdown然后重新打开。检查ADB_SERVER环境变量在WSL中运行echo $ADB_SERVER确认输出格式是IP:5037例如172.25.32.1:5037而不是localhost:5037或其他。如果变量未设置或错误请检查你的.bashrc或.zshrc文件并执行source命令。检查防火墙规则确认3.1步骤中创建的Windows防火墙入站规则是“启用”状态。可以在“Windows Defender 防火墙与高级安全”中查看。使用详细模式调试在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的体验。