Android 或将限制设备端 ADB 连接
在深入讨论之前，请注意，这不是谷歌的官方公告。 相反，这是基于谷歌IssueTracker上一个近期持续的功能请求，其中ADB核心维护者（谷歌员工）的一条评论提到了限制设备端ADB连接以防范“不良行为者”。
在你放下手头的事情直奔那个IssueTracker帖子之前，请仔细阅读以下内容：
如果你打算去issue tracker只是为了发布低质量评论（比如“嘿，别这么做，我需要Shizuku！”）、抱怨垄断或进行人身攻击，我强烈建议你不要这么做。 在帖子里刷屏只会导致谷歌开发者锁定该问题、忽略有价值的社区反馈，或者完全停止公开分享这项变更的进展。
我认为这样的改变可能对谷歌有利，因为它与他们新的侧载限制方向一致，但我并不认为这就是实际意图。这背后有一个真实且合理的理由，而且我认为可以采取两种不同的方法。我们将在本文中讨论这一点。
如何提供帮助：
- 如果你有独特的使用场景：如果你是直接受影响，并且能写出详细、有建设性的信息，说明你的工作流程、提供链接或技术方案/折中办法，请务必在Google Issue中分享你的反馈。
- 如果你的使用场景已经被提及：无需重复，只需点击Google IssueTracker右上角的+1按钮，让Google知道你也受影响，并开启通知以关注后续讨论。
我犹豫是否要写这篇博客，担心会给仅有的几位ADB开发者带来过多负担。我不确定是该再等等看情况，还是继续观望他们的应对方案。等太久也可能不好……写这篇文章时，我还不确定它何时（或是否）会发布。我注意到最近有一些任务分配给了之前负责ADB的主要开发者，所以且走且看吧。
你好！我是Kitsumed，ShizuCallRecorder（一款基于Shizuku的应用）的开发者。你可能已经猜到，这个改动会影响到我。当然，我非常希望他们不要以阻止回环连接的方式推进。
简单介绍一下自己，我开发ShizuCallRecorder是为了帮助自己应对一些残障问题。没有它我也能应付，但有它会轻松很多。
可以说我的使用场景非常独特，而且我还不断发现其他不寻常的案例，比如Reddit上的这位用户，他用我的应用保存了已故亲人的语音留言。
Android上的通话录音是个复杂话题。有无数用户请求，官方在Android 11中曾尝试加入该功能但后来取消，还有许多闭源、侵犯隐私的应用通过变通方式实现。
我曾听说许多残障用户不得不以隐私换取更便利的日常生活。我想这就是人们所说的取舍吧。
别跟我提那些制造商，他们在法律没有要求的地方强制加入“此通话正在录音”的语音提示。人们通常对此反应不佳，即使你解释为什么要录音，也会给人留下坏印象。说实话，我可能也会反感。 相信你们大多数人都用 Shizuku 做过一些“高级用户”的操作，甚至用回环 ADB 来执行开发任务。我也一样，但我想分享一个我独有的使用场景。 好了，回到正题。在解释拟议的变更之前，我先为不太懂技术的读者介绍一下什么是 ADB。ADB，全称 Android Debug Bridge（安卓调试桥），是 Google 创建的一种协议，让开发者可以在安卓设备上做各种开发工作……
基本上，它授予我们高级权限，让我们能够使用大量敏感命令来测试手机和应用的行为。这对开发者和高级用户来说都非常有用。
ADB 最初设计为通过 USB 连接工作，但后来扩展了工作方式：
- USB：原始方式。ADB 通过 USB 线缆直接通信。
- TCP/IP：引入了一种通过网络使用 IP 地址和端口（通常是端口
5555）运行 ADB 的方式。连接以明文传输 ADB 流量，并通过“是/否”提示进行身份验证。只有在已有活动 ADB 连接的情况下才能启用。 - 无线调试（Wifi 1.0/2.0）：在 Android 11 中引入，旨在改进传统的 TCP/IP 工作流程。它需要用户使用配对码或二维码将电脑与设备配对，然后建立一个经过身份验证和加密的连接，用于后续的 ADB 会话。它不需要已有活动 ADB 连接即可启用。
ADB 最初的设计是用于两台设备（简化说明）：被调试的 Android 设备运行 ADB 守护进程（ADBD），而另一台开发机运行 ADB 客户端。但在实际使用中，这种配置并不总是方便。有些开发者直接在 Android 设备上工作，手边没有第二台机器。
这就催生了 设备端 ADB（非官方术语）的用法。借助 Termux 这类终端模拟器，开发者可以直接在手机上运行 ADB 客户端，并通过 ADB TCP/IP 或 Wireless Debugging 连接到本地的守护进程（ADBD）服务器。由于客户端和服务器都在同一台设备上运行，连接通过回环地址（127.0.0.1）建立。这就是我所说的设备端 ADB。
虽然与 ADB 的初衷相比，这算是一个小众用法，但它催生了 MuntashirAkon 的 libadb-android 和 RikkaApps 的 Shizuku 等项目。这些项目连同其他许多项目，形成了一个庞大的开源社区，为开发者和高级用户提供了大量工具。
Google IssueTracker 上提交了一个 新功能，允许开发者选择 ADBD（ADB 服务器守护进程）监听哪个接口。
这个功能是在一个标识为 CVE-2026-0073 的重大安全漏洞之后提出的，该漏洞可以完全绕过无线 ADB 的认证过程。这个提案本身其实是个好主意。
目前，ADBD 会暴露在手机连接的每一个网络上。此功能请求旨在让开发者自行选择要监听哪个接口，从而减少暴露面。
问题出在 ADB 核心维护者之一的回复中：
本地回环连接也曾被用作攻击途径，应用通过该 socket 连接 adbd 来提升权限。那如果我们限制 adbd 始终只绑定到 wifi 接口
wlan0呢？
这里我们看到，这位员工建议只允许 wlan0（即 wifi 连接接口）。但这样做会破坏很多功能，比如设备端 ADB、通过 VPN 的 ADB、通过以太网的 ADB，以及许多其他开发者特有的配置。
我还注意到另一个问题，就是他们目前对“设备端 ADB”的立场。他们的评论暗示，设备端 ADB 主要被视为恶意分子用来提升权限的攻击手段，但其实设备端 ADB 有很多合法用途。开发者自己在无法使用电脑时就会用到它。
虽然它确实可以用来提升权限，但“恶意”应用无法独自完成。它需要多个步骤，而且这些步骤必须由人工操作。
为什么恶意分子其实很少使用设备端 ADB#
恶意应用确实可以利用设备端 ADB 连接来提升权限。但它无法自行建立这种连接。
为了说明这一点，我列出了几个场景中恶意分子会遇到的主要限制，类似于我在 IssueTracker 上的评论。
场景一：普通 Android 用户#
- 你安装了一个恶意应用。
- ADB 处于禁用状态，ADBD 未运行，应用也没有
WRITE_SECURE_SETTINGS权限（该权限必须通过 ADB 手动授予）。无法进行任何利用尝试。
- ADB 处于禁用状态，ADBD 未运行，应用也没有
场景二：Android 11+ 开发者使用无线 ADB#
- 你安装了一个恶意应用。
- 你开启了 USB 调试，启动了 ADBD。
- 你安装了一个恶意应用。
- 你开启 USB 调试，启动 ADBD。
- 通过 USB ADB 连接并启用 TCP/IP，然后拔掉 USB 线。
- ADBD 继续运行，监听所有网络接口。
- 应用发起连接，屏幕上弹出授权提示。如果用户点击否，连接被拒绝。无法静默发起攻击。
正常情况下，恶意攻击者无法建立 ADB 连接。只有在开发者主动使用设备端 ADB 时才可能，因为攻击者无法自行启动 ADBD。
但回到类似 CVE-2026-0073 的场景，攻击在场景 2 和 3 中就有可能发生，但前提是用户已经手动开启了 USB 调试。至于场景 3，还需要开发者手动启用 TCP/IP。我能理解默认禁止回环连接的动机，但不应该完全禁止。
默认禁止和永久禁止是有区别的。我认为应该允许用户通过持久设置来关闭这一限制，即一个重启后依然生效的开关（否则像 Shizuku 这样的工具就无法使用了），并且这个开关不能被第三方应用读取。否则，开发者每次使用银行应用或游戏检测到设备端 ADB 可用时，都得手动关闭它。不过，一旦用户手动授予了 WRITE_SECURE_SETTINGS 权限，这部分限制就可以绕过。
我认为，以“用户本可以手动操作来允许”为由禁止该功能，这种理由很牵强。用户同样可以手动将恶意应用设为设备管理员或授予无障碍权限，但我们并没有因此取消这些功能。
我认为这应被视为一种可接受的风险：关闭这项安全功能虽然开启了设备端调试，但同时也使设备面临未来极低概率的漏洞风险。在我看来，功能与风险的权衡是合理的，因为确实存在真实且合法的使用场景。
尽管最初并非设计如此，但On-Device ADB已经催生了一个面向开发者和高级用户的小众工具生态，包括App Manager、libadb-android、Canta、aShell、ShizuWall、ShizuCallRecorder和Shizuku等项目。
最后，我想提一下我在《什么是Shizuku？它是如何工作的？安全影响？》中得出的结论，当时我开玩笑说：
我的结束语是：我迫不及待想看看他们如何解释禁用非模拟器设备上通过TCP/IP连接的环回ADB，并开始要求Google账户……
嗯，看来他们可能真的会禁用环回ADB。哈……我猜我在这件事上几乎百分之百说对了。如果你是科技