How to use ADB over Wi-Fi: wireless debugging and adb tcpip

There are two ways to put adb on Wi-Fi, and the Android version on the phone decides which one you get. Android 11 (API level 30) added Wireless debugging, which pairs with a six-digit code and never needs a cable. Anything older needs one USB connection first, then adb tcpip 5555 to move the phone’s adb daemon onto the network.

Both end in the same place. The phone shows up in adb devices as an IP and port instead of a USB serial, and everything built on adb (scrcpy, uiautomator2, Appium, Android Studio) behaves as if it were plugged in.

The ports are what trip people up.

This guide covers phones. Wear OS and Android TV devices need Android 13 or later for wireless debugging, according to the adb docs, and I haven’t covered their menus here.

What you need

A current copy of Android SDK Platform-Tools. Run adb version. At the time of writing the latest release is 37.0.1, from July 2026. An old adb that came bundled with some other tool causes a surprising share of the weird errors below.
The phone and the computer on the same network, and a network that lets two clients talk to each other directly. Guest Wi-Fi and a lot of office networks don’t.
Developer options unlocked: Settings, About phone, tap Build number seven times. Some manufacturer skins bury Build number one level deeper, under Software information.
For the legacy method only: a USB cable and the USB debugging toggle, once.

Step by step: wireless debugging on Android 11 and later

1. Turn on Wireless debugging

It lives in Developer options, and the path to it varies by skin while the toggle name stays the same. The phone asks whether to allow wireless debugging on the current network. Ticking “always allow on this network” marks that network as trusted.

If it breaks: the toggle needs an active Wi-Fi connection. With Wi-Fi off, or on mobile data only, it won’t stay on.

2. Get a pairing code

Tap “Pair device with pairing code”. The dialog shows a six-digit code plus an IP address and port, something like 192.168.1.42:37123. Leave the dialog open until pairing finishes.

If it breaks: closing the dialog throws the code away. Open it again and use the new code and port.

3. Pair from the computer

adb pair 192.168.1.42:37123
Enter pairing code: 482913

Current Platform-Tools also accept the code as a third argument, which is handy in a script:

adb pair 192.168.1.42:37123 482913

If it breaks: a wrong-password or dropped-connection error nearly always means the code expired, or you copied the port from the main Wireless debugging screen instead of the pairing dialog.

You only pair once per computer. The Android docs say the device stays paired until you forget it or revoke adb authorizations on the phone.

4. Connect with the other port

This is the step everyone gets wrong. The port in the pairing dialog is for pairing and nothing else. The main Wireless debugging screen shows a separate “IP address & Port”, and that’s the one adb connect wants:

adb connect 192.168.1.42:41235
adb devices -l

On a network where mDNS works you can often skip this. After pairing, adb finds the phone by itself and lists it under a service-style serial along the lines of adb-R58M12ABCDE-a1b2c3._adb-tls-connect._tcp. To see what adb can discover:

adb mdns check
adb mdns services

If it breaks: failed to connect right after a successful pair means you reused the pairing port. Read the port off the main screen again.

5. Expect the connect port to change

The connect port isn’t fixed. Toggle Wireless debugging or reboot the phone and it picks a new one, so a script with :41235 hard-coded works today and fails tomorrow. Read the port fresh from adb mdns services each time, or let mDNS auto-connect handle it.

6. Or pair with a QR code from Android Studio

Android Studio’s “Pair devices using Wi-Fi” dialog shows a QR code, and the phone’s “Pair device with QR code” option scans it. Same result as steps 2 to 4, fewer ports to type.

7. Android 17 and adb Wi-Fi 2.0

The adb docs say Android 17, together with adb 37.0.0, introduces what Google calls adb Wi-Fi 2.0. The headline change is that the device reconnects to your workstation automatically when it joins a trusted wireless debugging network. To check whether a phone supports it, run adb mdns track-services --proto-text and look for mdns_service_version: "2.0" in the output. On Android 11 to 16, expect Wireless debugging to switch itself off when the phone reboots or changes networks. Turn it back on, then reconnect, through mDNS if it works on your network or by hand with the new port.

Step by step: the legacy adb tcpip method

The docs describe this as the only option on Android 10 and lower. It still works on newer phones. You need the cable once.

adb devices                              # the phone should be listed over USB
adb tcpip 5555                           # restart adbd listening on TCP port 5555
adb shell ip route | awk '{print $9}'    # print the phone's IP address

