Android 设备端 ADB 限制：对 Shizuku 和开发者工作流的影响

Android 设备端 ADB 限制：对 Shizuku 和开发者工作流的影响

Google 正在考虑一项功能，该功能将把 Android 调试桥（ADB）限制到特定的网络接口，这一举措可能会破坏由 Shizuku 和 Termux 等工具使用的“设备端 ADB”环回连接。此提案目前以功能请求的形式出现在 Google IssueTracker 上，旨在缓解安全漏洞，但威胁到开发者和无障碍工具的小众生态系统。

提议的更改与安全背景

Google 开发者正在调查一项功能，该功能将允许开发者选择 ADB 守护进程（ADBD）监听的网络接口。这是对安全问题的直接回应，具体来说，是在发现 CVE-2026-0073 之后，该漏洞允许绕过无线 ADB 身份验证。

目前，ADBD 会在手机连接的每个网络接口上使自身可用。所提出的解决方案旨在通过限制守护进程的可用性来减少此暴露。然而，一位核心 ADB 维护者建议了一种具体的实现方式：仅将 ADB 连接限制到无线接口 (wlan0)。

本地主机（localhost）的连接也曾被用作漏洞的来源，其中应用使用该套接字连接到 adbd 以提升权限。我们是否应该始终仅将绑定限制到 wifi 接口 wlan0？

对设备端 ADB 的影响

将 ADB 限制到如 wlan0 这样的特定接口将会破坏“设备端 ADB”工作流。这指的是 ADB 客户端直接在 Android 设备上运行（例如使用如 Termux 的终端模拟器）通过环回地址 (127.0.0.1) 连接到本地守护进程的情况。

此环回连接对以下几种高实用性应用至关重要：

  • Shizuku： 一个允许应用在不需要完全 root 访问权限的情况下执行高级系统操作的工具。
  • libadb-android： 用于在 Android 应用内部实现 ADB 功能的库。
  • 无障碍和实用工具： 类似 ShizuCallRecorder 的应用，它们依赖 Shizuku 为残障用户提供功能。

如果 ADB 守护进程被阻止绑定到环回接口，这些工具将失去功能，因为它们无法建立到本地 ADB 服务器的连接。

安全分析：风险是否真实？

批评者和开发者认为，设备端 ADB 带来的安全风险被夸大了，因为 ADB 连接需要手动用户干预。恶意应用程序无法独立建立 ADB 连接；它需要人类执行特定的高权限操作。

漏洞利用的障碍

在大多数情况下，恶意应用程序在未得到用户知晓的情况下无法获得 ADB 访问权限：

  1. 普通用户： ADB 默认处于禁用状态。启用它需要手动进入开发者选项。
  2. 无线调试（Android 11+）： 即使启用了无线调试，用户也必须手动执行一次性配对过程，使用代码或 QR 码。
  3. TCP/IP 连接： 在 TCP/IP 上建立连接首先需要通过 USB 连接发送手动命令，随后的连接尝试会在设备屏幕上触发授权提示。

恶意应用程序可以利用设备端 ADB 连接来提升权限。然而，它无法自行建立这样的连接。

社区担忧与“锁定”论点

围绕此更改的讨论凸显了安全与用户自主权之间日益增长的紧张关系。开发者社区中的许多人认为这些限制是朝着更类似 iOS 的“封闭”Android 体验发展的更广泛趋势的一部分。

  • 控制 vs. 安全： 一些评论者认为此举更多是关于 Google 对生态系统的控制，而不是安全，这可能会限制第三方开发者在 Google 官方渠道之外创建强大工具的能力。
  • 用户自主权： 社区常见的反方提案是实施一个持久的、用户可控的开关，该开关能够经受重启。这将允许高级用户选择加入环回 ADB，同时为普通用户保持禁用状态以防止意外被利用。
  • “侧载”关联： 人们担心这些限制是限制侧载应用的次要方法，这延续了之前对 Android 侧载权限的更改。

Sources