Google's Plan to Restrict On-Device ADB Could Kill Shizuku and an Entire Ecosystem of Rootless Android Power Tools

Google's Android team is weighing a change to ADB that would sever the technical foundation beneath Shizuku, libadb-android, and dozens of open-source apps that give Android power users capabilities the platform itself never built. A core ADB maintainer at Google proposed restricting on-device ADB connections to only the Wi-Fi interface, a shift that would eliminate the loopback connections these tools depend on 1.

The proposal surfaced in a Google IssueTracker feature request created in response to CVE-2026-0073, a vulnerability that allowed the Wireless ADB authentication process to be fully bypassed 1. The original request asked for something measured: letting developers choose which network interface the ADB daemon binds to, instead of exposing it on every available network. But in a comment on the thread, a core ADB maintainer suggested going further, proposing that the daemon should always bind exclusively to wlan0, the Wi-Fi interface. "Connection to localhost has also been the source of exploit where app are using that socket to adbd to escalate their privileges," the maintainer wrote. "What about we restrict to always only binding to wifi interface wlan0?" 1.

What Loopback ADB Powers

ADB, or Android Debug Bridge, is a protocol created by Google that grants developers elevated privileges to test how phones and applications behave 1. It was originally designed for USB connections between an Android device and a separate developer machine. But developers found they could run an ADB client directly on the phone, connecting to the local daemon through the loopback address, 127.0.0.1. This is what is known as on-device ADB 1.

That technique spawned an entire ecosystem. Shizuku, developed by RikkaApps, and libadb-android, developed by MuntashirAkon, let apps access ADB-level permissions without requiring root access 1. Shizuku became the backbone for dozens of tools: app managers, permission controllers, call recorders, and system-level tweakers that fill the gap between what Android's official APIs offer and what power users actually need.

Kitsumed, developer of ShizuCallRecorder, a Shizuku-based application, describes use cases that go beyond convenience. One user relied on the app to preserve the voicemail of a deceased loved one. Others use it for accessibility needs that Android's built-in tools don't address 1.

A Real Vulnerability, A Questionable Remedy

The maintainer's concern has merit in isolation. ADB's loopback socket can theoretically be exploited by a malicious app to escalate privileges by connecting to the local daemon. CVE-2026-0073 is a genuine finding: it demonstrated that Wireless ADB's authentication could be completely circumvented 1.

But the Kitsumed analysis questions whether on-device ADB is a meaningful attack vector in practice. General Android users rarely have ADB enabled at all. Developers on Android 11 and later use Wireless Debugging, which requires pairing via code or QR scan rather than the legacy TCP/IP mode that the vulnerability targets 1. The users most exposed to the flaw are not the same ones powering the loopback ecosystem. The blog notes that the proposal has already drawn community concern, with readers mobilizing to leave feedback on the IssueTracker thread 1.

No Replacement Path

For power users, the change means losing rootless tools that handle everything from granular permission management to call recording. Android's own attempt to add native call recording in Android 11 was canceled before release 1. There is no Google-built equivalent waiting in the wings.

For developers, the breakage arrives with no migration path. Shizuku and libadb-android were not built on undocumented APIs or security loopholes. They used ADB exactly as Google designed it, just from the same device. If loopback connections are blocked, the architecture these apps rely on ceases to function. Rewriting around Google's official permission APIs means accepting caps deliberately set for average users, which is precisely the ceiling these tools were built to exceed 1.

The restriction would also break ADB over VPN and ADB over Ethernet setups, affecting developers working from unconventional configurations 1. The proposal is not yet an official Google announcement, and the Kitsumed blog stresses that the IssueTracker discussion remains ongoing 1.

The recurring tension is that Android keeps telling developers to build within its API surface while that surface remains capped well below what power users want. Each time the community builds a bridge over the gap, a security rationale emerges to close it. CVE-2026-0073 exposed a real flaw 1, but the fix on the table would dismantle years of open-source work to block an attack surface that, by the available analysis, bad actors rarely exploit in practice 1. When a platform's security model and its power-user ecosystem can no longer coexist, the choice of which one survives says everything about who the platform thinks its users really are.