Remote Android Debugging over the Internet
ADB, or Android Debug Bridge, can communicate with an Android device over TCP after network mode is enabled. When the device and development computer are on different networks, a Localtonet TCP tunnel can publish the device's ADB listener through a public host and port without inbound router port forwarding, a static public IP address, or VPN setup. This guide explains the legacy adb tcpip workflow, Android Studio integration, security controls, and common troubleshooting steps. Because ADB grants powerful debugging access, use this workflow only on devices you own or are explicitly authorized to administer.
What Is ADB and Why Use It Remotely?
ADB is a command-line tool included in Android SDK Platform Tools. It lets an authorized computer communicate with an Android device to install and uninstall apps, transfer files, read system logs available to the shell user, run shell commands, and attach supported debugging tools to applications. The exact operations available depend on the Android version, device build, application configuration, user permissions, and device-management policy.
ADB normally communicates over USB. It can also use a network transport when TCP mode or Android's newer Wireless Debugging feature is enabled. Remote access can be useful in several controlled development and support scenarios:
A Localtonet TCP tunnel uses an outbound connection from the Android device to a Localtonet relay and provides a public host and port that forwards to the selected local target. This avoids inbound router port forwarding. It does not guarantee passage through every corporate firewall because a network administrator may block the outbound connection or the public destination port.
How ADB over a Localtonet Tunnel Works
The legacy adb tcpip 5555 command restarts the device's ADB daemon with a TCP listener on port 5555. The Localtonet Android client can then forward a Localtonet TCP endpoint to 127.0.0.1:5555 on the same device. From an authorized development computer, you connect with adb connect <PUBLIC_HOST>:<PUBLIC_PORT>. Use the actual host and port displayed by the current Localtonet dashboard rather than copying an example server name or port.
Enable Developer Options and USB debugging
Enable Developer Options using the instructions for your device manufacturer, then enable USB debugging.
Switch ADB to TCP mode through an authorized USB connection
Connect the device by USB, approve the host key on the device, and run adb tcpip 5555.
Create and start a Localtonet TCP tunnel
Select the device-specific AuthToken, choose an available relay in the current dashboard, set the local target to 127.0.0.1:5555, create the tunnel, and start it.
Connect from an authorized development computer
Run adb connect <PUBLIC_HOST>:<PUBLIC_PORT> and approve any debugging authorization prompt shown on the Android device.
Localtonet documents an encrypted outbound tunnel between the connected client and its relay infrastructure. A standard TCP endpoint does not by itself establish TLS between the remote ADB client and the public endpoint. Legacy ADB-over-TCP authentication should not be described as complete transport encryption. Restrict who can reach the endpoint, use only trusted networks and devices, stop the tunnel after use, and prefer an additional authenticated private-network layer when the risk profile requires end-to-end network protection.
Many production devices return to their normal debugging configuration after a reboot, so plan to verify TCP mode again after restarting. Exact behavior can vary by Android release, manufacturer build, device policy, and whether the device is rooted. Do not rely on undocumented persistent system properties or startup scripts for production support.
Prerequisites
What You Need
adb tcpip.
adb tcpip 5555. It may be needed again after a reboot or configuration change.
Step 1: Enable Developer Options and USB Debugging
Open the device build information
Open Settings and locate the Build number. Its location differs by manufacturer and Android version.
Tap Build number seven times
Tap the Build number repeatedly until the device confirms developer mode. Enter the device PIN or password if requested.
Open Developer Options
Return to Settings and open Developer Options. It is commonly under System, but the location is manufacturer-specific.
Enable USB debugging
Turn on USB debugging and accept the device warning only if you understand the access being granted.
On many Samsung devices, Build number is under Settings → About phone → Software information. Menu labels can change between One UI and Android releases.
Step 2: Enable Legacy ADB TCP Mode via USB
Connect the Android device by USB
Use a data-capable cable. Unlock the device and approve the debugging key fingerprint only if it belongs to your trusted computer.
Verify that ADB detects the device
adb devicesThe device should be listed with the state device. If it is unauthorized, inspect and approve the prompt on the Android device.
Restart the ADB daemon in TCP mode
adb tcpip 5555A successful command normally reports that ADB is restarting in TCP mode on port 5555.
Disconnect USB and verify the remote path promptly
After TCP mode starts, the cable is not required for that session. Keep someone available at the device to approve a new host key if Android requests authorization.
The command accepts another available port, but the same local port must be entered in the tunnel configuration. Android 11 Wireless Debugging uses a separate pairing and TLS-based connection workflow with dynamically selected ports, so its instructions should not be mixed with this legacy adb tcpip procedure.
Step 3: Set Up the Localtonet Android App
Localtonet Android App Setup
Install the Localtonet app
Install the current Localtonet Android app from Google Play.
Associate the app with its device token
Use the device-specific AuthToken shown in the current Localtonet dashboard. Do not publish, log, or share the token.
Keep the client connected
The tunnel is available only while the selected Android client is connected and the tunnel is running. Android background restrictions, battery optimization, or loss of connectivity can interrupt the session.
Step 4: Create and Start the Localtonet TCP Tunnel
Open the TCP tunnel interface
Sign in and open the current TCP or TCP/UDP tunnel page. Dashboard names and field labels can change between product versions.
Enter the local target
Choose TCP, select the AuthToken belonging to the Android device, select an available relay, set the local IP to 127.0.0.1, and set the local port to 5555. If you used another port with adb tcpip, enter that port instead.
Create and start the tunnel
Creating a tunnel does not mean it is running. Use the current Start control while the selected Android client is connected.
Record the assigned public endpoint
Copy the exact public host and port displayed by the dashboard. Do not assume a particular server code, region, or public port because availability varies.
If IP allowlisting is available on your current Localtonet plan, permit only the fixed public IP addresses of trusted development systems or CI runners. Localtonet's current public pricing page lists IP whitelisting under paid tunnel features, so do not assume it is included with every plan.
Step 5: Connect ADB from the Development Machine
Open a terminal
Use Command Prompt, PowerShell, Terminal, or another shell in which the current adb executable is available.
Connect to the assigned endpoint
adb connect <PUBLIC_HOST>:<PUBLIC_PORT>Replace both placeholders with the values displayed for the running tunnel.
Verify and authorize the connection
adb devices -lIf Android displays a key fingerprint prompt, compare and approve it on the device. Do not approve an unexpected host. The endpoint should eventually appear with the state device.
Use standard ADB commands
# Install a debuggable or otherwise permitted APK:
adb -s <PUBLIC_HOST>:<PUBLIC_PORT> install myapp.apk
# View logs available to the ADB shell:
adb -s <PUBLIC_HOST>:<PUBLIC_PORT> logcat
# Open an ADB shell:
adb -s <PUBLIC_HOST>:<PUBLIC_PORT> shell
# Capture and retrieve a screenshot:
adb -s <PUBLIC_HOST>:<PUBLIC_PORT> shell screencap -p /sdcard/screen.png
adb -s <PUBLIC_HOST>:<PUBLIC_PORT> pull /sdcard/screen.png
# Push a file to shared storage:
adb -s <PUBLIC_HOST>:<PUBLIC_PORT> push myfile.txt /sdcard/If exactly one device is connected, the -s selector may be omitted. Application signing rules, Android permissions, storage restrictions, enterprise policy, and production-build restrictions still apply.
Using Android Studio with the Tunnel
Android Studio uses ADB to discover connected devices. After the command-line ADB server has an authorized connection to the public tunnel endpoint, the device can appear in Android Studio's target-device menu. Make sure the terminal and Android Studio use compatible, current Platform Tools. If multiple ADB installations are running, they can conflict.
Open the Android Studio project
Confirm that the project is configured for the connected device's Android version and architecture.
Connect with the same SDK Platform Tools
Run adb connect <PUBLIC_HOST>:<PUBLIC_PORT> using the ADB installation managed by Android Studio when possible.
Select the authorized device
Open the target-device menu and select the remote device after it appears. Model labels vary by device and Android version.
Run or debug within normal Android restrictions
Android Studio can install and launch the app through ADB. Attaching a debugger requires a debuggable application or another build and policy configuration that permits debugging.
Use current Android Studio and SDK Platform Tools, reduce unnecessary deployment size, and expect internet latency to affect installs, log streaming, and debugger responsiveness. If the device does not appear, check adb devices -l, restart the ADB server if necessary, and reopen the target-device menu.
Common ADB Commands for Remote Debugging
| Task | ADB Command |
|---|---|
| Connect to the tunnel | adb connect <PUBLIC_HOST>:<PUBLIC_PORT> |
| List connected devices | adb devices -l |
| Install an APK | adb -s <SERIAL> install myapp.apk |
| Reinstall while retaining application data when permitted | adb -s <SERIAL> install -r myapp.apk |
| Uninstall an application | adb -s <SERIAL> uninstall com.example.myapp |
| View logs | adb -s <SERIAL> logcat |
| Clear the logcat buffers when permitted | adb -s <SERIAL> logcat -c |
| Open a shell | adb -s <SERIAL> shell |
| Push a file | adb -s <SERIAL> push local.txt /sdcard/ |
| Pull a file | adb -s <SERIAL> pull /sdcard/file.txt ./ |
| Take a screenshot | adb -s <SERIAL> exec-out screencap -p > screen.png |
| Record the screen | adb -s <SERIAL> shell screenrecord /sdcard/video.mp4 |
| Reboot the device when permitted | adb -s <SERIAL> reboot |
| Disconnect | adb disconnect <PUBLIC_HOST>:<PUBLIC_PORT> |
Security: Protecting an ADB Tunnel
ADB provides a privileged debugging shell and can install applications, modify many device settings, capture logs, transfer accessible files, and reboot a device. On normal production Android builds, the ADB shell is not automatically root and cannot freely read every application's private sandbox. Even without root, its capabilities are sensitive enough that a public endpoint must be tightly restricted.
🔒 Verify ADB host-key authorization
Android devices that enforce secure ADB normally require the user to approve a debugging host key. Check the displayed fingerprint and reject unexpected prompts. Do not assume this approval dialog replaces network access controls.
🌐 Use IP allowlisting when available
Allow only trusted source IP addresses or ranges. This reduces unsolicited connection attempts before they reach the ADB listener. Availability can vary by plan, so verify the current Localtonet dashboard and pricing information.
⏱ Stop the tunnel after the session
Disconnect ADB, stop the Localtonet tunnel, and confirm that it is no longer running. A saved tunnel configuration is not active unless its selected client is connected and the tunnel has been started.
🚫 Disable debugging when it is not needed
Turn off USB debugging or revoke debugging authorizations after the work is complete, particularly before returning a device to normal use.
📱 Use dedicated test devices
Do not expose ADB on personal devices or devices containing production credentials, customer data, financial applications, authentication secrets, or regulated information. For fleets and unattended production equipment, use supported enterprise device-management and remote-support controls instead of leaving ADB publicly reachable.
🧭 Follow organizational policy
Only connect to devices and networks you own or are authorized to administer. Corporate egress controls, mobile-device policies, and application-security requirements still apply.
Platform-Specific Notes
Windows
Android Studio includes SDK Platform Tools. For command-line use without Android Studio, download the current package from Android Developers. The initial USB connection may require the Google USB Driver for supported Google devices or an OEM-provided driver for another manufacturer.
adb version
adb devices -l
adb tcpip 5555
adb connect <PUBLIC_HOST>:<PUBLIC_PORT>macOS
Android Studio can manage SDK Platform Tools through its SDK Manager. A third-party package manager may also package ADB, but ensure the installed version remains current and avoid running multiple ADB servers from conflicting installations.
adb version
adb devices -l
adb tcpip 5555
adb connect <PUBLIC_HOST>:<PUBLIC_PORT>Linux
Use Android Studio's SDK Manager, the official Platform Tools archive, or a maintained distribution package. Linux USB access may require correctly configured udev rules and group membership. Prefer documented udev configuration over running the ADB server as root.
# Package names vary by distribution
adb version
adb devices -l
adb tcpip 5555
adb connect <PUBLIC_HOST>:<PUBLIC_PORT>Troubleshooting
| Problem | Likely cause | Fix |
|---|---|---|
adb devices shows nothing over USB | USB debugging, cable, USB mode, permissions, or driver problem | Unlock the device, verify USB debugging, use a data cable, and install the correct Windows driver or Linux udev rules. |
Device is unauthorized | The host key has not been approved | Inspect the device prompt and approve only the expected fingerprint. Revoke debugging authorizations and reconnect if the trusted prompt is stuck. |
adb connect reports connection refused | ADB is not listening, the tunnel is stopped, or the local target is wrong | Verify adb tcpip 5555, confirm 127.0.0.1:5555 is configured, and start the tunnel while the Android client is connected. |
| Connection times out | Endpoint blocked, client offline, allowlist mismatch, or unstable network | Check the Android client's connection, source-IP rules, current public host and port, and local network egress policy. |
Device appears offline | Stale ADB transport or interrupted tunnel | Run adb disconnect, then reconnect. If necessary, run adb kill-server and verify TCP mode again. |
| Android Studio does not show the device | Different ADB installations or an unauthorized transport | Check adb devices -l using Android Studio's Platform Tools, close conflicting ADB servers, and reopen the device selector. |
| TCP mode no longer works after restart | The device returned to its normal ADB configuration | Reconnect through USB, authorize the computer, and run adb tcpip 5555 again. |
| The tunnel stops in the background | Android battery or background-process restrictions | Keep the Localtonet client active as permitted by the device and organization. Check manufacturer-specific battery settings without disabling broader security controls unnecessarily. |
Frequently Asked Questions
Can I use ADB over the internet without router port forwarding?
Yes. A running Localtonet TCP tunnel uses an outbound client connection and provides a public host and port, so inbound router port forwarding and a static public IP are not required. The Android client must remain connected, the tunnel must be running, and local or corporate egress rules can still block the connection.
What port does legacy ADB over TCP use?
adb tcpip 5555 configures port 5555, which is conventionally used for this legacy workflow. The Localtonet public port is separate and is shown by the dashboard. Android 11 Wireless Debugging uses a different pairing and connection process.
Does ADB TCP mode always reset after reboot?
Many production devices return to their normal debugging configuration after reboot, but exact behavior is implementation-dependent. Verify the listener after every restart and be prepared to authorize USB again and rerun adb tcpip 5555.
Is the ADB connection end-to-end encrypted by a standard TCP tunnel?
Do not assume so. Localtonet documents an encrypted outbound tunnel from its client to the relay, but a raw public TCP endpoint is not automatically a TLS session between the remote ADB client and the endpoint. Legacy ADB host-key authorization is important, but it should not be represented as complete transport encryption. Use allowlisting when available, trusted networks, short-lived sessions, and an additional private authenticated network layer when end-to-end protection is required.
Does ADB provide root access or access to every application's data?
No, not on a normal production build. The ADB shell runs under a privileged shell identity but is not automatically root, and Android application sandboxes restrict access to private app data. Rooted, engineering, userdebug, vulnerable, or specially managed devices can behave differently. ADB remains a powerful administrative interface and must still be protected carefully.
Can I install an APK through the tunnel?
Yes, when the device and its policy permit installation. Package signatures, downgrade protection, storage availability, user restrictions, Play Protect, and enterprise-management controls still apply. Transfer time depends on latency and available bandwidth at both ends.
Does this use Android 11 Wireless Debugging?
No. This article uses the older adb tcpip workflow with a known local TCP port. Android 11 Wireless Debugging uses pairing, TLS, and separate service ports. Although ADB can support manual pairing and connection by address, forwarding that workflow requires handling the correct pairing and connection ports and is not covered by this single-port guide.
Quick Reference: Full Setup Checklist
| # | Step | Where | Command or action |
|---|---|---|---|
| 1 | Enable Developer Options | Android device | Use the manufacturer-specific Build number procedure |
| 2 | Enable USB debugging | Android device | Developer Options → USB debugging |
| 3 | Authorize the USB host | Device and computer | Verify the fingerprint, then run adb devices -l |
| 4 | Enable legacy TCP mode | Computer terminal | adb tcpip 5555 |
| 5 | Install and authenticate Localtonet | Android device | Use the device-specific AuthToken and keep it secret |
| 6 | Create the TCP tunnel | Localtonet dashboard | Target 127.0.0.1:5555 |
| 7 | Restrict access | Tunnel settings | Enable IP allowlisting when available for the plan |
| 8 | Start the tunnel | Current Localtonet controls | Confirm the Android client and tunnel are connected |
| 9 | Connect ADB | Authorized computer | adb connect <PUBLIC_HOST>:<PUBLIC_PORT> |
| 10 | Close the session safely | Both ends | Disconnect ADB, stop the tunnel, and disable debugging when finished |
Connect to an Authorized Android Test Device
Create a temporary TCP tunnel without inbound router port forwarding, then protect the ADB endpoint with host-key verification, available access controls, and a short tunnel lifetime.
Get Started Free →
