1. 为什么 Quest 2 的开发者模式值得折腾很多人拿到 Oculus Quest 2 之后玩了两天商店里的游戏就把它扔在角落里吃灰了。说实话这设备真正的潜力根本不在官方商店那几十款应用里。它本质上是一台跑着 Android 底层的独立头显一旦你打开了开发者模式接上 ADB这台设备就从一个游戏机变成了一块可以随意折腾的移动计算平台——侧载第三方应用、抓取系统日志、调试自己写的 Unity 项目、甚至做自动化测试全部都能干。我自己是从 Quest 2 刚发售那会儿就开始折腾的中间踩过的坑不算少。最开始连开发者模式在哪开都找了半天后来发现需要先在手机端 App 里注册开发者组织再到头显里开启调试权限。再后来遇到 ADB 连接不上、设备显示 unauthorized、无线调试端口对不上等一系列问题每一个都花了不少时间去排查。这篇文章就是把这些经验完整地梳理出来从零开始讲清楚开发者模式怎么开、ADB 怎么连、有线无线怎么选、常见问题怎么排查。不管你是想侧载一个第三方应用还是准备用 Unity 或 Unreal 做 VR 开发调试又或者只是想用 ADB 抓个日志看看设备到底在干什么这篇内容都能给你一套可以直接照着操作的方案。我尽量把每一步背后的逻辑也讲清楚这样遇到变体情况的时候你自己也能判断该怎么处理。2. 开发者模式开启全流程拆解2.1 开发者模式到底是什么为什么必须开Quest 2 默认状态下是一个封闭系统你只能通过官方商店安装应用USB 连接电脑也只是一个 MTP 媒体设备没法执行 ADB 命令。开发者模式本质上就是把这个限制打开让系统允许外部工具通过 ADB 协议与头显通信。这里有个关键点很多人搞混开发者模式和USB 调试授权是两回事。开发者模式是在账号和组织层面开启的开关它决定了你的设备允许不允许被调试而 USB 调试授权是设备端弹窗让你确认这台电脑能不能连。两个都到位了ADB 才能正常工作。从系统层面看开启开发者模式之后Quest 2 的 Android 底层会启动 adbd 守护进程监听 USB 和网络端的调试请求。这个进程就是 ADB 通信的服务端没有它你电脑上装再好的 ADB 工具也没用。2.2 手机端注册开发者组织的完整步骤这一步是整个流程里最容易被卡住的地方因为 Meta 的开发者后台界面改过好几次网上很多老教程的截图已经对不上了。我按目前实际能走通的路径来说。首先你需要在手机上安装 Meta Quest 应用就是原来那个 Oculus 应用用你头显上登录的同一个账号登进去。然后打开浏览器访问 Meta 的开发者后台页面用同一个账号登录。进去之后找到创建组织的入口填写组织名称——这个名字随便取个人开发者填自己的名字或者昵称都行不影响后续使用。创建组织的过程中会要求你同意开发者协议然后可能需要验证手机号或者邮箱。验证完成后你的账号就具备了开发者身份。这时候回到手机上的 Meta Quest 应用进入设备设置找到你的 Quest 2在开发者模式选项那里应该就能看到开关了。把它打开。注意如果你在手机应用里找不到开发者模式选项大概率是组织没有创建成功或者账号没有正确关联。先确认浏览器后台里能看到你的组织再回手机应用刷新一下。2.3 头显端确认与 USB 调试授权手机端打开开发者模式之后头显里其实不会有特别明显的提示。你需要戴上头显进入设置找到系统或者关于相关的菜单确认开发者选项已经出现。不同系统版本的菜单路径略有差异但大体上在设置的最底层。接下来用 USB 线把 Quest 2 连到电脑上。这时候头显里应该会弹出一个窗口问你是否允许 USB 调试。勾选始终允许然后确认。如果你没看到这个弹窗先别急后面排查章节会专门讲这个问题。连接成功后你可以在电脑上打开终端输入adb devices来验证。正常的话应该能看到设备序列号后面跟着device状态。如果显示unauthorized说明授权弹窗没有确认或者被跳过了需要重新插拔线缆再试。2.4 开发者模式开启后的能力边界开了开发者模式之后你能做的事情包括但不限于通过 ADB 安装任意 APK、抓取 logcat 日志、截屏录屏、模拟输入事件、查看系统属性、推送和拉取文件、甚至通过 ADB 命令修改一些系统设置。对于 VR 开发者来说这意味着你可以直接在真机上调试 Unity 或 Unreal 构建出来的包而不需要每次都走商店审核流程。但也要清楚它的边界开发者模式不会给你 root 权限你不能随意修改系统分区。某些系统级操作仍然受限。另外每次系统大版本更新后开发者模式有时会被重置需要重新确认。3. ADB 环境搭建与有线连接实战3.1 ADB 工具的选择与安装ADB 全称 Android Debug Bridge是 Google 提供的 Android 调试工具。虽然 Quest 2 是 Meta 的设备但它底层是 Android所以标准 ADB 工具完全适用。我建议直接下载 Google 官方发布的 Platform Tools 包不要用网上那些来路不明的ADB 工具包 1.0.32.zip之类的整合包。官方包干净、版本新、不会有兼容性问题。下载下来解压到一个固定目录比如C:\platform-tools或者~/platform-tools。解压之后你需要把这个目录加到系统环境变量 PATH 里。Windows 上在系统属性 - 高级 - 环境变量里编辑 Path把 platform-tools 的完整路径加进去。macOS 和 Linux 上编辑~/.bashrc或~/.zshrc加一行export PATH$PATH:~/platform-tools。配好之后打开一个新的终端窗口输入adb version能看到版本号就说明环境配好了。提示如果你之前装过其他版本的 ADB可能会遇到adb server version (31) doesnt match this client (41)这类报错。这是因为服务端和客户端版本不一致。解决办法是adb kill-server然后adb start-server让新版本的服务端重新启动。3.2 Windows 驱动问题与 universal adb driverWindows 上最常见的问题就是驱动。Quest 2 通过 USB 连接后设备管理器里可能会显示一个带感叹号的未知设备。这时候 ADB 是认不到设备的。解决办法是安装通用的 ADB 驱动。网上有一个叫 universal adb driver 的包安装之后基本能覆盖大部分 Android 设备包括 Quest 2。或者你也可以在设备管理器里手动更新驱动指向 platform-tools 目录下的usb_driver文件夹。macOS 和 Linux 通常不需要额外装驱动系统自带的支持就够了。Linux 上可能需要配置 udev 规则把 Quest 2 的 vendor ID 加进去否则普通用户权限下 ADB 可能认不到设备。3.3 有线连接的标准操作流程驱动和环境都就绪之后有线连接的操作其实很简单用 USB-C 数据线把 Quest 2 连到电脑。注意一定要用支持数据传输的线有些充电线只有供电针脚插上只能充电不能传数据。戴上头显确认弹出的 USB 调试授权窗口勾选始终允许并确认。在电脑终端执行adb devices。看到设备序列号加device状态就说明连接成功了。如果显示unauthorized把头显里的授权窗口重新触发一下——最直接的办法是拔掉线重新插或者在头显设置里撤销之前的 USB 调试授权再重新连。3.4 验证连接与基础命令实操连接成功之后先跑几个基础命令确认一切正常adb devices adb shell getprop ro.product.model adb shell getprop ro.build.version.release第一条列出设备第二条应该返回Quest 2之类的型号信息第三条返回 Android 版本号。如果这几条都能正常输出说明 ADB 通道完全打通了。接下来可以试试截屏和拉取文件adb shell screencap -p /sdcard/screen.png adb pull /sdcard/screen.png ./screen.png这两条命令先把头显屏幕截到设备存储里再拉到电脑当前目录。实测下来这个流程很稳适合做教程截图或者记录 bug 现场。4. 无线 ADB 连接与进阶操作4.1 为什么要用无线 ADB有线连接虽然稳定但 Quest 2 的 USB 口在头显侧面戴着玩的时候线缆很碍事。特别是做 VR 开发调试的时候你需要在真实空间里走动测试一根线牵着根本没法用。无线 ADB 就是解决这个问题的。无线 ADB 的原理是让 adbd 监听一个 TCP 端口电脑通过 Wi-Fi 网络连到这个端口上。这样只要头显和电脑在同一个局域网里就能无线执行所有 ADB 命令。4.2 无线 ADB 的开启步骤无线 ADB 的开启需要先通过有线连接做一次初始化因为要告诉设备监听哪个端口adb tcpip 5555这条命令让设备在 5555 端口上监听 TCP 连接。执行成功后会提示restarting in TCP mode port: 5555。这时候你可以拔掉 USB 线。然后需要知道头显的 IP 地址。可以在头显的 Wi-Fi 设置里查看或者通过有线连接时执行adb shell ip addr show wlan0找到inet后面跟着的那个 IP比如192.168.1.100。然后adb connect 192.168.1.100:5555看到connected to 192.168.1.100:5555就成功了。再跑一次adb devices应该能看到这个 IP 地址加端口号的设备。注意无线 ADB 在头显重启后会失效需要重新用有线连接执行一次adb tcpip 5555。这是 Android 系统的默认行为目前没有特别好的绕过办法。4.3 无线连接下的常用操作无线连上之后所有 ADB 命令都能正常用。我平时用得最多的几个场景抓日志排查应用崩溃adb logcat -v time quest_log.txt这条命令会把实时日志输出到文件里方便后续分析。如果只想看某个应用的日志可以加过滤条件adb logcat --pid$(adb shell pidof com.example.myapp)安装侧载应用adb install -r myapp.apk-r参数表示覆盖安装保留原有数据。第一次安装可以不加。查看当前前台应用adb shell dumpsys activity activities | grep mResumedActivity这个在调试的时候很有用能确认你的应用是不是真的在前台运行。4.4 无线 ADB 的稳定性优化无线 ADB 偶尔会断连特别是在 Wi-Fi 信号不好的时候。我试过几个办法来提升稳定性一是把电脑和头显都连到 5GHz 频段的 Wi-Fi 上2.4GHz 干扰太多延迟和丢包都更严重。二是如果路由器支持给头显分配一个静态 IP这样每次连接不用重新查 IP。三是如果长时间不用ADB 连接可能会超时断开重新adb connect一下就行。还有一个坑有些企业级或者校园网环境会做客户端隔离同一网络下的设备互相不能通信。这种情况下无线 ADB 是连不上的只能换网络或者用有线。5. 常见问题排查与避坑经验5.1 设备显示 unauthorized 怎么办这是最高频的问题。adb devices显示unauthorized说明设备端没有确认调试授权。原因通常有几个授权弹窗没弹出来、之前点了拒绝、或者授权记录被清了。解决办法按顺序试先拔掉 USB 线重新插看头显里有没有弹窗。如果没有去头显设置里找到开发者选项撤销所有 USB 调试授权然后再插线。还是不行的话重启头显再试。最后的手段是在电脑上删除~/.android/adbkey和adbkey.pub让 ADB 重新生成密钥对再重新连接。5.2 ADB 找不到设备的排查思路adb devices列表是空的说明电脑根本没认到设备。排查顺序排查项检查方法可能结果USB 线换一根确认支持数据传输的线排除线缆问题驱动设备管理器看有没有未知设备需要装驱动授权头显里有没有弹窗需要确认授权ADB 服务adb kill-server adb start-server重启服务端口占用检查 5037 端口是否被占用关闭冲突程序5037 是 ADB 服务端的默认端口如果有其他程序占用了这个端口ADB 就起不来。Windows 上可以用netstat -ano | findstr 5037来查。5.3 无线 ADB 连接失败的常见原因无线连不上先确认几件事头显和电脑是不是在同一个网段IP 前三段一样、头显的 Wi-Fi 是不是还连着、有没有执行过adb tcpip 5555。如果都确认了还是连不上试试 ping 一下头显的 IP看网络层通不通。还有一个容易忽略的点有些系统更新后会把 TCP 调试端口重置需要重新执行adb tcpip 5555。另外如果头显进入了休眠网络连接可能会断唤醒后再连。5.4 实操心得与避坑清单折腾了这么久我总结了几条经验都是文档里不会写的数据线一定要用好的。我一开始用了一根便宜的线时连时不连换了原装线之后问题消失。Quest 2 对线缆质量比较敏感。开发者模式在系统更新后有时会掉更新完系统第一件事就是检查开发者模式和 USB 调试还开着没。无线 ADB 的 5555 端口在某些网络环境下会被防火墙拦如果连不上可以试试换个端口比如adb tcpip 5556。抓 logcat 的时候记得加时间戳不然日志多了根本分不清先后顺序。侧载应用如果安装失败先看是不是 APK 架构不对。Quest 2 是 ARM64 架构x86 的包装不上。6. 从 ADB 到自动化测试的延伸玩法6.1 用 ADB 做基础自动化操作ADB 不只是调试工具它还能做自动化。比如你可以用adb shell input来模拟触摸和按键事件adb shell input tap 500 500 adb shell input swipe 500 500 1000 1000 300 adb shell input keyevent KEYCODE_BACK这些命令在 VR 里的效果和在手机上不太一样因为 Quest 2 的输入系统是基于手柄射线而不是触摸屏。但某些系统级操作还是能用的比如返回键、Home 键。6.2 结合 uiautomator 做界面分析adb shell uiautomator dump可以导出当前界面的 UI 层级结构对于分析应用界面很有用。不过在 Quest 2 上这个命令有时候会失败因为 VR 界面不是标准的 Android View 体系。实测下来在 2D 面板应用里能用在纯 VR 场景里基本用不了。如果确实需要做 VR 应用的自动化测试更靠谱的方案是用 Unity 的测试框架或者 Meta 自己的 XR 测试工具而不是硬套 Android 的 uiautomator。6.3 日志分析与性能监控ADB 抓下来的 logcat 日志可以做很多分析。比如监控应用的帧率、内存占用、崩溃信息。配合adb shell dumpsys系列命令还能拿到电池、网络、Activity 栈等信息。adb shell dumpsys battery adb shell dumpsys meminfo com.example.myapp adb shell dumpsys gfxinfo com.example.myapp这些数据对于优化 VR 应用的性能很有帮助。VR 应用对帧率要求极高掉帧会直接导致眩晕所以性能监控是开发过程中必不可少的一环。6.4 后续可以扩展的方向掌握了 ADB 基础之后你可以往几个方向深入一是结合脚本做批量操作比如自动安装多个 APK、自动抓取多轮测试的日志二是结合 CI/CD 流程在构建完成后自动部署到头显并跑冒烟测试三是研究 Quest 2 的系统属性看看有哪些可以调整的参数来优化开发体验。这些内容展开又是一大篇先把基础打牢后面的事情就顺了。我自己现在最常用的就是无线 ADB 加日志抓取这套组合日常调试基本够用了。 Oculus Quest 2 开发者模式与 ADB 调试完整指南
1. 为什么 Quest 2 的开发者模式值得折腾很多人拿到 Oculus Quest 2 之后玩了两天商店里的游戏就把它扔在角落里吃灰了。说实话这设备真正的潜力根本不在官方商店那几十款应用里。它本质上是一台跑着 Android 底层的独立头显一旦你打开了开发者模式接上 ADB这台设备就从一个游戏机变成了一块可以随意折腾的移动计算平台——侧载第三方应用、抓取系统日志、调试自己写的 Unity 项目、甚至做自动化测试全部都能干。我自己是从 Quest 2 刚发售那会儿就开始折腾的中间踩过的坑不算少。最开始连开发者模式在哪开都找了半天后来发现需要先在手机端 App 里注册开发者组织再到头显里开启调试权限。再后来遇到 ADB 连接不上、设备显示 unauthorized、无线调试端口对不上等一系列问题每一个都花了不少时间去排查。这篇文章就是把这些经验完整地梳理出来从零开始讲清楚开发者模式怎么开、ADB 怎么连、有线无线怎么选、常见问题怎么排查。不管你是想侧载一个第三方应用还是准备用 Unity 或 Unreal 做 VR 开发调试又或者只是想用 ADB 抓个日志看看设备到底在干什么这篇内容都能给你一套可以直接照着操作的方案。我尽量把每一步背后的逻辑也讲清楚这样遇到变体情况的时候你自己也能判断该怎么处理。2. 开发者模式开启全流程拆解2.1 开发者模式到底是什么为什么必须开Quest 2 默认状态下是一个封闭系统你只能通过官方商店安装应用USB 连接电脑也只是一个 MTP 媒体设备没法执行 ADB 命令。开发者模式本质上就是把这个限制打开让系统允许外部工具通过 ADB 协议与头显通信。这里有个关键点很多人搞混开发者模式和USB 调试授权是两回事。开发者模式是在账号和组织层面开启的开关它决定了你的设备允许不允许被调试而 USB 调试授权是设备端弹窗让你确认这台电脑能不能连。两个都到位了ADB 才能正常工作。从系统层面看开启开发者模式之后Quest 2 的 Android 底层会启动 adbd 守护进程监听 USB 和网络端的调试请求。这个进程就是 ADB 通信的服务端没有它你电脑上装再好的 ADB 工具也没用。2.2 手机端注册开发者组织的完整步骤这一步是整个流程里最容易被卡住的地方因为 Meta 的开发者后台界面改过好几次网上很多老教程的截图已经对不上了。我按目前实际能走通的路径来说。首先你需要在手机上安装 Meta Quest 应用就是原来那个 Oculus 应用用你头显上登录的同一个账号登进去。然后打开浏览器访问 Meta 的开发者后台页面用同一个账号登录。进去之后找到创建组织的入口填写组织名称——这个名字随便取个人开发者填自己的名字或者昵称都行不影响后续使用。创建组织的过程中会要求你同意开发者协议然后可能需要验证手机号或者邮箱。验证完成后你的账号就具备了开发者身份。这时候回到手机上的 Meta Quest 应用进入设备设置找到你的 Quest 2在开发者模式选项那里应该就能看到开关了。把它打开。注意如果你在手机应用里找不到开发者模式选项大概率是组织没有创建成功或者账号没有正确关联。先确认浏览器后台里能看到你的组织再回手机应用刷新一下。2.3 头显端确认与 USB 调试授权手机端打开开发者模式之后头显里其实不会有特别明显的提示。你需要戴上头显进入设置找到系统或者关于相关的菜单确认开发者选项已经出现。不同系统版本的菜单路径略有差异但大体上在设置的最底层。接下来用 USB 线把 Quest 2 连到电脑上。这时候头显里应该会弹出一个窗口问你是否允许 USB 调试。勾选始终允许然后确认。如果你没看到这个弹窗先别急后面排查章节会专门讲这个问题。连接成功后你可以在电脑上打开终端输入adb devices来验证。正常的话应该能看到设备序列号后面跟着device状态。如果显示unauthorized说明授权弹窗没有确认或者被跳过了需要重新插拔线缆再试。2.4 开发者模式开启后的能力边界开了开发者模式之后你能做的事情包括但不限于通过 ADB 安装任意 APK、抓取 logcat 日志、截屏录屏、模拟输入事件、查看系统属性、推送和拉取文件、甚至通过 ADB 命令修改一些系统设置。对于 VR 开发者来说这意味着你可以直接在真机上调试 Unity 或 Unreal 构建出来的包而不需要每次都走商店审核流程。但也要清楚它的边界开发者模式不会给你 root 权限你不能随意修改系统分区。某些系统级操作仍然受限。另外每次系统大版本更新后开发者模式有时会被重置需要重新确认。3. ADB 环境搭建与有线连接实战3.1 ADB 工具的选择与安装ADB 全称 Android Debug Bridge是 Google 提供的 Android 调试工具。虽然 Quest 2 是 Meta 的设备但它底层是 Android所以标准 ADB 工具完全适用。我建议直接下载 Google 官方发布的 Platform Tools 包不要用网上那些来路不明的ADB 工具包 1.0.32.zip之类的整合包。官方包干净、版本新、不会有兼容性问题。下载下来解压到一个固定目录比如C:\platform-tools或者~/platform-tools。解压之后你需要把这个目录加到系统环境变量 PATH 里。Windows 上在系统属性 - 高级 - 环境变量里编辑 Path把 platform-tools 的完整路径加进去。macOS 和 Linux 上编辑~/.bashrc或~/.zshrc加一行export PATH$PATH:~/platform-tools。配好之后打开一个新的终端窗口输入adb version能看到版本号就说明环境配好了。提示如果你之前装过其他版本的 ADB可能会遇到adb server version (31) doesnt match this client (41)这类报错。这是因为服务端和客户端版本不一致。解决办法是adb kill-server然后adb start-server让新版本的服务端重新启动。3.2 Windows 驱动问题与 universal adb driverWindows 上最常见的问题就是驱动。Quest 2 通过 USB 连接后设备管理器里可能会显示一个带感叹号的未知设备。这时候 ADB 是认不到设备的。解决办法是安装通用的 ADB 驱动。网上有一个叫 universal adb driver 的包安装之后基本能覆盖大部分 Android 设备包括 Quest 2。或者你也可以在设备管理器里手动更新驱动指向 platform-tools 目录下的usb_driver文件夹。macOS 和 Linux 通常不需要额外装驱动系统自带的支持就够了。Linux 上可能需要配置 udev 规则把 Quest 2 的 vendor ID 加进去否则普通用户权限下 ADB 可能认不到设备。3.3 有线连接的标准操作流程驱动和环境都就绪之后有线连接的操作其实很简单用 USB-C 数据线把 Quest 2 连到电脑。注意一定要用支持数据传输的线有些充电线只有供电针脚插上只能充电不能传数据。戴上头显确认弹出的 USB 调试授权窗口勾选始终允许并确认。在电脑终端执行adb devices。看到设备序列号加device状态就说明连接成功了。如果显示unauthorized把头显里的授权窗口重新触发一下——最直接的办法是拔掉线重新插或者在头显设置里撤销之前的 USB 调试授权再重新连。3.4 验证连接与基础命令实操连接成功之后先跑几个基础命令确认一切正常adb devices adb shell getprop ro.product.model adb shell getprop ro.build.version.release第一条列出设备第二条应该返回Quest 2之类的型号信息第三条返回 Android 版本号。如果这几条都能正常输出说明 ADB 通道完全打通了。接下来可以试试截屏和拉取文件adb shell screencap -p /sdcard/screen.png adb pull /sdcard/screen.png ./screen.png这两条命令先把头显屏幕截到设备存储里再拉到电脑当前目录。实测下来这个流程很稳适合做教程截图或者记录 bug 现场。4. 无线 ADB 连接与进阶操作4.1 为什么要用无线 ADB有线连接虽然稳定但 Quest 2 的 USB 口在头显侧面戴着玩的时候线缆很碍事。特别是做 VR 开发调试的时候你需要在真实空间里走动测试一根线牵着根本没法用。无线 ADB 就是解决这个问题的。无线 ADB 的原理是让 adbd 监听一个 TCP 端口电脑通过 Wi-Fi 网络连到这个端口上。这样只要头显和电脑在同一个局域网里就能无线执行所有 ADB 命令。4.2 无线 ADB 的开启步骤无线 ADB 的开启需要先通过有线连接做一次初始化因为要告诉设备监听哪个端口adb tcpip 5555这条命令让设备在 5555 端口上监听 TCP 连接。执行成功后会提示restarting in TCP mode port: 5555。这时候你可以拔掉 USB 线。然后需要知道头显的 IP 地址。可以在头显的 Wi-Fi 设置里查看或者通过有线连接时执行adb shell ip addr show wlan0找到inet后面跟着的那个 IP比如192.168.1.100。然后adb connect 192.168.1.100:5555看到connected to 192.168.1.100:5555就成功了。再跑一次adb devices应该能看到这个 IP 地址加端口号的设备。注意无线 ADB 在头显重启后会失效需要重新用有线连接执行一次adb tcpip 5555。这是 Android 系统的默认行为目前没有特别好的绕过办法。4.3 无线连接下的常用操作无线连上之后所有 ADB 命令都能正常用。我平时用得最多的几个场景抓日志排查应用崩溃adb logcat -v time quest_log.txt这条命令会把实时日志输出到文件里方便后续分析。如果只想看某个应用的日志可以加过滤条件adb logcat --pid$(adb shell pidof com.example.myapp)安装侧载应用adb install -r myapp.apk-r参数表示覆盖安装保留原有数据。第一次安装可以不加。查看当前前台应用adb shell dumpsys activity activities | grep mResumedActivity这个在调试的时候很有用能确认你的应用是不是真的在前台运行。4.4 无线 ADB 的稳定性优化无线 ADB 偶尔会断连特别是在 Wi-Fi 信号不好的时候。我试过几个办法来提升稳定性一是把电脑和头显都连到 5GHz 频段的 Wi-Fi 上2.4GHz 干扰太多延迟和丢包都更严重。二是如果路由器支持给头显分配一个静态 IP这样每次连接不用重新查 IP。三是如果长时间不用ADB 连接可能会超时断开重新adb connect一下就行。还有一个坑有些企业级或者校园网环境会做客户端隔离同一网络下的设备互相不能通信。这种情况下无线 ADB 是连不上的只能换网络或者用有线。5. 常见问题排查与避坑经验5.1 设备显示 unauthorized 怎么办这是最高频的问题。adb devices显示unauthorized说明设备端没有确认调试授权。原因通常有几个授权弹窗没弹出来、之前点了拒绝、或者授权记录被清了。解决办法按顺序试先拔掉 USB 线重新插看头显里有没有弹窗。如果没有去头显设置里找到开发者选项撤销所有 USB 调试授权然后再插线。还是不行的话重启头显再试。最后的手段是在电脑上删除~/.android/adbkey和adbkey.pub让 ADB 重新生成密钥对再重新连接。5.2 ADB 找不到设备的排查思路adb devices列表是空的说明电脑根本没认到设备。排查顺序排查项检查方法可能结果USB 线换一根确认支持数据传输的线排除线缆问题驱动设备管理器看有没有未知设备需要装驱动授权头显里有没有弹窗需要确认授权ADB 服务adb kill-server adb start-server重启服务端口占用检查 5037 端口是否被占用关闭冲突程序5037 是 ADB 服务端的默认端口如果有其他程序占用了这个端口ADB 就起不来。Windows 上可以用netstat -ano | findstr 5037来查。5.3 无线 ADB 连接失败的常见原因无线连不上先确认几件事头显和电脑是不是在同一个网段IP 前三段一样、头显的 Wi-Fi 是不是还连着、有没有执行过adb tcpip 5555。如果都确认了还是连不上试试 ping 一下头显的 IP看网络层通不通。还有一个容易忽略的点有些系统更新后会把 TCP 调试端口重置需要重新执行adb tcpip 5555。另外如果头显进入了休眠网络连接可能会断唤醒后再连。5.4 实操心得与避坑清单折腾了这么久我总结了几条经验都是文档里不会写的数据线一定要用好的。我一开始用了一根便宜的线时连时不连换了原装线之后问题消失。Quest 2 对线缆质量比较敏感。开发者模式在系统更新后有时会掉更新完系统第一件事就是检查开发者模式和 USB 调试还开着没。无线 ADB 的 5555 端口在某些网络环境下会被防火墙拦如果连不上可以试试换个端口比如adb tcpip 5556。抓 logcat 的时候记得加时间戳不然日志多了根本分不清先后顺序。侧载应用如果安装失败先看是不是 APK 架构不对。Quest 2 是 ARM64 架构x86 的包装不上。6. 从 ADB 到自动化测试的延伸玩法6.1 用 ADB 做基础自动化操作ADB 不只是调试工具它还能做自动化。比如你可以用adb shell input来模拟触摸和按键事件adb shell input tap 500 500 adb shell input swipe 500 500 1000 1000 300 adb shell input keyevent KEYCODE_BACK这些命令在 VR 里的效果和在手机上不太一样因为 Quest 2 的输入系统是基于手柄射线而不是触摸屏。但某些系统级操作还是能用的比如返回键、Home 键。6.2 结合 uiautomator 做界面分析adb shell uiautomator dump可以导出当前界面的 UI 层级结构对于分析应用界面很有用。不过在 Quest 2 上这个命令有时候会失败因为 VR 界面不是标准的 Android View 体系。实测下来在 2D 面板应用里能用在纯 VR 场景里基本用不了。如果确实需要做 VR 应用的自动化测试更靠谱的方案是用 Unity 的测试框架或者 Meta 自己的 XR 测试工具而不是硬套 Android 的 uiautomator。6.3 日志分析与性能监控ADB 抓下来的 logcat 日志可以做很多分析。比如监控应用的帧率、内存占用、崩溃信息。配合adb shell dumpsys系列命令还能拿到电池、网络、Activity 栈等信息。adb shell dumpsys battery adb shell dumpsys meminfo com.example.myapp adb shell dumpsys gfxinfo com.example.myapp这些数据对于优化 VR 应用的性能很有帮助。VR 应用对帧率要求极高掉帧会直接导致眩晕所以性能监控是开发过程中必不可少的一环。6.4 后续可以扩展的方向掌握了 ADB 基础之后你可以往几个方向深入一是结合脚本做批量操作比如自动安装多个 APK、自动抓取多轮测试的日志二是结合 CI/CD 流程在构建完成后自动部署到头显并跑冒烟测试三是研究 Quest 2 的系统属性看看有哪些可以调整的参数来优化开发体验。这些内容展开又是一大篇先把基础打牢后面的事情就顺了。我自己现在最常用的就是无线 ADB 加日志抓取这套组合日常调试基本够用了。