Android 17 Wireless ADB: Wi-Fi 2.0 Setup and Fixes

“Successfully paired” should feel like the end of setup. Instead, you run adb devices and see nothing.

This usually sends people back to the pairing screen, where they generate another code, repeat the same command and get the same result. The missing distinction is that pairing establishes trust; connecting creates a usable debugging connection.

Android 17 and ADB 37.0.0 introduce ADB Wi-Fi 2.0, including automatic connections when a paired device joins a trusted wireless-debugging network. Older Android versions can still support wireless debugging, but they do not acquire every Android 17 behavior merely because the computer's ADB was updated.source 1

The setup below uses your own phone, a trusted computer and a private network. It is not a way to administer a device without its owner's authorization.

Know which wireless ADB method you are using

Three different situations are often described as “wireless ADB”:

Method	How to recognize it	What to remember
Modern Wireless debugging	Android's pairing-code or QR-code flow	Pair the workstation and use the connection information for that session
Android 17 with ADB Wi-Fi 2.0	Supported Android 17 device plus ADB 37 or later	Trusted-network behavior can automatically restore a paired connection
Legacy TCP mode	Tutorials using `adb tcpip 5555`	This is not the modern pairing/TLS workflow

Google's hardware-device guide specifically warns that the legacy adb tcpip connection used for mirroring is not encrypted.source 1 Do not open port 5555 on your router or expose ADB to the public internet.

A firewall rule that exposes everything is not an acceptable solution to a discovery problem.

Check the ADB you are actually running

Download current SDK Platform Tools from Google, not an abandoned “minimal ADB” bundle. Then run:

adb version

Read the Version information, not just the familiar Android Debug Bridge protocol-version line. Updating a folder does not prove that your shell or IDE is using it.

On Windows:

where.exe adb

On macOS or Linux:

command -v adb

If several copies exist, decide which installation your tools should use. Do not delete unrelated SDK folders indiscriminately. A direct invocation from the intended platform-tools directory is a useful comparison.

Why some popular mDNS fixes are now obsolete

Google's release notes say Platform Tools 37.0.1, released in July 2026, removed the old OpenScreen backend. Setting ADB_MDNS_OPENSCREEN has no effect in that version. The active implementation is libadbmdns.source 3

A tutorial telling every reader to toggle that variable may have been written for a different release. First check the version. Do not stack old environment-variable workarounds onto a new installation without understanding whether they still exist.

Pair the phone and computer

Use a trusted network and keep the phone unlocked during setup.

Open Developer options > Wireless debugging. Allow debugging on the network only if you control and trust it. Choose the pairing-code option and leave that dialog open.

On the computer, use the address and pairing port shown in that dialog:

adb pair PHONE_IP:PAIRING_PORT

Replace both placeholders with the actual values, then enter the displayed code when prompted. Afterwards, check:

adb devices -l

These are the modern ADB pairing and connection checks documented by Google.source 2

Do not post a live pairing code in a support forum. Pairing is an authorization decision, not just a connectivity test.

Pairing port and connection port are different

If the phone does not appear after pairing, return to the main Wireless debugging page. Use its address and connection port:

adb connect PHONE_IP:CONNECTION_PORT
adb devices -l

Do not reuse the pairing-dialog port just because it is the last number you copied. The developer of Bugjaeger also documents this distinction in its wireless connection guide.source 4

For example, a pairing dialog and the main page might show different ports at the same phone IP. Those values are session information, not permanent numbers to hard-code into every future command.

Understand what “trusted network” means

There are two decisions: whether to trust the workstation, and whether to allow wireless debugging automatically on that network.

Google's Android 17 instructions explain that selecting the network's always-allow option makes it a trusted wireless-debugging network. A paired workstation can then reconnect when the device returns to that network.source 1

This is convenient at your desk. It is not a reason to approve hotel, airport or shared public Wi-Fi indefinitely.

Also separate a trusted-network setting from the app-level local-network permission introduced for relevant Android 17 apps. ADB setup is not fixed by granting a random media app more permissions. Our Android 17 local-network guide covers TV, printer and NAS discovery separately.

Paired but not connected: work through these checks

1. Confirm the current address and connection port

Read them again from the main Wireless debugging page. Do not rely on yesterday's screenshot or a saved command. Then try a direct connection to that current endpoint.

If direct connection succeeds but automatic discovery does not, you have narrowed the problem considerably. Pairing is probably not the first thing to redo.

2. Check the running server

With current ADB, inspect:

adb server-status

Google's troubleshooting documentation uses this to examine the server version and mDNS state. For the current implementation, check that mDNS is enabled and the backend is LIBADBMDNS.source 2

A client binary and an already-running server deserve separate attention. When necessary, restart the server from the intended Platform Tools installation:

adb kill-server
adb start-server
adb server-status

This interrupts other ADB connections on that computer. Save active debugging work first.

If your environment explicitly disabled mDNS, remove that configuration or follow Google's documented ADB_MDNS setting for your shell. Do not substitute the obsolete OpenScreen variable.source 2 source 3

3. Inspect service discovery

A useful read-only discovery check is:

adb mdns services

Compare that output with a direct connection attempt. An empty discovery result does not, on its own, prove the phone's pairing credentials are broken.source 2

Record the combination of results:

