上周，一篇开发者博客在 Hacker News 上获得 863 个赞、405 条评论，成为当日最热的讨论：Google 可能正在考虑限制 Android 的”设备端 ADB”（On-Device ADB）连接。一旦落地，以 Shizuku 为代表的整个免 root 高级工具生态将面临灭顶之灾。
起因：一个安全漏洞引出的提案
事情的源头是编号为 CVE-2026-0073 的高危漏洞——无线 ADB 的认证流程可以被完全绕过。随后有开发者在 Google IssueTracker 上提交了一个功能请求，希望让开发者可以选择 ADB 守护进程（ADBD）监听哪个网络接口，以减小暴露面。这本身是个合理的安全改进。
问题在于一位 ADB 核心维护者（Google 员工）的回复。他提到，连接到 localhost 的 socket 也是提权攻击的来源之一，并提议：“要不我们干脆让 ADBD 只绑定到 Wi-Fi 接口 wlan0？”
为什么这会杀死整个生态
ADB（Android 调试桥）原本是设计给两台设备用的：电脑跑客户端，手机跑守护进程。但很多开发者只有一部手机，于是社区发展出了”设备端 ADB”的用法——通过 Termux 等终端模拟器在手机上直接运行 ADB 客户端，经由回环地址 127.0.0.1 连接本机的 ADBD。
在这个看似小众的用法之上，生长出了一个庞大的开源生态：
· Shizuku（RikkaApps 出品）：让普通应用无需 root 就能调用系统级 API，是数百个隐私工具、自动化工具的底座；
· libadb-android：把 ADB 客户端做成库，供应用内嵌使用；
· 各类移动开发工作流：直接在手机上调试、抓日志、跑脚本。
如果 ADBD 只绑定 wlan0，回环连接将被切断，Shizuku 的启动方式会失效，ADB over VPN、ADB over 以太网等开发场景也会一并阵亡。博客作者 Kitsumed 自己就是受影响者——他开发的 ShizuCallRecorder 基于 Shizuku，帮助残障用户实现通话录音，甚至有用户用它保存了已故亲人的语音留言。
作者的核心反驳
Kitsumed 在文中逐一分析了”恶意行为者并不依赖设备端 ADB”的原因：普通用户根本不会开启无线调试；Android 11+ 的无线调试需要配对码或二维码，攻击者无法静默利用；而 TCP/IP 模式虽然认证薄弱，但必须先有活跃的 ADB 连接才能开启。真正利用 CVE-2026-0073 的攻击走的是网络路径，而非回环路径——用限制 localhost 来修这个漏洞，是打错了靶子。
他也呼吁社区保持克制：不要去 IssueTracker 刷屏抱怨，否则只会让 Google 开发者锁帖、停止公开进展。有独特用例的人应该写下详细、建设性的反馈。
社区反响：愤怒的不只开发者
HN 评论区最高赞是一条讽刺：”太好了，我的孩子终于安全了，我的银行账户终于坚不可摧了！”另一条高赞评论则指出，这种”以安全为名移除功能、且永远不给开关”的叙事，是 2010 年代以来软件行业最令人厌烦的模式。还有人联想到 Google 近期对侧载应用的收紧，担心这是收紧 Android 开放性的又一步；也有少数声音认为，让设备自己连自己本身就是个 hack，正确的做法是把能力直接授予应用，而不是保留 ADB 这个旁路。
结语
目前这还只是 IssueTracker 上的讨论，并非 Google 的官方决定。但 863 个赞说明，Shizuku 生态背后的用户群体远比想象中庞大。安全与开放如何权衡，Google 的下一步值得所有 Android 高级用户关注。
原文：Android May Soon Restrict On-Device ADB
HN 讨论：news.ycombinator.com/item?id=49045159（863 赞 / 405 评论）