Android may soon restrict on-device ADB

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.

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.

ADB , also called A ndroid D ebug B ridge, 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:

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 lies in the response from one of ADB core maintainers:

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 .

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.

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 .

As this is gaining traction, I’ve seen a few users mention that bad actors could automate some actions once the user is tricked into giving the accessibility permissions.

This is true today for sideloading (not for apps on the Play Store due to Google rules and restrictions). However, the proposed solution would also address this issue . So if Google comes out and uses this as a justification, it’s in my own eyes most likely just an excuse rather than a real limitation that “force them” to do it.

They could still restrict this behavior by default, as proposed in my blog post, while allowing developers to disable that restriction using a second computer , at this point, it becomes assumed risk that you connected via ADB via USB, ran the commands, and disabled the restriction. There is no more “accessibility permit exploitation” as it would by default be blocked.

I also still believe, as I mentioned previously, that there needs to be a reasonable balance between functionality and security . Just because a user could grant a malicious app the ability to do something harmful doesn’t mean we should block the functionality entirely.

If we follow that logic, no one should be allowed to choose their own keyboard app because it could be a keylogger. Accessibility services would be too dangerous for us because they can view and interact with the screen. VPN apps could intercept or monitor all network traffic. Device Administrator capabilities could be abused to lock a user out of their device or make an app difficult to remove. Apps with the “Draw over other apps” permission could be abused for tapjacking or phishing attacks by displaying deceptive overlays. The same reasoning could be applied to many other powerful Android permissions and capabilities . At some point, there needs to be a balance between mitigating risks and preserving legitimate functionality.

Granting accessibility permissions is already a significant hurdle (8 to 12+ steps), and every security prompt shown during the process is very explicit that doing so is dangerous . If someone chooses to proceed despite multiple clear warnings explaining the risks , even if they are beeing scammed, they likely would have fallen to many other types of scams. Justifying a complete lockdown is, in my opinion, not appropriate when there are alternative solutions (as mentioned in the blog) that effectively address the same concerns while not implementing breaking changes.

JavaScript is required to load comments. The JavaScript widget is loaded ONLY when you press the button. This blog uses Giscus to manage comments via GitHub Discussions. ( Privacy Policy here ). If you do not want to allow a third-party app to comments, you can also leave comments directly on GitHub by visiting the Blog Comments section .