Android may stop letting a phone debug itself, and Shizuku would break with it

Google’s ADB maintainers are discussing whether an Android phone should still be allowed to debug itself. The conversation is a comment on a public issue tracker, not a release note. If it ships the way it’s phrased today, Shizuku stops working, and so does every debloater and permission tool built on top of it.

Nothing has been announced. Google hasn’t published a policy, landed a commit that implements the restriction, or named a target release. What exists is a feature request, issue 526109803, and a reply from one of the engineers who maintains ADB proposing a fix that would take loopback connections off the table. That reply is why the writeup surfacing it, from ShizuCallRecorder developer Kitsumed, sat at the top of Hacker News on Saturday with 805 points and pulled 826 upvotes on r/Android.

What on-device ADB actually does

ADB, the Android Debug Bridge, is the command-line tool developers use to install apps, read logs, and change protected settings on a phone from a computer. Two pieces make it work: an adb client on the machine, a daemon called adbd on the phone. Over USB it’s boring plumbing. Android 11 changed the picture by adding Wireless Debugging, a pairing-code flow that lets a client reach the daemon over the network with no cable and no pre-existing USB session.

Once that daemon is listening on a TCP port, nothing requires the client to sit on a different device. Install a terminal emulator like Termux, drop an adb binary into it, and connect to 127.0.0.1. The phone becomes both ends of the conversation. That’s the whole trick. Kitsumed calls it on-device ADB and notes the term isn’t official, because Google never designed for it.

Today’s behaviour is right there in AOSP. In daemon/main.cpp, adbd checks service.adb.listen_addrs first, falls back to service.adb.tcp.port or persist.adb.tcp.port, and when a port is set it registers a bare tcp:<port> listener alongside a vsock one. Bare means every interface at once: Wi-Fi, Ethernet, VPN, loopback. That indiscriminate binding is the exposure somebody filed the feature request about.

The comment that set this off

The request itself is narrow and sensible: let developers pick which interface adbd listens on instead of taking all of them. It followed CVE-2026-0073, a logic error in adbd_tls_verify_cert that allowed “a possible bypass of wireless ADB mutual authentication,” scored 8.8 High and fixed in the May 2026 Android security bulletin across Android 14 through 16 QPR2. Anyone on the same network could hijack a debugging session that wasn’t theirs. Reducing the daemon’s blast radius is a fair thing to want.

Then came the third comment on the thread. Kitsumed quotes a core ADB maintainer at a google.com address writing: “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?”

Read the second sentence twice. wlan0 is the Wi-Fi interface and only the Wi-Fi interface. Bind there and nowhere else and loopback dies by construction, taking ADB over Ethernet, USB tethering and a VPN with it. Google’s tracker requires a sign-in, so I can’t read the thread directly; the quote and the argument around it come from Kitsumed’s post. Treat it as one engineer thinking out loud in public, which is what it is.

The demand pointing the other way is already sitting in Gerrit. Change 4118073 against platform/packages/apps/Settings, uploaded by John Peterson on June 11 and still marked NEW as of last Monday, is a rough patch to make local ADB work when there’s no Wi-Fi network in range at all. Its commit message names the assumption it’s arguing with: “the main obstacle for this patch seems to be an assumption that all developers or all advanced users have wifi all the time or nearby.” Two proposals, opposite directions, same subsystem, neither merged.

What breaks if wlan0 wins

Shizuku is the load-bearing piece, at 27,952 GitHub stars. It opens one loopback ADB connection at setup, uses it to start a privileged process, then lends that privilege to ordinary apps through an API. No root, no unlocked bootloader, no tripped attestation. Canta (5,377 stars) rides on it to remove carrier and OEM apps that Settings refuses to uninstall, and App Manager (8,568 stars) does the same for component-level control. XDA’s Ayush Pande walked through the workflow earlier this month, with the fair caveat that “Shizuku isn’t meant to be a replacement for good ol’ rooting.”

Then there’s the long tail nobody writes product requirements for. Kitsumed built ShizuCallRecorder because Android still has no supported call-recording path, and his post points at a thread on r/fossdroid where a repair-shop owner used it to capture the voicemail greeting of a customer’s deceased relative. “Your app worked on the first try, it took me like 90 seconds,” the shop owner wrote. That’s not a power-user flex. It’s a disability and grief workaround that exists because the platform left a gap.

Community reaction landed about where you’d guess. On Hacker News, commenter 3form cut to the objection: “If I want to bind ADB to localhost, let me.” On r/Android the thread ran 346 comments deep and the top-voted reply was five words: “Whats the point of android anymore”. Kitsumed, to his credit, opened his post by asking readers not to brigade the tracker, warning that spamming it “will only cause Google developers to lock the issue, ignore valuable community feedback, or stop sharing public updates about this change entirely.”

The security case is real

Here’s the part the angry replies skip. A localhost ADB socket is a genuine privilege-escalation surface. An app that reaches an ADB session gets WRITE_SECURE_SETTINGS and a shell running as the shell user, which is most of the way to owning the phone. No exploit is needed if a scammer on the other end of a call can walk someone through Developer Options, and coercion is exactly the threat Google names in its June developer-verification post, which promises “security checkpoints to resist coercion scams” in the new advanced sideloading flow.

Kitsumed’s rebuttal is the strongest thing in his writeup, and it’s structural rather than emotional. A malicious app can’t start adbd. It can’t switch on Developer Options, can’t complete a wireless pairing code, can’t tap Allow on the authorisation prompt. Every route to an on-device session passes through a human doing several deliberate things in Settings. “There is a difference between preventing it by default and permanently preventing it,” he writes, arguing for a reboot-surviving toggle rather than a hard block. Android already ships switches with a worse risk profile. Accessibility services and device-admin grants hand an app more power than a shell does, and nobody’s proposing to delete them.

My read: wlan0-only is a bad fix to a real problem, and it probably gets walked back, if only because it also breaks Ethernet debugging, tethered debugging and the VPN setups Google’s own engineers use. The direction of travel worries me more than this specific patch. The June post states plainly that “Unregistered apps can be sideloaded with Android Debug Bridge (adb) or advanced flow,” which makes ADB the sanctioned escape hatch from developer verification when registration starts biting on September 30 in Brazil, Indonesia, Singapore and Thailand. Narrow on-device ADB and that escape hatch quietly becomes “own a computer.” Android 17 shipped in June with floating bubbles and tighter location controls and didn’t touch any of this, while the same month Play Integrity locked GrapheneOS users out of a Volkswagen app. The gates ratchet one notch at a time, and the people who route around them keep building anyway, which is how projects like LibrePods happen.

Watch the code, not the commentary. The signal that this has stopped being a conversation is a change in platform/packages/modules/adb that touches the listener setup and hard-codes an interface name. Nothing like that has been uploaded. If you depend on Shizuku, the useful move right now is unglamorous: write your actual workflow into issue 526109803 once, then leave it alone, because a comment thread is the only input Google is taking on this.