Before we dive in, please note that this is not an official Google announcement. Instead, this is based on a recent, ongoing feature request on Google IssueTracker, in which a comment by one of the core ADB maintainers (Google employee) talked about restricting On-Device ADB connections to protect from “bad actors”.

Before you stop what you are doing to head over to that IssueTracker thread, please read this carefully:

If you plan to visit the issue tracker just to post low-quality comments (such as “Hey, don’t do this, I need Shizuku!”), complaints about monopoly, or insults, I highly recommend that you refrain from doing so. Spamming the thread will only cause Google developers to lock the issue, ignore valuable community feedback, or stop sharing public updates about this change entirely.

I think a change like this could benefit Google as it goes well along their new Sideloading changes, but I do not actively believe this is what is going on here. There is a true, valid reason behind this, and I think two different approach can be taken. We will talk about it in this blog post.

How You Can Help:

• If you have a unique use case: If you are directly affected and can write a detailed, constructive message explaining your workflow, providing links, or offering technical solutions/compromises, please, by all means, share your feedback in Google issue.
• If your use case has already been mentioned: You do not need to repeat it. Instead, simply click the +1 button in the top right corner of the Google IssueTracker to let Google know you are affected, and toggle notifications to stay updated on the discussion.

I am hesitant to make this blog post, as I fear it may overload the few developers that work on ADB. I am unsure if I should wait more and see what happens or hold it longer and see what approach they take. Waiting too long could also be bad… As of writing this, I am unsure when/if this post will release. I saw some recent updates on assignments which were given to the main guy who previously worked on ADB, so we will see what happens.

Hi! I’m Kitsumed, developer of ShizuCallRecorder, a Shizuku based application. As you may have guessed by now, I would be affected by this change. Obviously, I would really like it if they do not proceed with it in a way that prevent loopback connections.

To talk briefly about myself, I made ShizuCallRecorder to help with some of my own disabilities. I can get by without it, but it’s much easier with it.

You could say I have a very unique use case, and I keep discovering other unusual ones, like this person on Reddit, who used my application to preserve the voicemail of a deceased loved one.

Call recording on Android is a complicated topic. There are countless user requests, an official attempt to add the feature in Android 11 that was later canceled, and many closed-source, privacy-invasive applications that use work-arounds.

I used to hear that many users with disabilities had to trade their privacy for an easier daily life. I guess that’s what people mean when they talk about those trade-offs.

Don’t even get me started on OEMs that force an audio warning such as “This call is being recorded,” when it’s in places where it’s not legally required. People often don’t react well to that, even if you explain why you’re recording the call, it gives a bad impression. To be honest, I probably wouldn’t react well to it either.

I’m sure most of you have a more “power-user” use of Shizuku or even use loopback ADB for developer tasks. I do those too, but I wanted to point out one of my unique use case.

Alright, back on the main topic. Before I explain what the proposed change is, I’m going to explain what is ADB for less technical users.

What’s ADB?

ADB, also called Android Debug Bridge, is protocol created by Google to let developers do developer things on Android devices…

Basically, it grant us a high level of privileges, give us access to a lot of sensible commands to tests how the phone and application behave. Useful stuff for any developers or power-users.

ADB was originally designed to work over a USB connection, but later expanded how it could works:

• USB: The original way. ADB communicates directly over a USB cable.
• TCP/IP: Introduced as a way to run ADB over a network using an IP address and port (typically port 5555). The connection carries ADB traffic in plain text and provides a YES/NO prompt as authentication. Can only be enabled once you already have an active ADB connection.
• Wireless Debugging (Wifi 1.0/2.0): Introduced in Android 11, it aims to improve the legacy TCP/IP workflow. It requires pairing the computer with the device using a pairing code or QR code, then establishes an authenticated and encrypted connection for subsequent ADB sessions. It does not require an active ADB connection to be enabled.

What’s a On-Device ADB connection?

ADB was originally intended to be used with two devices (simplified explanation): the Android device being debugged run the ADB Daemon (ADBD) and a separate developer machine run the ADB client. In practice, however, this setup is not always convenient. Some developers work directly from their Android device and do not have access to a second machine.

This led to usage of On-Device ADB (this is not a official term). By using a terminal emulator such as Termux, developers can run an ADB client directly on their phone and establish a connection to the local daemon (ADBD) server using either ADB TCP/IP or Wireless Debugging. Since both the client and server are running on the same device, the connection is made through the loopback address (127.0.0.1). That’s what I call On-Device ADB.

