A proposal sitting on Google’s public issue tracker would change how on-device ADB works on Android, and if it ships, it takes Shizuku with it. The idea, raised by a Google engineer who maintains the Android Debug Bridge code, is to make the ADB daemon bind only to the Wi-Fi interface and stop accepting connections over localhost loopback — the 127.0.0.1 address a phone uses to talk to itself. That loopback path is exactly what lets a phone grant elevated ADB permissions to its own apps with no PC in the room, and it is the foundation Shizuku is built on.
Nothing has been decided. This is an open discussion thread (issue #526109803), not an announcement, and the maintainer’s own reply to the pushback was that they would weigh it up. But the discussion is real enough that developers who depend on the mechanism have started sounding the alarm.
What the on-device ADB change would actually do
ADB normally runs between a phone and a computer. Wireless debugging extended it over the network, and on-device ADB is the trick of pointing that network connection back at the phone itself — an app or a local terminal connects to 127.0.0.1 and issues shell-level commands to its own system. Restricting the daemon to wlan0 closes that door.
The rationale is security, and it is not invented. Kitsumed, the developer behind ShizuCallRecorder, has been tracking the thread and quotes the Google engineer’s proposal as follows:
Connection to localhost has also been the source of exploit where app are using that socket to adbd to escalate their privileges. What about we restrict to always only binding to wifi interface
wlan0?
The trigger appears to be CVE-2026-0073, a logic error in adbd_tls_verify_cert that allowed wireless ADB’s mutual authentication to be bypassed outright. The NVD entry rates it 8.8 (High) and describes remote code execution at shell privilege with no user interaction required, affecting Android 14, 15, 16 and 16 QPR2. That is a serious hole, and Google patching it is not in question — the argument is over whether the fix should also amputate a legitimate feature.
What breaks if it goes through
Shizuku is the headline casualty, and it is not a niche tool. It is the standard way to hand an ordinary app shell-level permissions on an unrooted phone, and a long list of apps sit on top of it. Kitsumed’s write-up lists the collateral damage:
- Shizuku — the permission-granting framework itself, and every app that requires it
- libadb-android — the on-device ADB library other projects build on
- App Manager, aShell, ShizuCallRecorder — package managers, local shells and call recorders that need shell privileges
- On-device development workflows — testing and debugging directly on a phone with no PC attached
- ADB over Ethernet or a VPN interface — collateral, since neither is
wlan0
In practice, Shizuku is how a lot of people strip carrier and OEM bloatware they cannot otherwise uninstall, run system-wide ad and tracker blocking, tighten permissions the settings app will not expose, and automate their phones. Those are the uses that get quietly deleted here. Google’s security case is genuine, but the cost falls entirely on the people using the platform’s own debugging tools to take back control of a device they own — and their alternatives are unlocking the bootloader and rooting, which is a far bigger security downgrade than the hole being closed, or simply going without.
What happens next
The proposal is at the discussion stage, on a public tracker, with the maintainer saying they will assess the trade-off after community feedback — so no Android version has been named and no code has landed. That also means the window for developer input is open now rather than after the fact, which is the point the Shizuku-adjacent developers are making loudly. Anyone whose setup depends on on-device ADB should assume nothing yet, but watch the thread rather than find out from a release note. It also lands in the same year as Google’s wider tightening of what an owner may install on their own hardware — the Android Developer Verifier that began appearing on phones this month is the other half of that trend.
Sources: Kitsumed, Android Authority
