How to Debug Android Phone Using Wi-Fi

Debugging an Android phone over a trusted Wi-Fi network

Wireless debugging lets Android Studio and Android Debug Bridge, or ADB, communicate with an Android phone without keeping a USB cable attached. Once the phone and computer are paired, you can deploy a test build, read Logcat, run ADB commands, inspect an app, and use many normal development tools over a local Wi-Fi network.

Android 11 and later support direct wireless pairing. Android 16 places the control under Developer options. The process is convenient, but a paired computer receives powerful development access while debugging is active. Use a private network, keep pairing information secret, and remove access when the workstation is no longer trusted.

Requirements

An Android phone with Wireless debugging available in Developer options.
A computer with a current stable Android Studio or Android SDK Platform-Tools.
The phone and computer connected to the same trusted Wi-Fi network.
Permission to change firewall settings if local device discovery is blocked.
An unlocked phone during the initial pairing process.

Guest, hotel, school, office, and public networks often isolate devices or block multicast discovery. A private home or development network is normally easier and safer. Do not expose ADB using router port forwarding.

Step 1: Enable Developer Options

If Developer options is still hidden, open Settings > About phone, find Build number, and tap it seven times. Enter the phone's PIN, password, or pattern when requested.

Manufacturer menus differ, so use How to Enable Developer Options on Android 16 for Pixel, Samsung, safety, and troubleshooting details.

Step 2: Turn On Wireless Debugging

On Android 16, the standard route is:

Settings > System > Developer options > Wireless debugging

Connect the phone to a trusted Wi-Fi network.
Open Wireless debugging.
Turn on the switch.
Approve the current network only if you recognize and trust it.

If the phone offers Always allow on this network, use it only for a private network you control. The phone may automatically reconnect to a paired workstation when both return to a trusted network.

Method 1: Pair with Android Studio

This is the easiest method for developers who already use Android Studio.

Open Android Studio.
Open the target-device menu and choose Pair Devices Using Wi-Fi. You can also use Device Manager where the pairing action is available.
On the phone, keep the Wireless debugging page open.
Choose QR-code or pairing-code mode in Android Studio.
For QR pairing, tap Pair device with QR code on the phone and scan the code shown by Android Studio.
For numeric pairing, tap Pair device with pairing code and enter the displayed six-digit code in Android Studio.
Wait for the phone to appear in Android Studio's device list.

Select the phone as the run target and launch a debuggable project. A successful installation and app launch without a cable confirm that the connection works.

Method 2: Pair with ADB from the Command Line

Use this method when Android Studio discovery fails, you work from another editor, or you need direct control over ADB.

Check that ADB is available

adb version

If the command is not found, install or update Android SDK Platform-Tools and run ADB from its installed directory, or add that directory to the development shell's path.

Open the pairing screen

On the phone, open:

Wireless debugging > Pair device with pairing code

The phone displays an IP address, a temporary pairing port, and a six-digit code. Keep this screen open while pairing.

Run adb pair

adb pair PHONE_IP:PAIRING_PORT

Replace the placeholders with the values shown on the phone, then enter the six-digit code when prompted. A successful result confirms that the computer has been paired.

Do not publish the real command from your device in screenshots or support posts. It can reveal local network and pairing details.

Pairing and Connecting Are Different

Pairing establishes trust between the phone and computer. Connecting creates the active ADB session. Android normally uses one temporary port for pairing and a different port for the active connection.

After pairing, ADB usually discovers and connects to the device automatically through multicast DNS, or mDNS. Check with:

adb devices -l

If the phone is paired but absent from the list, return to the main Wireless debugging page and use the separate IP address and port shown there:

adb connect PHONE_IP:CONNECTION_PORT

Do not reuse the pairing port for adb connect. Always use the values currently displayed because ports can change when Wireless debugging restarts, the network changes, or the phone reconnects.

Verify the Connection

Check ADB

adb devices -l

The device should appear with the state device. Other states require attention:

offline: ADB sees the endpoint but cannot complete a working session.
unauthorized: trust or authorization is incomplete.
no entry: discovery, connection, network, firewall, or pairing failed.

Check Android Studio

Select the phone in the target-device menu and run a debuggable application. Use Logcat or attach the debugger to confirm more than simple device discovery.

Check Flutter

flutter devices

Flutter uses the Android connection exposed by ADB, so a working wireless device should normally appear here. If Flutter setup is incomplete, run:

flutter doctor

For the complete setup, see How to Connect an Android Phone to Flutter and the Flutter Android App Development Guide.

Useful Wireless Debugging Tasks

Read device logs

adb logcat

Logs can contain application data, URLs, device details, and other sensitive information. Capture only the period needed for diagnosis and review the file before sharing it.

Install a debuggable APK

adb install path-to-debug.apk

Install only APK files you built or obtained from a source you trust. ADB installation is for development and controlled testing, not a way to bypass security review.

Open a device shell

adb shell

The shell can inspect state and run supported diagnostic commands. Copy commands only when you understand their target and effect; some can delete app data, change settings, stop processes, or create misleading test conditions.

