Google Weighs Restricting Android's On-Device ADB, Threatening Shizuku Ecosystem

A comment from a core ADB maintainer on Google’s IssueTracker has raised alarm that Android may soon curtail on-device ADB — the practice of running an ADB client and daemon on the same phone and connecting over loopback (127.0.0.1), typically via a terminal like Termux. This technique underpins root-free power-user tooling such as RikkaApps’ Shizuku and Muntashir Akon’s libadb-android, and by extension a wide ecosystem of open-source apps built on them. The report is unofficial, drawn from an active feature request rather than a Google announcement.

The underlying request is reasonable: prompted by CVE-2026-0073, a flaw that let Wireless ADB authentication be fully bypassed, it asks Google to let developers pick which network interface ADBD binds to instead of exposing it on every connected network. The problem is the maintainer’s suggested fix — binding ADBD only to the wlan0 Wi-Fi interface. That would sever loopback connections along with ADB over VPN, Ethernet, and other setups, collapsing on-device ADB entirely. The comment also frames localhost ADB primarily as a privilege-escalation vector abused by ‘bad actors.’

The author, Kitsumed, develops ShizuCallRecorder, a Shizuku-based call recorder he built around his own disabilities, and would be directly affected. His counterargument is that while a malicious app can exploit an existing on-device ADB session to escalate privileges, it cannot establish that connection on its own — the setup requires deliberate human steps. Legitimate uses abound, including developers who work directly from a phone without a second machine. He urges affected users to file constructive, specific feedback rather than spam the thread, which risks getting it locked.