The last line is the one the scrcpy docs use. If it prints more than one address, take the Wi-Fi one, or read it from Settings, About phone, Status. Then unplug and connect:

adb connect 192.168.1.42:5555
adb devices

adb connect assumes port 5555 if you leave the port off.

Things to know about this mode:

It doesn’t survive a reboot. adbd comes back on USB and you need the cable again. Rooted phones can be set to start adbd on a TCP port at boot; a normal retail phone can’t.
The connection isn’t encrypted. Wireless debugging on Android 11 and later runs over TLS, which is why its mDNS service is called _adb-tls-connect. Legacy mode is plain TCP. The phone still has to accept your computer’s key, but the traffic itself is readable by anyone who can capture it, so keep it off shared Wi-Fi.
adb disconnect 192.168.1.42:5555 drops one device, and a bare adb disconnect drops all of them.
adb usb puts adbd back on USB when you’re finished.

My opinion: on anything running Android 11 or later, stop using adb tcpip. Pairing takes the same thirty seconds, it’s encrypted, and it doesn’t need a cable after a reboot.

Common pitfalls

adb connect times out, or says no route to host

That’s the network, nearly every time. Guest SSIDs and many corporate networks enable client isolation (also called AP isolation), which stops Wi-Fi clients reaching each other even though each one has internet. Phones and laptops on different VLANs or subnets hit the same wall. So does a VPN on either end, because the laptop may route the traffic into the tunnel instead of onto the LAN.

Try ping 192.168.1.42 first. A reply rules out isolation. No reply isn’t conclusive, since some networks drop ping, but it’s a strong hint.

Connection refused

The address is reachable and nothing is listening on that port. You used the pairing port, or the port changed after a toggle or reboot, or (in legacy mode) the phone rebooted and adbd went back to USB.

The device shows as unauthorized

The phone hasn’t accepted this computer’s key yet, so check its screen for the “Allow debugging?” prompt. If you’ve been going round in circles, revoke USB debugging authorizations in Developer options and start again. The key pair lives in ~/.android/adbkey on the computer (%USERPROFILE%\.android\adbkey on Windows). Run adb as a different user or inside a container and it has a different key, so the phone treats it as a new machine.

Two adb servers fighting

adb server version (40) doesn't match this client (41); killing...

Two different adb binaries are taking turns killing each other’s server on port 5037. It’s most common on Windows, where Android Studio’s SDK, a package manager copy and a copy shipped inside some third-party tool can all live on one machine. Every time the servers swap, every device disconnects and reconnects, which looks exactly like flaky Wi-Fi. Keep one Platform-Tools install, put it first on PATH, and run adb kill-server once.

mDNS finds nothing

Run adb mdns check. If adb itself is fine and adb mdns services stays empty, the network is probably dropping multicast between Wi-Fi clients, which plenty of routers and mesh systems do. Skip discovery and connect by IP and port.

It worked yesterday

The phone got a new address from DHCP. Give test phones a DHCP reservation on the router so their IPs stay put.

Scaling this

One phone on Wi-Fi is easy. Ten is where habits have to change.

Stop typing ports. A short script that reads adb mdns services (or your DHCP reservations) and runs adb connect for each phone pays for itself in a week.
Always address a device by serial, for example adb -s 192.168.1.42:41235 shell getprop ro.product.model, or set ANDROID_SERIAL per process. With more than one device attached, a bare adb shell fails with more than one device/emulator.
Give the phones their own SSID or VLAN, without client isolation and without the rest of the office’s traffic. Congested Wi-Fi shows up as random timeouts in your tests, never as a clear network error.
For long unattended runs, go back to USB. Wi-Fi is great for the phone on your desk. A rack of phones running tests overnight has fewer ways to fail on powered USB hubs.

Where to go next

Once the phone is on the network, scrcpy can mirror and control it over the same connection, and its --tcpip option does the legacy switch for you. If you’re picking a framework to drive the phone, the uiautomator2 vs Appium comparison covers setup cost and which one suits which team. And if your tests pass on the emulator but fail on hardware, read what emulators miss compared with real devices.

The primary reference is Google’s adb documentation. Changes such as the new mDNS backend in 37.0.x show up first in the Platform-Tools release notes.

Written by Xavier Fok

disclosure: ADB Handbook is published by the team that runs cloudf.one. This article contains no sponsored links. Last reviewed by Xavier Fok on 2026-09-11.