Google Considers Restricting Local ADB, Putting Shizuku at Risk

⏱️ Lectura: 11 min

An ADB maintainer at Google wrote, in a public Issue Tracker thread, that the team is evaluating restricting the protocol’s local connections to curb so-called bad actors. The proposal, if it moves forward, would break the workflow of Shizuku, the framework that thousands of developers use to access system APIs without rooting their phone.

📑 En este artículo

1. TL;DR
2. What Happened
3. Background: What ADB Is and Its Three Connection Modes
4. On-Device ADB: The Mechanism Behind Shizuku
5. Shizuku, libadb, and Real-World Use Cases
6. How to Try It Today: Local ADB and Shizuku Step by Step
7. Impact and Analysis
8. What’s Next
9. Frequently Asked Questions
   1. What is Shizuku and why does it depend on local ADB?
   2. Has Google already confirmed it will restrict local ADB?
   3. What’s the difference between ADB over TCP/IP and Wireless Debugging?
   4. What other apps would be affected besides Shizuku?
   5. How can I give Google feedback about this change?
   6. Is there an alternative if Google restricts ADB loopback?
10. References

There’s no official announcement or implementation date. The case was documented by the developer who goes by Kitsumed, creator of the Shizuku-based app ShizuCallRecorder, in a blog post that compiles the entire thread.

TL;DR

• An ADB maintainer at Google commented on an Issue Tracker thread that they’re evaluating restricting local ADB to curb bad actors.
• It’s not an official announcement: it’s a comment on a feature request that’s still open, with no confirmed implementation date.
• The restriction would affect Shizuku, the framework that grants access to system APIs without rooting the phone, and libraries like libadb.
• Android supports ADB over USB, over unencrypted TCP/IP on port 5555, and over encrypted Wireless Debugging since Android 11.
• On-device ADB isn’t an official term: it describes running the ADB client and daemon on the same phone, without a PC.
• Developer Kitsumed, creator of ShizuCallRecorder, documents legitimate uses like recording calls due to a disability.
• Google is asking for detailed technical feedback on the Issue Tracker and warns that spam in the thread could get it closed.

What Happened

The debate originates from an open feature request on Google’s public Issue Tracker, the system where anyone can report bugs or request changes to its products. In the comments of that thread, one of the main ADB maintainers, a Google employee, proposed restricting local ADB connections as a security measure.

Kitsumed clarifies on his blog that this isn’t a product announcement. It is, in his words, an early signal worth taking seriously without causing panic. The author himself asks the community not to fill the thread with low-quality comments (complaints, insults, monopoly accusations), because that tends to make Google lock the issue or stop sharing public updates on the topic.

The recommendation for affected developers is concrete: if you have a unique use case, write a detailed, technical comment describing your actual workflow, with links or compromise solutions. If your case has already been mentioned, it’s enough to +1 the issue and turn on notifications to follow the discussion.

Background: What ADB Is and Its Three Connection Modes

ADB stands for Android Debug Bridge, a protocol Google designed so developers can run low-level tasks on a device: install apps without going through the Play Store, read system logs, grant permissions that normally require manual interaction, or simulate keyboard and screen events. It’s a standard tool in any Android workflow, documented in the official ADB reference.

ADB was originally built for USB cables, but over the years it gained two more ways to connect a client and a device:

• USB: the original mode. The client runs on the computer and connects to the phone via cable.
• TCP/IP: enabled once an active ADB connection already exists. It runs in plain text over port 5555 by default and asks to confirm the connection with a simple yes or no on screen.
• Wireless Debugging: arrived in Android 11 to replace the TCP/IP flow. It pairs the computer with the phone using a code or a QR code and, from there, opens an authenticated, encrypted session without needing a prior ADB connection.

Mode	When It’s Used	Advantage	Limitation
USB	Cable debugging, first pairing	Stable, doesn’t depend on the network	Requires a cable and driver on the computer
TCP/IP (port 5555)	Scripted automation, with an already active session	No cable needed after the first connection	Unencrypted traffic, only confirms with yes or no
Wireless Debugging	Pairing from scratch, Android 11+	Encrypted, authenticated session, no prior connection needed	Must re-pair if the Wi-Fi network changes
On-device ADB (loopback)	Frameworks like Shizuku, no computer	Grants system permissions without rooting	The mode Google is considering restricting

On-Device ADB: The Mechanism Behind Shizuku

The originally intended use for ADB requires two devices: the phone runs the daemon (adbd) and a computer runs the adb client. Not every developer has a second machine on hand. That’s how the community came up with what it calls on-device ADB: running the client and daemon on the same phone, connecting to itself via loopback, either through local TCP/IP or through Wireless Debugging paired with the device itself.

That trick is the foundation of Shizuku, an open source framework that exposes system permissions and APIs (the same ones ADB uses) to regular apps, without requiring the user to root their phone. Once active, compatible apps request authorization through the Shizuku manager and then call functions that would otherwise be blocked for an app installed from the Play Store.

💭 Key point: On-device ADB isn’t an official Google term. The community uses it to describe any flow where the ADB client and daemon run on the same phone, without going through a computer.

Shizuku, libadb, and Real-World Use Cases

Kitsumed uses Shizuku for ShizuCallRecorder, an app that records calls. He built it to compensate for a disability of his own: he can live without it, he says, but daily life is simpler with the app running. He also mentions discovering uses he didn’t expect, like a person on Reddit who used it to preserve a deceased loved one’s voicemail.

Call recording on Android has been a thorny topic for years. There was an official attempt to add it as a native API in Android 11, which Google later scrapped. Meanwhile, closed-source apps circulate that solve the problem with privacy-invasive methods, and some manufacturers force an audio notice like This call is being recorded even in places where it’s not a legal requirement.