Target one device explicitly

If an emulator and physical phone are connected at the same time, first copy the correct identifier from adb devices, then use:

adb -s DEVICE_SERIAL COMMAND

This prevents a command from accidentally targeting the wrong phone or emulator.

Fix: The Phone Does Not Appear

Confirm both devices are connected to the same Wi-Fi network.
Keep the Wireless debugging screen open during pairing.
Update Android Studio and SDK Platform-Tools.
Turn Wireless debugging off and on to refresh its ports.
Forget the workstation on the phone and pair again.
Use adb connect with the connection port, not the pairing port.
Try a private network without client isolation.
Temporarily test whether a VPN or security product is blocking local discovery, following your organization's security rules.

Fix: Pairing Succeeds but ADB Does Not Connect

This usually means trust was established but automatic mDNS discovery did not create the active session.

Open the main Wireless debugging screen.
Note the current connection address and port outside the pairing dialog.
Run adb connect PHONE_IP:CONNECTION_PORT.
Check again with adb devices -l.

If it still fails, restart the local ADB server:

adb kill-server
adb start-server
adb connect PHONE_IP:CONNECTION_PORT
adb devices -l

Restarting ADB interrupts other active ADB sessions on that computer, so check whether another development task is using it first.

Fix: The Connection Keeps Dropping

Keep the phone and computer on the same stable Wi-Fi network.
Disable aggressive battery or Wi-Fi power saving temporarily for diagnosis.
Check whether the phone switches automatically between Wi-Fi and mobile data.
Avoid guest networks that rotate addresses or isolate clients.
Reopen Wireless debugging and use its current connection port.
Use USB debugging when installing large builds or when Wi-Fi latency makes debugging unreliable.

Wireless debugging is a convenience, not a requirement. A stable USB data connection may be better for long profiling sessions or unreliable networks. If Windows reports a hardware connection error, see How to Fix USB Code 43 on Android.

Firewall and Network Troubleshooting

Wireless discovery and connections can be blocked by the computer firewall, router settings, virtual private network, corporate security controls, or wireless client isolation. Do not solve this by disabling every security control permanently.

Use a controlled test:

Confirm the network profile is correct for the trusted environment.
Allow the installed Android Studio and ADB components only where appropriate.
Avoid broad inbound rules, router port forwarding, and exposure to the internet.
Restore any temporary diagnostic change after identifying the cause.

On managed computers or networks, ask the administrator rather than bypassing policy. A restricted network may deliberately prevent device-to-device development connections.

Wireless Debugging Security

Pair only computers you control or explicitly trust.
Use a private network rather than public Wi-Fi.
Never share an active QR code or six-digit pairing code.
Do not forward ADB ports through a router or expose them to the internet.
Review the paired-device list periodically.
Turn Wireless debugging off when it is not needed.
Review logs and screenshots before sharing them.
Use the correct device identifier when several targets are connected.

Android Studio device mirroring can display and control phone content on the workstation. Be careful when notifications, messages, authentication codes, customer data, or private apps may appear on screen.

Disconnect and Remove Pairing

Disconnect the current ADB session

adb disconnect PHONE_IP:CONNECTION_PORT

Forget one workstation on the phone

Open Settings > System > Developer options > Wireless debugging.
Find the workstation under Paired devices.
Tap its name and choose Forget.

Remove all ADB authorizations

Use Revoke USB debugging authorizations in Developer options when you want every previously trusted ADB workstation to request approval again. Finally, turn off Wireless debugging if it is no longer required.

Frequently Asked Questions

Do I need a USB cable first?

No for Android 11 and later when direct Wireless debugging pairing is available. Older workflows and some troubleshooting situations may still require an initial USB connection.

Why are two different ports shown?

One port is used temporarily by adb pair; another is used by the active ADB connection. Use the connection port from the main Wireless debugging page with adb connect.

Can Flutter use wireless debugging?

Yes. Once the phone is connected through ADB, flutter devices should normally detect it as an Android target.

Can I debug over mobile data?

The supported local pairing workflow is designed for the development computer and phone to share a suitable network. Do not expose ADB across the public internet. Use an approved secure remote-development design if local access is impossible.

Why does the connection address change?

Network addresses and debugging ports can change when the phone reconnects, Wireless debugging restarts, or the network assigns a new address. Read the current values from the phone instead of reusing an old command.

Final Checklist

Use an Android version that supports direct Wireless debugging.
Update Android Studio and SDK Platform-Tools.
Connect both devices to the same trusted network.
Pair with Android Studio or adb pair.
Use the separate connection port if manual adb connect is needed.
Verify the target with adb devices -l.
Verify with flutter devices when using Flutter.
Keep pairing details and logs private.
Forget old workstations and turn debugging off when finished.

Wireless debugging is reliable when the network allows local device discovery and the pairing and connection stages are treated separately. Once verified, it provides a convenient cable-free workflow without changing how Android Studio or Flutter builds the application.

Official References

Menus, ports, discovery behavior, and development tools can change with Android and Platform-Tools updates. This guide was reviewed against official documentation available on 23 August 2026.