While this is a niche use case compared to how ADB intended to be used, it has led to the creation of projects such as libadb-android by MuntashirAkon and Shizuku by RikkaApps. These projects, along with many others, have created a large open-source community that made a wide range of tools for developers and power-users.

A new feature was made on Google IssuerTracker to allow developers to choose what interface ADBD (ADB server daemon) would listen to.

This feature was proposed following a major security issue identified as CVE-2026-0073, which allowed the Wireless ADB authentication process to be fully bypassed. What is proposed in this issue is actually a nice idea.

Right now, ADBD makes itself available on every network your phone is connected to. This feature request asks to let developers choose which interface is chosen, reducing the exposure.

The problem

The problem lies in the response from one of ADB core maintainers:

sa…@google.com:

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 ?

Here, we can see that the employee talk about only allowing wlan0, the interface of the Wifi connection. Doing so would break many things, On-Device ADB, ADB via VPN, ADB via Ethernet, and many other unique developers setups.

Another issue I see here is the stance they seems to currently have on “On-Device ADB”. Their comment suggests that On-Device ADB is viewed primarily as an exploit bad actors can use to elevate privileges, yet there a lot of legitimate usages of on-device ADB. Developers themself uses it when they can’t access a computer.

While it can indeed be used to elevate privileges, a “malicious” application cannot do so alone. It requires multiples actions that MUST be perfomed by a human.

Why On-Device ADB Is Not Really Used by Bad Actors

A malicious application could use an on-device ADB connection to perform privilege escalation. However, it cannot establish one by itself.

To illustrate this, I’ve laid out the general limitations a bad actor would face in a few scenarios, similar to my comment on IssueTracker.

Scenario 1: General Android Users

1. You install a malicious application.
   • ADB is disabled. ADBD is not running, and the application does not have the WRITE_SECURE_SETTINGS permission, as it must be manually granted via ADB. No exploitation attempts are possible.

Scenario 2: A Developer on Android 11+ Using Wireless ADB

1. You install a malicious application.
2. You enable USB debugging, starting ADBD.
3. You enable Wireless ADB. ADBD is now running on your phone and listening on all network interfaces.
4. The application would need to perform the one-time pairing process. This requires the user to manually retrieve the one-time code from Settings and provide it. No exploitation attempts are possible.

Scenario 3: A Developer Using ADB over TCP/IP

1. You install a malicious application.
2. You enable USB debugging, starting ADBD.
3. You connect via USB ADB to enable TCP/IP, then disconnect the USB cable.
4. ADBD continues running and listens on all network interfaces.
5. The application initiates a connection, causing an authorization prompt to appear on the screen. If the user selects No, the connection is rejected. No silent exploitation attempts are possible.

In a normal scenario, a bad actor cannot gain an ADB connection. It is only possible while the developer is actively using ADB on the device, because a bad actor cannot start ADBD by themselves.

However, if we return to a scenario such as CVE-2026-0073, exploitation would become possible in Scenarios 2 and 3, but only after the user has manually enabled USB debugging. As for scenario 3, it would also require the developer to MANUALLY enable TCP/IP. I can understand the motivation for preventing loopback connections by default, but not to fully prevents it.

There is a difference between preventing it by default and permanently preventing it. I think this should be something users can disable through a persistent setting. By this, I mean a toggle that survives a reboot (else it would make tools like Shizuku impracticals) and, ideally, cannot be read by third-party applications. Otherwise, developers would have to repeatedly disable it whenever banking apps or games detect that on-device ADB is availabl. That said, this part could be worked around once a application is manually granted WRITE_SECURE_SETTINGS.

I think that justifying blocking it because a human could perform actions to allow it would be far-fetched. A human could also designate a malicious application as a device administrator or grant it Accessibility permissions, and yet we would not get rid of those features.

I believe it should be an assumed risk that disabling such a security feature enables on-device debugging while also exposing the device to the rare possibility of a future vulnerability. To me, the feature/risk ratio make sense here, as there is a real, legitimate usage.

Although it may have not been originally intended, On-Device ADB has enabled a niche ecosystem of developer and power-user tools, including projects such as App Manager, libadb-android, Canta, aShell, ShizuWall, ShizuCallRecorder and Shizuku.

To conclude, I would like to mention my conclusion in What Is Shizuku? How Does It Work? Security Implications?, where I said as a joke:

Here’s my closing thought: I can’t wait to see how they’ll justify disabling loopback ADB over TCP/IP connections on non-emulator devices and start requiring a Google account…

Well I guess they may indeed disable loopback ADB. Huh… I was almost 100% right on that one I guess. If you are a technical user, I invite you to give your feedback inside the issue here. Please don’t forget the early warning.