The underlying argument, according to Kitsumed: if Google closes the door on local ADB without offering an alternative, the signal users with real needs receive is that the transparent path stops existing and only closed, less auditable solutions remain.

How to Try It Today: Local ADB and Shizuku Step by Step

For the classic two-device flow, you need Android platform-tools installed on your computer. The installation varies depending on the operating system:

# Windows (PowerShell)
winget install --id Google.PlatformTools

# macOS (Homebrew)
brew install android-platform-tools

# Linux (Debian/Ubuntu)
sudo apt install android-sdk-platform-tools

# Pair via Wireless Debugging (Android 11+)
adb pair 192.168.1.42:41381
adb connect 192.168.1.42:38217
adb shell getprop ro.build.version.release

The adb pair command uses the code your phone shows under Settings > Developer Options > Wireless Debugging. The last command confirms the session is alive by returning the installed Android version.

For the on-device flow, install the Shizuku app from its official repository and activate it using the Wireless Debugging option directly from the system Settings, without going through a computer. Once the Shizuku manager shows an active status, any compatible app can request the permission:

val binderActivo = Shizuku.pingBinder()
if (binderActivo && Shizuku.checkSelfPermission() == PackageManager.PERMISSION_GRANTED) {
    val proceso = Shizuku.newProcess(
        arrayOf("pm", "grant", packageName, "android.permission.READ_CALL_LOG"),
        null,
        null
    )
    proceso.waitFor()
} else {
    Shizuku.requestPermission(CODIGO_SOLICITUD_SHIZUKU)
}

That snippet requests the Shizuku binder, checks whether the app already has permission, and if it does, runs a command with privileges equivalent to those of an ADB session. To confirm Shizuku is still running from the terminal, you can run adb shell dumpsys activity services rikka.shizuku and look for the running state in the output.

flowchart TD
A["Shizuku-compatible app"] --> B["Shizuku Manager (rish)"]
B --> C["Local ADB (loopback)"]
C --> D["Android system APIs"]
subgraph "Same device"
B
C
D
end

Impact and Analysis

If Google restricts local ADB, the impact won’t fall on Shizuku alone. Any tool built on top of libadb or on the process Shizuku leaves running loses its access path: automation tools like MacroDroid or Tasker with Shizuku modules, accessibility apps, and debug utilities that run directly from the phone without a computer.

The security argument has technical grounding. Local ADB, since it doesn’t require a second machine, is easier to automate from a malicious app than a traditional flow that requires human intervention on a separate computer. Kitsumed acknowledges this on his blog, though he insists that most real-world use is legitimate and that blocking the entire mechanism punishes valid use cases along with abusive ones.

⚠️ Heads up: Google’s argument for restricting local ADB is about security: a malicious app that automates pairing could try to escalate privileges without the user noticing. It’s a different concern, but related to Google’s recent changes to Android’s sideloading policies.

For developers in Latin America who rely on Shizuku for accessibility, automation, or testing apps, the signal worth watching closely isn’t the timeline (there isn’t one yet), but what kind of technical compromise Google proposes if the change moves forward: an additional explicit permission would be far less disruptive than a total block on loopback.

What’s Next

There’s no date or public product document. Kitsumed mentions he saw recent task-assignment updates related to whoever was leading ADB work at Google, which could mean the matter is moving forward internally, though there’s no confirmation of what shape the final change will take.

The recommendation remains the same: developers with a concrete use case should leave detailed, technical feedback on the Issue Tracker, with their actual workflow and, if possible, a compromise proposal. The rest of the community can add a +1 to the issue and turn on notifications to follow the discussion without flooding the thread.

📖 Summary on Telegram: View summary

Try it yourself: install platform-tools, pair your phone with adb pair, and add your use case to the Issue Tracker feature request before Google makes a final decision.

Frequently Asked Questions

What is Shizuku and why does it depend on local ADB?

Shizuku is an open source framework that uses the same permission channel as ADB to give regular apps access to system APIs, without requiring root. It needs an ADB session, either via Wireless Debugging or loopback, to start its process with elevated privileges.

Has Google already confirmed it will restrict local ADB?

No. The only public information is a comment from an ADB maintainer on an Issue Tracker feature request. There’s no changelog, date, or official product document yet.

What’s the difference between ADB over TCP/IP and Wireless Debugging?

TCP/IP runs over unencrypted port 5555 and needs an already active ADB connection to be enabled. Wireless Debugging, added in Android 11, pairs via a code or QR code and opens an encrypted session without depending on a prior connection.

What other apps would be affected besides Shizuku?

Any tool built on top of libadb or on Shizuku’s process: automation tools like MacroDroid or Tasker with Shizuku modules, accessibility apps, and debug utilities that run directly from the phone.

How can I give Google feedback about this change?

If you have a specific use case, add a detailed, technical comment on the Issue Tracker with your actual workflow. If your case is already mentioned, it’s enough to +1 the issue and turn on notifications.

Is there an alternative if Google restricts ADB loopback?

Not yet. That’s why Kitsumed is asking for technical feedback on the thread: the idea is for Google to consider a compromise, like some kind of explicit permission, instead of blocking the mechanism entirely.

References

• Kitsumed Blog: original post documenting the Issue Tracker thread about restricting on-device ADB.
• Android Debug Bridge (official reference): Google’s documentation on ADB’s USB, TCP/IP, and Wireless Debugging modes.
• Shizuku on GitHub: official repository of the framework that exposes system APIs without root using ADB.
• Google Issue Tracker: public system where bugs and feature requests for Google products, including ADB, are reported.

📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Imagen destacada: Foto de Fahim Muntashir en Unsplash