Observation	A narrower next step
Pairing succeeds and direct connect works, but automatic discovery does not	Inspect mDNS, the active ADB server and local network filtering
Pairing succeeds but direct connect fails	Recheck the current connection port, network path and Wireless debugging state
It works on a private hotspot or home LAN but not an office network	Ask the administrator about client isolation and permitted discovery
One computer works and another does not	Compare Platform Tools installations, server state and host firewall rules
It works until you change networks	Review network trust and the new network's connectivity rather than assuming permanent access
The target appears twice	Select the intended transport explicitly

The table is a troubleshooting method. Each observation narrows the investigation; none is a universal diagnosis by itself.

4. Check the network without weakening it

Guest Wi-Fi, client isolation, a host firewall or a VPN can change whether peers can discover or reach each other. Google's ADB documentation identifies restrictive network environments as a source of wireless debugging problems.source 2

Try a network you own and trust. Keep the test controlled: the same phone, the same computer and the same ADB installation. A successful result there is useful evidence to bring to an administrator.

Do not turn off all firewall protection permanently. Create only the narrowly required exception supported by your operating system and network policy.

“More than one device” is a selection problem

USB, Wi-Fi and emulator connections can coexist. Do not assume an ADB target identifier always looks like the phone's printed hardware serial number.

An XDA discussion from 2022 documents exactly this confusion: the user saw changing wireless identifiers and wanted to connect using a single permanent serial. Replies and tests centered on selecting the transport actually listed by ADB.source 6

Read the current list and copy the identifier for the connection you intend to use:

adb devices -l
adb -s "EXACT_IDENTIFIER_FROM_THE_LIST" shell getprop ro.product.model

The second command is a read-only identity check. If it identifies the wrong target, stop before using installation, deletion or flashing commands.

Do not trim parts off an mDNS-based identifier because the remaining text looks more familiar.

Wireless ADB working does not mean Shizuku will always stay running

ADB pairing and the lifecycle of an app started through ADB are related but different concerns.

Shizuku documents its own startup methods, reboot behavior and device-specific restrictions.source 5 A computer automatically reconnecting through ADB Wi-Fi 2.0 is not proof that Shizuku has automatically restarted or that Android will never stop an app's service.

Check the app's own status screen. If ADB works but the dependent tool does not, investigate that tool's startup and authorization rather than rebuilding a successful ADB pairing.

The same distinction applies to a helper app that uses local wireless debugging on the phone itself. Follow that app's supported procedure; do not assume workstation instructions are identical to a loopback connection.

Disconnecting is not the same as revoking access

When you finish, turn off Wireless debugging if you do not need it. To remove a computer's trust, use Paired devices > the workstation > Forget. Google's guide also describes revoking debugging authorizations to remove previously paired workstations.source 1

adb disconnect closes a transport connection. It should not be treated as a substitute for forgetting an untrusted workstation or removing automatic network trust.

Before lending or selling a device, review authorized computers and developer settings as part of the handover. Do not leave a temporary support computer paired simply because the session has ended.

A useful wireless ADB bug report

Include the phone model and exact Android build, the output of adb version and adb server-status, whether pairing succeeds, whether direct connection succeeds, and whether the same setup works on another trusted network.

State whether USB and Wi-Fi are connected simultaneously. Include a redacted adb devices -l result when target selection is the problem.

Do not publish pairing codes, private ADB keys or full logs containing personal app data. A report that separates discovery, trust and connection saves everyone time.

Frequently asked questions

Do I need a USB cable to pair on Android 17?

Not for the supported modern Wireless debugging pairing flow. Do not confuse it with older tutorials that first enable TCP mode through USB.source 1 source 4

Why does ADB say paired when the device list is empty?

Pairing and an active connection are distinct. Check the main page's current connection port, then examine discovery and server state.

Does ADB Wi-Fi 2.0 work on every older Android phone?

The documented new combination is Android 17 with ADB 37.0.0 or later. Earlier versions can support the older wireless workflow, but that is not a promise of identical automatic behavior.source 1

Should I set ADB_MDNS_OPENSCREEN=0?

Not as a fix for Platform Tools 37.0.1. Google says that variable no longer has an effect in that release.source 3

Should I open port 5555 to fix this?

No. Public port forwarding is not part of the modern local pairing workflow. Keep debugging limited to authorized devices and networks.

Keep the diagnosis in three parts

Can the computer discover the phone? Is the computer trusted? Can it establish the current connection?

Answer those separately. You will know whether to fix a network, select the correct endpoint, update the running ADB installation or repair an actual pairing problem, instead of generating codes repeatedly and hoping one works.

Sources and scope

Research checked September 28, 2026. Commands use Google's documented ADB interface and illustrative placeholders. No claim is made that automatic reconnect was physically tested across manufacturers or networks for this article.

Source 1: Android Developers, running apps on a hardware device, Android 17 Wi-Fi 2.0, trusted networks, pairing and revocation. Open source
Source 2: Android Developers, Android Debug Bridge and wireless debugging troubleshooting. Open source
Source 3: Android Developers, SDK Platform Tools release notes, particularly 37.0.0 and 37.0.1. Open source
Source 4: Bugjaeger developer, connecting through Wi-Fi, including pairing and connection ports. Open source
Source 5: Shizuku official setup guide, startup methods and device restrictions. Open source
Source 6: XDA, August 2022 discussion of wireless ADB identifiers and changing port assignments. Historical user troubleshooting, not an Android 17 test. Open source