Android 或将限制设备端 ADB 功能，影响 Shizuku 等工具

背景与事件概述

Google 内部正在讨论一项针对 Android 的变更——限制设备端 ADB（Android Debug Bridge）的本地回环（loopback）连接。该讨论源于一个功能请求，原本是为了让开发者选择 ADB 守护进程（ADBD）监听的网络接口，以解决 CVE-2026-0073 无线 ADB 认证绕过漏洞。但核心 ADB 维护者在评论中提出直接限制 ADBD 仅绑定到 wlan0（WiFi 接口），从而切断本地回环连接。这一提议可能严重影响依赖 On-Device ADB 的整个开源工具生态，包括 Shizuku、libadb、App Manager、Canta、aShell 等。

什么是 ADB 与 On-Device ADB？

ADB 是 Google 提供的安卓调试桥，最初用于通过 USB 连接电脑进行开发调试。后来扩展出 TCP/IP 和无线调试（Android 11+）两种方式。On-Device ADB 是指开发者在同一台安卓设备上同时运行 ADB 客户端和服务器（ADBD），通过回环地址 127.0.0.1 建立连接。这通常通过 Termux 等终端模拟器实现，让开发者无需电脑即可执行高级调试操作。虽然这是一个小众用法，但它催生了 Shizuku 等强大工具——Shizuku 利用本地 ADB 为应用提供高权限 API，无需 root 即可实现通话录音、防火墙、应用管理等高级功能。

提议的变更及其问题

Google 员工在 IssueTracker 上的评论显示，他们倾向于将 ADBD 绑定到 wlan0 接口，理由是“连接到 localhost 已被应用利用来通过 ADB 套接字提升权限”。但这一做法会直接破坏 On-Device ADB（因为回环连接不再可用），同时也会影响通过 VPN、以太网等其他网络接口的调试场景。作者指出，这一变更将“杀死”一个由开源社区构建的完整生态，包括大量面向开发者与高级用户的隐私保护工具和辅助功能应用。

为什么恶意软件难以单独利用 ADB？

作者通过三个场景论证 On-Device ADB 并非真正的攻击面：

• 普通用户场景：ADB 默认关闭，恶意应用无法启动 ADBD，也无法获取 WRITE_SECURE_SETTINGS 权限。
• 使用无线调试的开发者：即使开启了无线调试，每次会话都需要用户手动配对（输入一次性代码）。
• 使用传统 TCP/IP 的开发者：需要用户先通过 USB 开启 TCP/IP 模式，且每次连接会弹出授权提示。

在任何场景下，恶意应用都无法单独建立 ADB 连接。即使出现类似 CVE-2026-0073 的漏洞，其前提仍然是用户已手动开启 USB 调试。作者认为，将“人类可能主动允许”作为禁止理由过于牵强——用户可以授予恶意应用设备管理员或无障碍权限，但 Google 并未因此移除这些功能。

作者的建议与结论

作者建议 Google 不要永久禁止回环 ADB，而是提供一个持久化的开关（重启后保留），且默认关闭。该开关不应被第三方应用读取，但可以通过已授权的 WRITE_SECURE_SETTINGS 来管理。这样既默认阻止了潜在攻击，又保留了合法用户的自主选择权。作者强调，On-Device ADB 虽非 Google 最初设计，但已成为一个重要的“小众生态”，其功能价值远大于理论上的安全风险。最后，作者以幽默口吻表达担忧：未来 Google 是否会要求开发者必须登录 Google 账户才能使用 ADB？

原标题：Android May Soon Restrict On-Device ADB。 HN 原始发布时间：2026年7月25日星期六。当前记录为 880 分、422 条评论。

阅读原文 · 查看 HN 讨论