860 个赞、404 条评论，社区炸了
2026 年 7 月，一条 Google IssueTracker 上的内部评论被截图流出。Google ADB 团队的核心维护者写道：“localhost 连接也被证实是应用利用 ADB 套接字提权的一种途径。不如我们限制只绑定到 wlan0 无线网卡。”
这条看似平淡的技术讨论，在 Hacker News 上拿下了 860 个点赞、404 条评论，引发了 Android 开发者社区近十年来最激烈的一场争论。争议的焦点是一个很难回避的质疑：这是安全升级，还是借安全之名铲除不听话的工具？
一条藏在开发者选项里的”后门”
ADB（Android Debug Bridge，安卓调试桥）对普通 Android 用户来说几乎不存在——它躺在设置里的”开发者选项”中，而开发者选项本身就是个彩蛋：你需要连续点击”版本号”七次才会现身。
但 ADB 的能量非常大。它就像手机系统的一个管理级通道：可以安装/卸载应用、读取日志、查看文件、模拟按键操作。开发者用它调试 App，高级用户用它实现一些系统没开放的功能。
早期 ADB 只能通过 USB 线连接电脑使用。Android 11 引入了无线调试模式（Wireless Debugging），通过二维码配对后就能用 Wi-Fi 连接。这两种方式都要求有两台设备，一台手机、一台电脑。
但总有聪明人发现：我直接在手机上运行一个 ADB 客户端，通过 127.0.0.1（本机回环地址）连接到自己身上不就行了吗？
这就叫”设备端 ADB”（On-Device ADB）。它原本不是 Google 设计的用法，却催生了一整个开源工具生态。
Shizuku：一个意外的生态链
“设备端 ADB”最大的产品就是 Shizuku（日文中”雫”的罗马音）。
Shizuku 做的事情可以用一句话说清楚：它利用设备端 ADB 获得系统级权限，然后让其他 App 通过它调用这些权限，整个过程不需要 root。
听起来还是抽象？举个例子：
- Canta：可以卸载手机厂商预装的那些删不掉的 App（比如某某商城、某某钱包），不需要 root。
- App Manager：可以查看每个 App 真正用了哪些权限、访问了哪些文件。
- aShell：你在手机上开一个终端窗口，直接在手机里跑 ADB 命令。
- ShizuCallRecorder：在部分地区没有内置通话录音的手机上实现通话录音。作者 Kitsumed 本人就是用它来帮助自己的听障日常。
Android 开源项目的作者 Rikka 在 2019 年发布 Shizuku 时，可能也没想到它会变成这样一个”底层基础设施”。如今 Google Play 上安装 Shizuku 的设备超过百万台，但这仍然是个低估——因为大量用户通过 F-Droid、GitHub 直接安装，统计不到。
攻击路径：需要”叠buff”
Google ADB 维护者的顾虑是：恶意 App 可以利用设备端 ADB 的 127.0.0.1 连接来提升自身权限，从而绕过 Android 的沙盒机制。
那么，恶意 App 要成功利用这招，需要几步？
笔者结合 Kitsumed 原文的分析和 HN 评论区讨论，整理了实际攻击链路：
- 用户必须先进入”设置 → 关于手机”，连续点击”版本号”7 次，开启开发者选项
- 用户必须手动进入开发者选项，打开”USB 调试”，启动 ADB 守护进程
- 用户必须再开启”无线调试”（Android 11+）或通过 USB 连接电脑启用 TCP/IP 模式
- 恶意 App 发起连接时，手机上会出现一个对话框，用户必须点击”允许”
- 如果使用无线调试配对模式，用户还必须手动输入一个 6 位配对码
HN 用户 microtonal 的评论被顶到最高：“这个攻击面需要同时开启开发者设置和远程 ADB。对于 99.9% 的用户来说，这不是一个现实的攻击向量。剩下的 0.1% 基本上知道自己在做什么。”
另一位用户 crote 说得更直白：“这几乎不可能影响普通用户，只有粗心的开发者才可能中招。而且前提是 Google Play 自己的恶意软件扫描完全失效——等等，限制侧载的理由不就是说 Play 扫描很厉害吗？”
从工程角度看：CVE-2026-0073 确实是真实的漏洞——它绕过了无线调试的身份认证。但这个漏洞已经被修复了。现在讨论的提案，是在漏洞已经修好之后，额外再去封堵设备端 ADB 这个功能本身。
反派是谁？
这里很难不看到一种模式的重复。
回顾过去几年 Google 的产品决策：Chrome 推出 Manifest V3，以安全为由让广告拦截插件失效；Android 收紧侧载权限，以安全为由限制从 Play 商店以外安装 App。每一次，“安全”都是那张牌，打出的效果都在做同一件事：缩小用户对自己设备的控制空间。
HN 用户 transcriptase 的一句话扎心：“我仍然不敢相信，一家广告公司居然能以子虚乌有的安全问题为由，有效阉割了全球 80% 用户的广告/内容拦截能力。”
这次 ADB 限制的剧情几乎一模一样。有一个真实存在于 IssueTracker 的功能请求：让开发者选择 ADB 守护进程监听哪些网络接口（目前它监听所有接口）。这是一个合理的改进。但 ADB 维护者在评论中话锋一转，把”限制接口选择”变成了**“彻底禁止本机回环连接”**——而后者恰恰是设备端 ADB 存在的基础。
整个生态链中，不存在”强盗”式的恶意角色。真正在博弈的是**平台所有者（Google）与设备实际拥有者（消费者与开发者）**之间的权力边界。Google 维护的是 Android 生态的封闭性和可管控性，而用户和开发者想要的是对自己设备的实际控制权。
被牺牲的生态
如果提案落地，具体会死掉什么？
- Shizuku 的所有功能：从卸载预装应用到拦截应用唤醒，全部瘫痪
- Canta、App Manager、aShell 等几十款依赖 Shizuku 的工具
- libadb-android 这种藏在底层的基础库
- 所有在 Termux 中使用 ADB 的开发工作流
Kitsumed 在原文中呼吁开发者去 IssueTracker 上发表有建设性的意见，而非刷低质量评论。这种克制的态度本身就像一种苦笑——“我们知道这很可能挡不住，但至少不要让我们显得很蠢。”
从目前 IssueTracker 的动向看，assignment 已经移交给 ADB 组的主要工程师，事情正在推进中。
安全，从来不只是技术问题
设备端 ADB 的封禁，从一个角度看是合理的安全加固——任何减少攻击面的措施都有其价值。但从另一个角度看，这是一个”默认不信任设备所有者”的信号：你买的手机，但你不一定有权决定它能跑什么代码。
HN 用户 JoshTriplett 在讨论中给出了一种折中方案：可以默认禁止本机回环连接，但提供一个持久化的设置开关（重启不丢失），且第三方 App 无法读取这个开关的状态。 这样既保证了普通用户的安全性，又给高级用户留了一条路。从工程上说，这不是一个难实现的设计。
但提案之所以是提案，正因为它没有选择折中。
2026 年的 Android，正在经历一场艰难的平衡：一边是欧盟 DMA 迫使它开放侧载和第三方应用商店，另一边是 Google 在内部不断收紧对设备底层的控制。设备端 ADB 也许只是这场拉锯战中，普通人不会注意到的又一块倒下的多米诺骨牌。
图：Shizuku 启用无线调试的界面。来源：shizuku.rikka.app
图：Shizuku 成功启动后的界面。来源：shizuku.rikka.app
图：无线调试的 6 位配对码输入界面。来源：shizuku.rikka.app
参考来源
- Android May Soon Restrict On-Device ADB, Affecting Shizuku, libadb and Developers — Kitsumed Blog
- Hacker News Discussion (item?id=49045159)
- Shizuku User Manual — Rikka Apps
- Google IssueTracker — ADB Feature Request
- Android Developers — ADB 官方文档
