The author spotted the adbd/netd diff in an internal Android build showing connections from the same device (127.0.0.1) will be refused, and published a working reproducer. They frame this as a deliberate lockdown that will break Shizuku, LADB, App Manager, Island, SystemUI Tuner, Brevent, and the broader non-root power-user stack the next time users reboot.
By submitting the post and driving it to 672 points, shscs911 amplified the concern that this patch — landing without any public Google comment — would silently kill a well-established pattern that senior mobile devs, security researchers, and privacy-minded users rely on to reclaim control over their own hardware.
The author acknowledges that pairing a device to itself over wireless ADB was a clever repurposing of a feature designed for a separate developer machine, not for granting apps shell-UID privileges on the same phone. From that framing, the adbd change reads less as a surprise attack and more as Google finally patching a semantic loophole that let ordinary apps escalate to the shell user without root.
A developer poking around a recent Android internal build spotted a change to the `adbd` daemon that refuses connections whose source address resolves to the same device. In plain terms: the wireless-debugging port on `127.0.0.1` — the one Shizuku, LADB, and a long tail of power-user apps quietly connect to — would stop answering. The write-up, published on kitsumed's blog and pushed to the top of Hacker News with 672 points, includes the relevant `netd`/`adbd` diff and a working reproducer against a preview image.
The mechanic being killed is well-known to anyone who has set up Shizuku the hard way. Android 11 introduced wireless ADB pairing so you no longer needed a USB cable. Shortly after, developers realized you could pair the device *to itself*: enable wireless debugging, grab the localhost port and pairing code from the Settings UI, and hand them to an app on the same phone. The app then speaks ADB to its own OS and can run privileged shell commands — package installs, permission grants, `appops` toggles, `settings put` — with the `shell` UID, no root required.
If the patch ships as written, that entire pattern breaks the next time a user reboots. Existing pairings survive until the ADB session drops; new ones fail immediately. Google has not publicly commented on the change, and it is not yet in a public beta channel, so the timeline is unclear. But the code is there, and the direction is not ambiguous.
Shizuku is not a niche curiosity. It is the substrate under a surprisingly deep stack of Android tooling that senior mobile devs, security researchers, and privacy-minded users depend on. App Manager uses it to inspect and revoke permissions the Settings app hides. Island and Insular use it to spin up work profiles for app sandboxing without an MDM. SystemUI Tuner uses it to flip tuner keys Google removed from the UI. LADB exists specifically to give you a shell. Brevent freezes background apps. Swift Backup pulls APKs and app data. Every one of these has a fallback story that is worse: require root, require a PC, or don't work.
The change is defensible on security grounds and lousy on developer-experience grounds, and both things are true at once. The loophole is genuinely a foothold — a malicious app that convinces a user to enable wireless debugging and share the pairing code (say, via a fake "tap here to grant permission" flow) gets shell-level access to the device. Google has been tightening this class of attack for years: scoped storage, the accessibility-service crackdown, `MANAGE_EXTERNAL_STORAGE` gating, the recent sideloading friction in Android 15. Blocking self-pairing is consistent with that arc. It is also consistent with the arc where Android becomes less of a general-purpose computer.
Community reaction on the HN thread splits along the predictable line. One camp: this was always a bug being exploited as a feature, apps should not have shell UID, good riddance. The other camp: the only thing standing between mainstream Android and a locked-down appliance was the ability of a determined user to grant themselves privileges on their own hardware, and that is now going away too. The interesting middle position, articulated by a few Shizuku contributors in the comments, is that Google could preserve the capability with a real permission gate — an explicit "grant this app shell access" toggle in developer options — but has shown no interest in doing so. The path of least resistance for the platform team is to close the hole and let the ecosystem sort itself out.
What is not being said out loud is that this closes one of the last on-device escape hatches on stock Android without rooting. iOS has never had one. Custom ROMs still will. The middle ground — a Pixel or Samsung running stock, owned outright, with the user granting themselves capabilities the manufacturer didn't ship — is the ground being narrowed.
If you ship an Android app that depends on Shizuku, start planning now. The fallback matrix is short and none of the options are good. A wired ADB flow works but requires a PC, which cuts your addressable users by an order of magnitude. A second Android device on the same Wi-Fi works for enthusiasts and no one else. Root works if the user has an unlockable bootloader and is willing to trip SafetyNet/Play Integrity, which breaks banking apps, Google Wallet, and increasingly ordinary things like Netflix downloads. There is no clean fourth option.
For tool authors specifically: the pragmatic move is to add a wired-setup path if you don't have one, document it clearly, and stop assuming the self-pairing trick will keep working. LADB's maintainer has already floated a companion desktop helper that speaks ADB over the network from a laptop, which preserves the "no root" pitch at the cost of the "no PC" pitch. Expect similar pivots from the rest of the ecosystem.
For security-conscious engineers building enterprise Android software, this is a mild win: one fewer social-engineering vector against your users' devices, and one fewer supply-chain worry about what a Shizuku-backed app might be doing. For anyone doing mobile security research, incident response, or forensics on a phone they don't have physical cables for, it is a real capability loss.
Watch for three things over the next few weeks. First, whether the change lands in the next Android 16 QPR beta — that would signal a real ship date rather than an experiment. Second, whether Google adds any developer-options escape hatch, which would be uncharacteristic but not impossible given the loud creator community around Shizuku. Third, whether the Shizuku maintainers publish a workaround; they've routed around platform changes before, and there may still be a legal path via a `content://` provider or a bound service that survives the netd check. If none of those materialize, budget a quarter for your migration and pick your fallback now — the users who cared enough to run your app via Shizuku will care enough to follow you to a wired flow, but only if you make it painless.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.