If you often tinker with your mobile phone or develop applications, sooner or later you end up using ADB (Android Debug Bridge) for talk to your device from your computerFor years the USB cable was mandatory, but since Android 11 things have changed: now you can use ADB completely. via Wi-Fi, without plugging anything in.
With the advent of Wireless debugging is integrated into Android 11 and later versions.Google has added a secure pairing system using QR codes or PINs, compatible with Android Studio and also with the command line. In addition, classic TCP/IP methods, automations with Termux and Tasker, and solutions like LADB or Remote ADB still work, so There are options for virtually any scenario..
What is ADB and how does it fit into wireless debugging?
ADB, short for Android Debug Bridge, is a A command-line tool that acts as a bridge between your development machine and the Android deviceIt is designed for debugging and testing apps, but in practical terms it is a Swiss Army knife for advanced users: installing and uninstalling applications, accessing a Unix shell, copying files, recording the screen, taking screenshots, managing permissions, user profiles and even company policies.
Internally it is based on a client-server model: on your PC it runs the adb client and a server listening on port 5037, while on the mobile device or emulator the daemon runs adbd which is the one that actually receives and executes the commands. The server scans ports (for example, 5555-5585 in emulators) and maintains active connections with all available devices.
When you connect via USB or Wi-Fi, you can check adb devices -l to see the list of devices and their statusTo execute commands against a specific device, use -s serial_number or the -d (physical device) and -e (emulator) options. If there is more than one device and you don't specify it, you will receive the typical "more than one device/emulator" error.
The big leap with Android 11 was allowing that same bridge to be created securely over the wireless network, without always having to start with a USB cableWireless debugging works with a pairing system using a QR code or numeric code, relies on mDNS to discover devices, and has extra security controls to prevent anyone from connecting to your mobile phone without permission.
ADB also includes a whole collection of advanced commands: am (Activity Manager), pm (Package Manager), dpm (Device Policy Manager), screencap, screenrecord, forward, pull/push, sqlite3etc. All of this is available in exactly the same way when you work via Wi-Fi, so the only real difference is the medium of transport.
Requirements for using wireless ADB on Android 11 or higher
Before you go crazy with commands, it's a good idea to make sure that The minimum conditions for wireless debugging to work are metIf any of these points fail, you can waste hours not knowing why it won't connect.
On the phone side, you need the device to run at least Android 11 (API level 30) to have the Wireless Debugging menu within Developer Options. In Android 13, compatibility is expanded to include TV and Wear OS, although the pairing process is very similar.
It is essential that both the mobile device and your development machine are connected to the same Wi-Fi networkIt's no good having your PC connected via Ethernet to a corporate VLAN and your mobile device on a different network. Many user reviews mention a very specific drawback: if you're not on Wi-Fi, Android itself does not allow you to enable Wireless DebuggingIt does not work over mobile data.
Another critical point is the version of the tools: on the computer you must have the updated Platform-tools (the package that includes adb) And, if you're going to use a graphical environment, a recent version of Android Studio (Bumblebee or higher) that includes the "Pair devices using Wi-Fi" assistant.
In more closed work environments, the network firewall may block traffic. It is important that Ensure that port 5555 (or the one you use for ADB) is not filtered and that the network does not block p2p connections.If you're having problems, sometimes the solution involves using your own access point, mobile tethering, or simply using ADB over Ethernet.
Enable Developer Options and Wireless Debugging
The first thing to do on any modern Android device is Enable Developer Options and enable debug modesAlthough the menu names may change slightly depending on the interface (One UI, MIUI, Pixel, etc.), the procedure is virtually identical.
To show hidden options, go to Settings > About phone (or About device) and tap several times in a row on Build numberAfter a few taps, the system will notify you that you are now a developer, and the new menu will usually appear within System or Additional Settings.
Once you have that menu in view, use the Settings search bar to quickly locate it. "Developer options" and access them without having to search.Inside you'll see several blocks: debugging, networking, tracing, animations, etc. This is where the key switches for ADB are located.
In the debugging section, first activate USB debuggingwhich will come in handy for any emergency and for the classic TCP/IP method. The switch is usually located right below it. Wireless debugging or debugging over WLANWhen you activate it, the system will display a notification about the current Wi-Fi network and ask for explicit confirmation.
It is highly recommended to select the option to "Always allow on this network" if it's your trusted Wi-Fi.This way you won't have to accept pop-ups every few minutes. Remember that you can't enable this mode if your phone is only using mobile data: it must be connected to a wireless network.
Pair devices from Android Studio using a QR code or PIN
If you already use Android Studio for programming, it's quite easy, because modern versions include a Visual assistant for linking physical devices via Wi-FiIt is the most convenient method for debugging without writing hardly any commands.
With your project open, go to Open Device Manager and go to the Physical tab to view the physical terminals.At the top you will find the option Pair using Wi-Fi or Pair devices using Wi-Fi, depending on the exact version of the IDE you are using.
Clicking on that option opens a pop-up window with two main tabs: “Pair using QR code” and “Pair using pairing code”The first tab directly displays a large QR code ready to be scanned.
That QR code contains a connection profile and pairing data generated by Android Studio. However, if you scan it with another app, you'll see that it includes Network information and ADB parameters; you shouldn't use it outside of the system's own wireless debugging flowThe valid reader is always the one in Developer Options.
On your mobile device, with Wireless Debugging enabled, enter this menu and tap “Link device with QR code”The camera will open in scanner mode; point it at the code displayed on the Android Studio screen and wait a few seconds. If everything goes well, the pairing will be complete and the PC will be listed as an authorized workstation.
When the QR reader fails for any reason (the camera isn't focusing properly, there are network problems, etc.), the alternative is to use the tab “Pair using pairing code”, which uses a six-digit code along with the IP and portIn Android, you choose "Link with sync code" and in Android Studio you enter that code when the wizard detects the device.
Pair and connect using only the command line (adb pair / adb connect)
If you don't want to install Android Studio or simply prefer to use the console, Android 11 and higher allow you to... Use the wireless pairing system directly with the commands adb pair and adb connectThe flow is similar to that of the graphical assistant but 100% via terminal.
With Wireless Debugging enabled, open the corresponding menu on your mobile device and tap the option “Link device with synchronization code”On the screen you will see an address like 192.168.xy:pairing port and a six-digit PIN code valid for a few minutes.
On your computer, open a terminal and navigate to the folder where you have Platform-tools installed. If you haven't added it to your system PATH, you'll need to navigate manually to something like android_sdk/platform-tools or %LOCALAPPDATA%\Android\SDK\platform-tools on Windows so that the adb command is recognized.
From there, execute adb pair IP:PORT Using the information you see on your phone, for example, `adb pair 192.168.1.25:37119`, the tool will ask you to enter the six-digit pairing code. If it matches the phone's code and the network isn't blocking anything, the pairing will be recorded.
That pairing isn't yet the debug connection itself; to truly use ADB, you need to look at the list of “Linked devices” within Wireless Debugging, where another IP:port appears associated with your workstation. That second combination is the one you will use with adb connect, for example adb connect 192.168.1.25:5555.
Classic method: ADB over Wi-Fi after an initial USB connection
Before Android 11 arrived, the only way to work wirelessly with most mobile phones was Enable ADB over TCP/IP on a known port (usually 5555) after an initial USB connectionThis trick still works perfectly well, both on Android 10 and earlier versions as well as on modern devices.
The first step is to connect the mobile phone to the computer via USB, making sure that USB debugging is enabled and you accept the RSA key dialog when the PC attempts to debug the device.If you do not accept, you will see the terminal as "offline" when you run adb devices.
When adb devices lists your phone as “device”, you can launch the command adbtcpip 5555This instructs the device's adbd daemon to begin listening for incoming ADB connections on port 5555 over the network interface. Once the command executes successfully, you can disconnect the USB cable.
At that point you will find your Android's internal IP address in Settings > About phone > Status > IP address or directly within the Wi-Fi menu, depending on the brand. That address, combined with port 5555, is what you'll use from your PC to connect: adb connect 192.168.xy:5555.
If everything is correct, `adb devices` will now show an entry of the type `192.168.xy:5555 device` And you'll be able to use the exact same commands as if you were still connected via USB. Keep in mind that if the terminal changes networks, restarts, or receives an update, you'll likely have to repeat the USB + tcpip process.
ADB over Wi-Fi and over Ethernet in special environments (Chromebook, restricted networks)
In Chromebooks and corporate environments, the story gets a little more complicated, because ADB over USB is not always supported, and many networks block ports or P2P traffic.In these cases, both standard wireless debugging and Ethernet solutions are used.
Google documents a generic flow for ADB over Wi-Fi on any device: Connect your PC and Android device to the same network, ensure port 5555 is free in your firewall, enable `adb tcpip 5555` if necessary, and finally, use `adb connect IP:5555`.It is exactly the classic method, but emphasizing control over the network.
When Wi-Fi is heavily filtered or direct traffic between clients is not allowed, a reliable alternative is Pull ADB over EthernetTo do this, you connect your mobile device (or Chromebook) and PC with a physical cable, assign IP addresses within the same range (for example, 192.168.1.2 for the device and 192.168.1.3 for the computer) and connect with adb connect 192.168.1.2:5555 after having enabled adb tcpip if necessary.
On Linux and macOS, you can manually configure the Ethernet interface IP address; on Windows, you need to access the TCP/IPv4 properties. On Chromebooks, the setting is done from the crosh command prompt and the ChromeOS shell, using `ifconfig` on the eth0 interface (or the corresponding interface). 192.168.1.x as the address space reserved for this direct link.
Once the link is established and the ports are open, the ADB user experience is exactly the same as over Wi-Fi, only with the added stability of a wired connection. It's very useful for test labs, large-scale automation, or when the wireless environment is unreliable.
Use wireless ADB from your mobile device: Termux, Tasker, and Remote ADB
Besides the typical “PC + mobile” combination, there are configurations where you want Launch ADB commands from an Android device to another remote deviceor even automate the activation of ADB itself via Wi-Fi without relying on a computer. This is where tools like Termux, Tasker, Remote ADB, or LADB come into play.
Termux allows you to have a Linux terminal environment on your phone, where you can install Use `android-tools` with `pkg install android-tools` to have the adb executable on your mobile device.From there, with the Termux:Tasker plugin and the Tasker app, you can create bash scripts that automatically connect, pair, or change the adbd mode.
A typical setup involves creating the folder Run .termux/tasker and add scripts like adb.sh and adb_pair.shThe first accepts an IP address as an argument and executes `adb connect`, `adb tcpip 5555`, `adb disconnect`, and `adb kill-server`; the second receives the IP:port pair and the pairing code, executes `adb pair`, and then shuts down the server.
Tasker can invoke these scripts using the Termux action once you grant it the special permission to “Executing commands in the Termux environment” from the Android application settings. From there, you can define profiles that react to the device starting up, unlocking, connecting to a specific Wi-Fi network, or even key combinations such as a long press of the volume button.
There are complex profiles that, as soon as the phone is turned on, They reset a state variable (%ADB_enabled), enable "Debugging over WLAN", and monitor Logcat until they detect the line related to the Wi-Fi ADB port.They extract that port, call the adb.sh script to connect and switch to tcpip 5555, and finally disable wireless debugging because it is no longer needed.
LADB and other apps to simplify PC-free pairing
If you don't feel like wrestling with Termux and scripts, there's a fairly user-friendly alternative called LADB, an open-source project that offers a kind of "local mini ADB server" within the phone itself. The advantage is that It allows you to execute ADB commands without needing to use another device..
The basic flow consists of connecting to a Wi-Fi network, activating ADB Debugging and Wireless ADB Debugging In Developer Options, open LADB in split-screen mode next to System Settings. From there, go to Wireless ADB Debugging, choose "pair using code," and enter the following code into LADB: pairing code and port that Android shows you.
Once the pairing is successful (although sometimes the terminal output shows messages like “Shell is dead, resetting” while it is actually working), you can open the LADB help menu and Change the default startup command so that it runs `adb tcpip 5555` every time the app is launched.This way, by simply opening LADB after a restart, you automatically activate ADB over Wi-Fi.
By combining LADB with Tasker, it is possible to set up simple tasks that, after connecting to a Wi-Fi network, Enable Wireless Debugging, wait for your confirmation in the pop-up, start LADB until ADB over Wi-Fi is activeClose the app and disable wireless debugging again so you don't leave it open unnecessarily.
Another interesting app is Remote ADB, designed to a phone acts as a “controller” and connects via Wi-Fi to other devices (for example, to send commands to an Android tablet or TV). On Android 12 and higher, it takes advantage of the built-in pairing interface: you enable Wireless Debugging on the target device, generate a pairing code, and from the controller terminal, you let the app scan the environment and connect by entering that code.
Main ADB commands useful when working wirelessly
Once the connection is established, whether with Android Studio, via the command line, with LADB, or using the TCP/IP trick, the important thing is to take advantage of it. the ADB commands you'll actually use on a daily basisLuckily, everything that works via USB works exactly the same way via Wi-Fi.
To verify that the device is accessible, the reference command is `adb devices -l` lists connected instances, their status (device, offline, unauthorized), and a brief description.If you see your phone as ip:port device, everything is fine. If you also need to control the screen, try scrcpy from Windows.
When multiple terminals are connected (emulators, physical mobiles, tablets, etc.), you can direct a command to a specific one with adb -s serial_number commandFor example, adb -s 192.168.1.25:5555 install app.apk, or set the ANDROID_SERIAL environment variable to avoid repeating the number each time.
In the app management section, the key commands are adb install route_to_apk to install a package, adb install-multiple when your app is divided into several APKs, and adb uninstall package.name (with the -k option if you want to preserve user data and cache when uninstalling).
To move files across the wireless connection, you will use adb push local_file remote_path (sending things to the phone, for example push myfile.txt /sdcard/myfile.txt) and adb pull remote_path local_folder to bring logs, screenshots, or any other file to the PC.
When you need to get “inside” the system, the foolproof command is adb shellThis opens an interactive shell on the device with access to Unix-like tools. From there you can use am to launch activities or services, pm to list, enable, or revoke packages, dpm to test device manager policies, or utilities like screencap, screenrecord, and sqlite3.
Advanced features: screenshots, screen recording, port forwarding, and more
The true potential of ADB becomes apparent when you start using it Its most advanced components for debugging apps, logging activity, or generating graphicsAnd the advantage of doing it via Wi-Fi is that you don't depend on the cable at any time.
To capture the screen, you can run adb shell screencap /sdcard/screen.png and then adb pull /sdcard/screen.png To bring the image to your computer. If you prefer to do it directly, `adb exec-out screencap -p > screen.png` generates a PNG directly on your local machine without any intermediate steps.
Another very powerful tool is the port forwarding with adb forwardThis allows you to forward a local port on the PC to a specific port or internal resource on the device. A typical example would be `adb forward tcp:6100 tcp:7100`, or even `adb forward tcp:6100 local:logd` to send everything received to the terminal's log system.
If at any point the ADB server starts behaving strangely—not responding, not listing devices, only showing "offline"—it's quite common to fix it with a simple `adb kill-server` to stop the background process and then implicitly restart it by executing any adb commandThis causes the server to perform a clean reboot and rescan devices and ports.
In recent versions of the Platform-tools, Google has also introduced a configurable burst mode with the environment variable ADB_BURST_MODE=1This improves transfer performance and reduces latency, which is especially useful when working over Wi-Fi and moving very large files or intensively debugging apps.
With all this arsenal, the combination of native wireless debugging in Android 11+, classic TCP/IP methods, Android Studio integrations, tools like Termux, Tasker, LADB or Remote ADB, and the appropriate network settings allows you to Work with your Android device from almost any environment without relying on a USB cable, with much more flexibility and without sacrificing any of ADB's advanced capabilities..
