Android 设备上直接运行 ADB 的做法，可能会受到限制。现在还没有 Google 的正式公告，线索来自一个公开的 Google IssueTracker、Kitsumed 7 月 20 日的文章，以及 Hacker News 上的大量讨论。这个话题值得开发者关注，因为它不是普通设置项之争，而是移动平台安全和用户控制权之间的边界问题。

一部显示本地 ADB、无线调试和安全控制的 Android 手机

IssueTracker 里的原始诉求并不激进：希望 adbd 可以绑定到指定网络接口或本地 IP，而不是在所有接口上监听。考虑到 CVE-2026-0073，这个方向有安全理由。NVD 将该漏洞描述为 Wireless ADB 相互认证可能被绕过，附近网络中的攻击者有机会以 shell 用户执行代码。

争议点在于一种可能的做法：只允许 adbd 绑定到 Wi-Fi 接口 wlan0。如果这样实现，连接 127.0.0.1 的本机 ADB 可能会失效。所谓 on-device ADB，就是在手机上运行 ADB 客户端，例如通过 Termux 或某个库，再连接同一台手机上的 ADB daemon。

这不是少数人的玩具。Shizuku、libadb-android 以及一批权限管理、包管理、自动化和维修辅助工具，都依赖这种介于普通应用和 root 之间的能力。很多开发者可以改用 USB 或从电脑进行无线调试，但现场设备、测试机、没有电脑的手机工作流并不总有替代方案。

安全方面的担忧也是真实的。ADB 权限很高，调试端口暴露在错误网络上会成为攻击面。更合理的方案不是简单砍掉 loopback，而是默认更保守，同时为开发者提供明确的接口选择、持续提示、企业 MDM 控制，以及对 127.0.0.1、tun0、eth0 的显式授权。

目前还不能说 Android 一定会这样改。但团队应该先盘点自己是否依赖 Shizuku、libadb-android、adb connect 127.0.0.1、VPN ADB 或 Ethernet ADB。移动系统正在收紧调试入口，越是非标准但有效的工作流，越需要提前准备后路。