From Newsgroup: comp.mobile.android

PSA:
Persistent ADB over Wi-Fi without repeated pairing of desktop to Android

I've streamlined adb connections over Wi-Fi between the desktop & Android
by eliminating the USB cable & by reducing the need for new cryptic ports.

a. Pair the unrooted phone once using the Wireless Debugging pairing code
adb pair 192.168.1.2:12345 543210
Note the unrooted phone is set to a static IP address for convenience.
b. Connect to the temporary Wireless Debugging port (no USB cable needed)
adb connect 192.168.1.2:46003
c. Switch adbd into classic TCP/IP mode on port 5555
adb -s 192.168.1.2:46003 tcpip 5555
This creates a persistent Wi-Fi ADB port that survives desktop reboots.
d. And then by running this script:
adbconnect.vbs

After a disconnection or desktop reboot, only one step is needed:
adbconnect.vbs

After a phone reboot, Wireless Debugging is reset on the phone, so repeat:
i. Turn on wireless debugging (which is turned off by Android reboots)
ii. Pair and connect using the new ports & pins provided
adb pair 192.168.1.2:12345 543210
adb connect 192.168.1.2:46003
iii. Restart adbd in TCP/IP mode on port 5555 (for persistent Wi-Fi ADB)
adb -s 192.168.1.2:46003 tcpip 5555
Note: The phone listens on 5555 forever, until its next reboot
iv. Then run the script (which does not take over the console)
adbconnect.vbs
The script takes advantage that once adbd is switched to TCP/IP
mode, the phone listens on port 5555 until reboot. The script
simply reconnects using ADB's mDNS discovery & launches scrcpy.

' adbconnect.vbs
' Auto-reconnects ADB over Wi-Fi using mDNS and launches scrcpy
Dim objShell, objExec, strOutput, strCommand
Set objShell = CreateObject("Wscript.Shell")

' 1. Disconnect any dead sessions
objShell.Run "cmd /c adb disconnect", 0, True

' 2. Use ADB's built-in MDNS discovery to find the phone's wireless service automatically
' This searches the Wi-Fi space for your phone's unique ADB signature, bypassing the need for a static port
objShell.Run "cmd /c adb mdns check", 0, True

' 3. Give it 2 seconds to find the device over Wi-Fi
WScript.Sleep 2000

' 4. Launch scrcpy using the auto-discovery flag
' Change the IP address to your phone's static IP address on your LAN
strCommand = "cmd /c scrcpy.exe --tcpip=192.168.1.2 --keyboard=sdk --always-on-top"
objShell.Run strCommand, 0, False

For Linux, which I haven't tested but someone else can test for the team,
we can replace the VBS script with a bash script, e.g., bash adbconnect.sh

#!/bin/bash
# adbconnect.sh
# Auto-reconnects ADB over Wi-Fi using mDNS and launches scrcpy
adb disconnect
adb mdns check
sleep 2
# Change the IP address to your phone's static IP address on your LAN
scrcpy --tcpip=192.168.1.2 --keyboard=sdk --always-on-top

As always, please add value so all benefit from every action, and,
as always, please correct where I err so all benefit from every post.
--
On Usenet, people can work out a solution which everyone can then use.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

I've streamlined adb connections over Wi-Fi between the desktop & Android
by eliminating the USB cable & by reducing the need for new cryptic ports.

If it takes two steps, we reduce it to one, so here's a reduction in steps.

I converted the vbs script into a batch script which...
a. Detects whether the phone is already connected to adb
b. If not, prompts for the pairing code & pairing port
c. But it avoids re-pairing unless absolutely necessary
d. Then using a static LAN IP address, it resets the device to TCP/IP 5555
e. Then launches scrcpy in a detached process (allowing the console to be re-used)

If people want, we can convert this to a Linux bash script also.

:: adbconnect.bat Wi-Fi adb/scrcpy static IP and static 5555 port connect
:: v1p0 20260611 converted adbconnect.vbs to adbconnect.bat
:: Connects desktop & phone over adb & mirrors phone on the monitor
:: Should work even if either the PC and/or the phone is rebooted
:: The script will ask only for the minimum amount of data needed
:: Change the phone static IP address to the local LAN IP address
@echo off
setlocal enabledelayedexpansion

set PHONE_IP=192.168.1.2
set SCRCPY_OPTS=--keyboard=sdk --always-on-top

echo.
echo === ADB Wireless Auto-Connect ===
echo Phone IP: %PHONE_IP%
echo.

REM 1. Find adb
for /f "delims=" %%A in ('where adb 2^>nul') do (
if not defined ADB set ADB=%%A
)

if not defined ADB (
echo [ERROR] adb.exe not found.
exit /b
)

REM Ensure .exe extension
if /i not "%ADB:~-4%"==".exe" set ADB=%ADB%.exe

echo Using ADB: %ADB%
echo.

REM 2. Check if already connected
echo Checking existing ADB devices...
for /f "skip=1 tokens=1" %%D in ('"%ADB%" devices') do (
echo %%D | findstr /i "%PHONE_IP%" >nul && (
echo Already connected on %%D
set DEVICE_ID=%%D
goto RUN_TCPIP
)
)

echo Not connected. Need to pair.
echo.

REM 3. Ask user for pairing info
set /p PAIR_PORT=Enter pairing port (shown on phone):
set /p PAIR_CODE=Enter pairing code:
set /p DEBUG_PORT=Enter debug port (usually 54321):

echo.
echo Pairing with: %PHONE_IP%:%PAIR_PORT%
"%ADB%" pair %PHONE_IP%:%PAIR_PORT% %PAIR_CODE%
echo.

echo Connecting to debug port: %PHONE_IP%:%DEBUG_PORT%
"%ADB%" connect %PHONE_IP%:%DEBUG_PORT%
echo.

echo Switching to TCP/IP 5555...
"%ADB%" -s %PHONE_IP%:%DEBUG_PORT% tcpip 5555
echo.

echo Connecting final port: %PHONE_IP%:5555
"%ADB%" connect %PHONE_IP%:5555
echo.

set DEVICE_ID=%PHONE_IP%:5555
goto RUN_SCRCPY


:RUN_TCPIP
echo Switching device !DEVICE_ID! to TCP/IP 5555...
"%ADB%" -s !DEVICE_ID! tcpip 5555
"%ADB%" connect %PHONE_IP%:5555
goto RUN_SCRCPY

:RUN_SCRCPY
:: Launch scrcpy in a detached process so the console can be killed
REM scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%
echo Launching scrcpy...
start "" /B scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS% >nul 2>&1
echo(
exit /b

REM end of adbconnect.bat
--
Knowledge is best shared, like a fresh pizza & beer, among your friends.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

I've streamlined adb connections over Wi-Fi between the desktop & Android
by eliminating the USB cable & by reducing the need for new cryptic ports.

If it takes two steps, we reduce it to one, so here's a reduction in steps.

I made the script more robust where the goal is to simplify connection when mirroring the phone over Wi-Fi (no USB) when you're at home.

Most of the effort is tricks to get around modern Android security fences.

:: adbconnect.bat
:: No-USB, Wi-Fi only, adb/scrcpy static IP and static 5555 port connect
:: v1p0 20260611 converted adbconnect.vbs to adbconnect.bat
:: Connects desktop & phone over adb & mirrors phone on the monitor
:: No USB cord is used in this process as it's all done over Wi-Fi
:: Should work even if either the PC and/or the phone is rebooted
:: The script will ask only for the minimum amount of data needed
:: Change the phone static IP address as needed to fit your LAN IP address
:: v1p1 20260611 reliability improvements added to v1p0
:: Added better device lookup (skip header,ignore blanks,avoid false matches)
:: Added retry logic for adb pair & adb connect (for when phone not ready)
:: Improved polish (consistent quoting, stable scrcpy launch)
:: v1p2 20260611 further reliability improvements added to v1p1
:: Use separate retry counters for pair/connect to avoid loop
:: interference (ATTEMPTS_PAIR, ATTEMPTS_CONN)
:: Added fail-fast with clear error codes and user hints after retry
:: exhaustion
:: Added a detection of the device id after initial connect
:: (handles ephemeral adb ports like 192.168.1.4:54321)
:: Use DEVICE_ID for subsequent -s tcpip command (quoted)
:: to avoid parsing issues with colons
:: Fallback device-id lookup when initial pattern match fails
:: (robust parsing of "adb devices")
:: Consistent quoting of %ADB% and device identifiers to avoid
:: CMD parsing errors
:: v1p3 20260612 moved the pipe outside the FOR command for reliability
:: v1p4 20260612 divorced the console from the mirrored Android image
:: so that either can be killed by the user and the other will remain
@echo off
setlocal enabledelayedexpansion

set PHONE_IP=192.168.1.4
set SCRCPY_OPTS=--keyboard=sdk --always-on-top

echo.
echo === ADB Wireless Auto-Connect ===
echo Phone IP: %PHONE_IP%
echo.

REM 1. Find adb
for /f "delims=" %%A in ('where adb 2^>nul') do (
if not defined ADB set ADB=%%A
)

if not defined ADB (
echo [ERROR] adb.exe not found.
exit /b
)

REM Ensure .exe extension
if /i not "%ADB:~-4%"==".exe" set ADB=%ADB%.exe

echo Using ADB: "%ADB%"
echo.

REM 2. Check if already connected
echo Checking existing ADB devices...

REM v1p1 fixed device lookup:
REM a. skip header line
REM b. ignore blank lines
REM c. only process lines containing digits
REM d. avoid CMD parser bugs by NOT piping inside the FOR command
REM v1p3 moved pipe OUTSIDE the for loop
:: for /f "skip=1 tokens=1" %%D in ('"%ADB%" devices') do (

set DEVICE_ID=
for /f "skip=1 tokens=1" %%I in ('"%ADB%" devices') do (
echo %%I | findstr /R "[0-9]" >nul && (
echo %%I | findstr /I "%PHONE_IP%" >nul && (
if not defined DEVICE_ID set DEVICE_ID=%%I
)
)
)

if defined DEVICE_ID (
echo Already connected on %DEVICE_ID%
goto RUN_TCPIP
)

echo %%D | findstr /R "[0-9]" >nul && (
echo %%D | findstr /i "%PHONE_IP%" >nul && (
echo Already connected on %%D
set DEVICE_ID=%%D
goto RUN_TCPIP
)
)
)

echo Not connected. Need to pair.
echo.

REM 3. Ask user for pairing info
set /p PAIR_PORT=Enter Wireless debugging pairing port (shown on phone):
set /p PAIR_CODE=Enter Wireless debugging pairing code (shown on phone):
set /p DEBUG_PORT=Enter Wireless debugging debug port (shown on phone):

echo.
echo Pairing with: %PHONE_IP%:%PAIR_PORT%

REM Retry logic for adb pair (3 attempts)
set ATTEMPTS_PAIR=0
:PAIR_RETRY
set /a ATTEMPTS_PAIR+=1
"%ADB%" pair %PHONE_IP%:%PAIR_PORT% %PAIR_CODE%
if errorlevel 1 (
if !ATTEMPTS_PAIR! lss 3 (
echo Pair failed, retrying...
timeout /t 2 >nul
goto PAIR_RETRY
) else (
echo [ERROR] adb pair failed after %ATTEMPTS_PAIR% attempts.
echo Hint: Open Wireless debugging -> "Pair device with pairing code" on the phone, then re-run this script.
exit /b 1
)
)
echo.

echo Connecting to debug port: %PHONE_IP%:%DEBUG_PORT%

REM Retry logic for adb connect (3 attempts)
set ATTEMPTS_CONN=0
:CONNECT_RETRY
set /a ATTEMPTS_CONN+=1
"%ADB%" connect %PHONE_IP%:%DEBUG_PORT%
if errorlevel 1 (
if !ATTEMPTS_CONN! lss 3 (
echo Connect failed, retrying...
timeout /t 2 >nul
goto CONNECT_RETRY
) else (
echo [ERROR] adb connect %PHONE_IP%:%DEBUG_PORT% failed after %ATTEMPTS_CONN% attempts.
echo Hint: Ensure phone is on the same Wi-Fi and Wireless debugging pairing UI is active.
exit /b 2
)
)
echo.

REM After connect, get the actual device id reported by adb (handles ephemeral ports)
set DEVICE_ID=
for /f "tokens=1" %%I in ('"%ADB%" devices ^| findstr /R /C:"%PHONE_IP%[: ]"') do (
if not defined DEVICE_ID set DEVICE_ID=%%I
)

if not defined DEVICE_ID (
REM fallback: try to find any non-empty device id line
for /f "skip=1 tokens=1" %%I in ('"%ADB%" devices') do (
echo %%I | findstr /R "[0-9]" >nul && if not defined DEVICE_ID set DEVICE_ID=%%I
)
)

if defined DEVICE_ID (
echo Found device id: "%DEVICE_ID%"
) else (
echo [WARN] No device id found after connect. Continuing using %PHONE_IP%:%DEBUG_PORT% for tcpip attempt.
set DEVICE_ID=%PHONE_IP%:%DEBUG_PORT%
)

echo Switching to TCP/IP 5555...
"%ADB%" -s "%DEVICE_ID%" tcpip 5555
echo.

echo Connecting final port: %PHONE_IP%:5555
"%ADB%" connect %PHONE_IP%:5555
echo.

set DEVICE_ID=%PHONE_IP%:5555
goto RUN_SCRCPY

:RUN_TCPIP
echo Switching device !DEVICE_ID! to TCP/IP 5555...
"%ADB%" -s "%DEVICE_ID%" tcpip 5555
"%ADB%" connect "%PHONE_IP%:5555"
goto RUN_SCRCPY

:RUN_SCRCPY
:: Launch scrcpy in a detached process so the console can be killed
:: v1p4 Divorced the console from the mirrored image and vice versa
:: start "" /B scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS% >nul 2>&1
echo Launching scrcpy...
start "" scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS% >nul 2>&1
echo(
exit /b

REM end of adbconnect.bat
--
Every post to Usenet should strive to add value that wasn't there before.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote on 6/12/2026 4:17 PM:

Maria Sophia wrote:

I've streamlined adb connections over Wi-Fi between the desktop & Android >>> by eliminating the USB cable & by reducing the need for new cryptic ports. >>

If it takes two steps, we reduce it to one, so here's a reduction in steps.

I made the script more robust where the goal is to simplify connection when mirroring the phone over Wi-Fi (no USB) when you're at home.

Most of the effort is tricks to get around modern Android security fences.

:: adbconnect.bat
:: No-USB, Wi-Fi only, adb/scrcpy static IP and static 5555 port connect
:: v1p0 20260611 converted adbconnect.vbs to adbconnect.bat
:: Connects desktop & phone over adb & mirrors phone on the monitor
:: No USB cord is used in this process as it's all done over Wi-Fi
:: Should work even if either the PC and/or the phone is rebooted
:: The script will ask only for the minimum amount of data needed
:: Change the phone static IP address as needed to fit your LAN IP address
:: v1p1 20260611 reliability improvements added to v1p0
:: Added better device lookup (skip header,ignore blanks,avoid false matches)
:: Added retry logic for adb pair & adb connect (for when phone not ready)
:: Improved polish (consistent quoting, stable scrcpy launch)
:: v1p2 20260611 further reliability improvements added to v1p1
:: Use separate retry counters for pair/connect to avoid loop
:: interference (ATTEMPTS_PAIR, ATTEMPTS_CONN)
:: Added fail-fast with clear error codes and user hints after retry
:: exhaustion
:: Added a detection of the device id after initial connect
:: (handles ephemeral adb ports like 192.168.1.4:54321)
:: Use DEVICE_ID for subsequent -s tcpip command (quoted)
:: to avoid parsing issues with colons
:: Fallback device-id lookup when initial pattern match fails
:: (robust parsing of "adb devices")
:: Consistent quoting of %ADB% and device identifiers to avoid
:: CMD parsing errors
:: v1p3 20260612 moved the pipe outside the FOR command for reliability
:: v1p4 20260612 divorced the console from the mirrored Android image
:: so that either can be killed by the user and the other will remain
@echo off
setlocal enabledelayedexpansion

set PHONE_IP=192.168.1.4
set SCRCPY_OPTS=--keyboard=sdk --always-on-top

echo.
echo === ADB Wireless Auto-Connect ===
echo Phone IP: %PHONE_IP%
echo.

REM 1. Find adb
for /f "delims=" %%A in ('where adb 2^>nul') do (
if not defined ADB set ADB=%%A
)

if not defined ADB (
echo [ERROR] adb.exe not found.
exit /b
)

REM Ensure .exe extension
if /i not "%ADB:~-4%"==".exe" set ADB=%ADB%.exe

echo Using ADB: "%ADB%"
echo.

REM 2. Check if already connected
echo Checking existing ADB devices...

REM v1p1 fixed device lookup:
REM a. skip header line
REM b. ignore blank lines
REM c. only process lines containing digits
REM d. avoid CMD parser bugs by NOT piping inside the FOR command
REM v1p3 moved pipe OUTSIDE the for loop
:: for /f "skip=1 tokens=1" %%D in ('"%ADB%" devices') do (

set DEVICE_ID=
for /f "skip=1 tokens=1" %%I in ('"%ADB%" devices') do (
echo %%I | findstr /R "[0-9]" >nul && (
echo %%I | findstr /I "%PHONE_IP%" >nul && (
if not defined DEVICE_ID set DEVICE_ID=%%I
)
)
)

if defined DEVICE_ID (
echo Already connected on %DEVICE_ID%
goto RUN_TCPIP
)

echo %%D | findstr /R "[0-9]" >nul && (
echo %%D | findstr /i "%PHONE_IP%" >nul && (
echo Already connected on %%D
set DEVICE_ID=%%D
goto RUN_TCPIP
)
)
)

echo Not connected. Need to pair.
echo.

REM 3. Ask user for pairing info
set /p PAIR_PORT=Enter Wireless debugging pairing port (shown on phone):
set /p PAIR_CODE=Enter Wireless debugging pairing code (shown on phone):
set /p DEBUG_PORT=Enter Wireless debugging debug port (shown on phone):

echo.
echo Pairing with: %PHONE_IP%:%PAIR_PORT%

REM Retry logic for adb pair (3 attempts)
set ATTEMPTS_PAIR=0
:PAIR_RETRY
set /a ATTEMPTS_PAIR+=1
"%ADB%" pair %PHONE_IP%:%PAIR_PORT% %PAIR_CODE%
if errorlevel 1 (
if !ATTEMPTS_PAIR! lss 3 (
echo Pair failed, retrying...
timeout /t 2 >nul
goto PAIR_RETRY
) else (
echo [ERROR] adb pair failed after %ATTEMPTS_PAIR% attempts.
echo Hint: Open Wireless debugging -> "Pair device with pairing code" on the phone, then re-run this script.
exit /b 1
)
)
echo.

echo Connecting to debug port: %PHONE_IP%:%DEBUG_PORT%

REM Retry logic for adb connect (3 attempts)
set ATTEMPTS_CONN=0
:CONNECT_RETRY
set /a ATTEMPTS_CONN+=1
"%ADB%" connect %PHONE_IP%:%DEBUG_PORT%
if errorlevel 1 (
if !ATTEMPTS_CONN! lss 3 (
echo Connect failed, retrying...
timeout /t 2 >nul
goto CONNECT_RETRY
) else (
echo [ERROR] adb connect %PHONE_IP%:%DEBUG_PORT% failed after %ATTEMPTS_CONN% attempts.
echo Hint: Ensure phone is on the same Wi-Fi and Wireless debugging pairing UI is active.
exit /b 2
)
)
echo.

REM After connect, get the actual device id reported by adb (handles ephemeral ports)
set DEVICE_ID=
for /f "tokens=1" %%I in ('"%ADB%" devices ^| findstr /R /C:"%PHONE_IP%[: ]"') do (
if not defined DEVICE_ID set DEVICE_ID=%%I
)

if not defined DEVICE_ID (
REM fallback: try to find any non-empty device id line
for /f "skip=1 tokens=1" %%I in ('"%ADB%" devices') do (
echo %%I | findstr /R "[0-9]" >nul && if not defined DEVICE_ID set DEVICE_ID=%%I
)
)

if defined DEVICE_ID (
echo Found device id: "%DEVICE_ID%"
) else (
echo [WARN] No device id found after connect. Continuing using %PHONE_IP%:%DEBUG_PORT% for tcpip attempt.
set DEVICE_ID=%PHONE_IP%:%DEBUG_PORT%
)

echo Switching to TCP/IP 5555...
"%ADB%" -s "%DEVICE_ID%" tcpip 5555
echo.

echo Connecting final port: %PHONE_IP%:5555
"%ADB%" connect %PHONE_IP%:5555
echo.

set DEVICE_ID=%PHONE_IP%:5555
goto RUN_SCRCPY

:RUN_TCPIP
echo Switching device !DEVICE_ID! to TCP/IP 5555...
"%ADB%" -s "%DEVICE_ID%" tcpip 5555
"%ADB%" connect "%PHONE_IP%:5555"
goto RUN_SCRCPY

:RUN_SCRCPY
:: Launch scrcpy in a detached process so the console can be killed
:: v1p4 Divorced the console from the mirrored image and vice versa
:: start "" /B scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS% >nul 2>&1
echo Launching scrcpy...
start "" scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS% >nul 2>&1
echo(
exit /b

REM end of adbconnect.bat

Wonderful Mary. Thanks for adding this value for us!

Keep up your altruistic work.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

UPDATE:

Since others may be using this script, I updated it to ask for the LAN IP address and I converted it to a Linux script (which needs to be tested).

:: adbconnect.bat
:: No-USB, Wi-Fi only, adb/scrcpy static IP and static 5555 port connect
:: v1p5 20260613 Added query asking for the LAN IP address of the phone
:: Reordered comments to allow the current version to be obvious
:: v1p4 20260612 divorced the console from the mirrored Android image
:: so that either can be killed by the user and the other will remain
:: v1p3 20260612 moved the pipe outside the FOR command for reliability
:: v1p2 20260611 further reliability improvements added to v1p1
:: Use separate retry counters for pair/connect to avoid loop
:: interference (ATTEMPTS_PAIR, ATTEMPTS_CONN)
:: Added fail-fast with clear error codes and user hints after retry
:: exhaustion
:: Added a detection of the device id after initial connect
:: (handles ephemeral adb ports like 192.168.1.4:54321)
:: Use DEVICE_ID for subsequent -s tcpip command (quoted)
:: to avoid parsing issues with colons
:: Fallback device-id lookup when initial pattern match fails
:: (robust parsing of "adb devices")
:: Consistent quoting of %ADB% and device identifiers to avoid
:: CMD parsing errors
:: v1p1 20260611 reliability improvements added to v1p0
:: Added better device lookup (skip header,ignore blanks,avoid false matches)
:: Added retry logic for adb pair & adb connect (for when phone not ready)
:: Improved polish (consistent quoting, stable scrcpy launch)
:: v1p0 20260611 converted adbconnect.vbs to adbconnect.bat
:: Connects desktop & phone over adb & mirrors phone on the monitor
:: No USB cord is used in this process as it's all done over Wi-Fi
:: Should work even if either the PC and/or the phone is rebooted
:: The script will ask only for the minimum amount of data needed
:: Change the phone static IP address as needed to fit your LAN IP address
@echo off
setlocal enabledelayedexpansion
:: For phones with static IP addresses, change the next line
set PHONE_IP=192.168.1.4
set SCRCPY_OPTS=--keyboard=sdk --always-on-top

echo.
echo === ADB Wireless Auto-Connect ===
echo === [Developer options > Wireless debugging > on] ===
echo.

REM 1. Find adb
for /f "delims=" %%A in ('where adb 2^>nul') do (
if not defined ADB set ADB=%%A
)

if not defined ADB (
echo [ERROR] adb.exe not found.
exit /b
)

REM Ensure .exe extension
if /i not "%ADB:~-4%"==".exe" set ADB=%ADB%.exe

echo Using ADB: "%ADB%"
echo.

REM 2. Check if already connected
echo Checking existing ADB devices...

REM v1p1 fixed device lookup:
REM a. skip header line
REM b. ignore blank lines
REM c. only process lines containing digits
REM d. avoid CMD parser bugs by NOT piping inside the FOR command
REM v1p3 moved pipe OUTSIDE the for loop
:: for /f "skip=1 tokens=1" %%D in ('"%ADB%" devices') do (

set DEVICE_ID=
for /f "skip=1 tokens=1" %%I in ('"%ADB%" devices') do (
echo %%I | findstr /R "[0-9]" >nul && (
echo %%I | findstr /I "%PHONE_IP%" >nul && (
if not defined DEVICE_ID set DEVICE_ID=%%I
)
)
)

if defined DEVICE_ID (
echo Already connected on %DEVICE_ID%
goto RUN_TCPIP
)

echo %%D | findstr /R "[0-9]" >nul && (
echo %%D | findstr /i "%PHONE_IP%" >nul && (
echo Already connected on %%D
set DEVICE_ID=%%D
goto RUN_TCPIP
)
)
)

echo Not connected. Need to pair.
echo.

REM 3. Ask user for pairing info
echo Necessary pairing information will be shown on the phone:
set /p PHONE_IP=Enter phone IP [%PHONE_IP%] :
set /p PAIR_PORT=Enter Wireless debugging pairing port (shown on phone):
set /p PAIR_CODE=Enter Wireless debugging pairing code (shown on phone):
set /p DEBUG_PORT=Enter Wireless debugging debug port (shown on phone):

echo.
echo Pairing with: %PHONE_IP%:%PAIR_PORT%

REM Retry logic for adb pair (3 attempts)
set ATTEMPTS_PAIR=0
:PAIR_RETRY
set /a ATTEMPTS_PAIR+=1
"%ADB%" pair %PHONE_IP%:%PAIR_PORT% %PAIR_CODE%
if errorlevel 1 (
if !ATTEMPTS_PAIR! lss 3 (
echo Pair failed, retrying...
timeout /t 2 >nul
goto PAIR_RETRY
) else (
echo [ERROR] adb pair failed after %ATTEMPTS_PAIR% attempts.
echo Hint: Open Wireless debugging -> "Pair device with pairing code" on the phone, then re-run this script.
exit /b 1
)
)
echo.

echo Connecting to debug port: %PHONE_IP%:%DEBUG_PORT%

REM Retry logic for adb connect (3 attempts)
set ATTEMPTS_CONN=0
:CONNECT_RETRY
set /a ATTEMPTS_CONN+=1
"%ADB%" connect %PHONE_IP%:%DEBUG_PORT%
if errorlevel 1 (
if !ATTEMPTS_CONN! lss 3 (
echo Connect failed, retrying...
timeout /t 2 >nul
goto CONNECT_RETRY
) else (
echo [ERROR] adb connect %PHONE_IP%:%DEBUG_PORT% failed after %ATTEMPTS_CONN% attempts.
echo Hint: Ensure phone is on the same Wi-Fi and Wireless debugging pairing UI is active.
exit /b 2
)
)
echo.

REM After connect, get the actual device id reported by adb (handles ephemeral ports)
set DEVICE_ID=
for /f "tokens=1" %%I in ('"%ADB%" devices ^| findstr /R /C:"%PHONE_IP%[: ]"') do (
if not defined DEVICE_ID set DEVICE_ID=%%I
)

if not defined DEVICE_ID (
REM fallback: try to find any non-empty device id line
for /f "skip=1 tokens=1" %%I in ('"%ADB%" devices') do (
echo %%I | findstr /R "[0-9]" >nul && if not defined DEVICE_ID set DEVICE_ID=%%I
)
)

if defined DEVICE_ID (
echo Found device id: "%DEVICE_ID%"
) else (
echo [WARN] No device id found after connect. Continuing using %PHONE_IP%:%DEBUG_PORT% for tcpip attempt.
set DEVICE_ID=%PHONE_IP%:%DEBUG_PORT%
)

echo Switching to TCP/IP 5555...
"%ADB%" -s "%DEVICE_ID%" tcpip 5555
echo.

echo Connecting final port: %PHONE_IP%:5555
"%ADB%" connect %PHONE_IP%:5555
echo.

set DEVICE_ID=%PHONE_IP%:5555
goto RUN_SCRCPY

:RUN_TCPIP
echo Switching device !DEVICE_ID! to TCP/IP 5555...
"%ADB%" -s "%DEVICE_ID%" tcpip 5555
"%ADB%" connect "%PHONE_IP%:5555"
goto RUN_SCRCPY

:RUN_SCRCPY
:: Launch scrcpy in a detached process so the console can be killed
:: v1p4 Divorced the console from the mirrored image and vice versa
:: start "" /B scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS% >nul 2>&1
echo Launching scrcpy...
start "" scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS% >nul 2>&1
echo(
exit /b

REM end of adbconnect.bat

===== Linux script below (untested!) needs to be tested =====
#!/usr/bin/env bash
#
# adbconnect.sh
# Wi-Fi-only ADB + scrcpy auto-connect
# Linux bash version of adbconnect.bat
# v1p5 (20260613)
#

set -euo pipefail

# --- USER CONFIG ---

PHONE_IP="192.168.1.4"
SCRCPY_OPTS="--keyboard=sdk --always-on-top"

# --- FUNCTIONS ---

find_adb() {
if command -v adb >/dev/null 2>&1; then
ADB="$(command -v adb)"
else
echo "[ERROR] adb not found in PATH"
exit 1
fi
}

get_device_id() {
DEVICE_ID="$(adb devices | awk -v ip="$PHONE_IP" '
NR>1 && $1 ~ ip {print $1}
')"

if [[ -z "$DEVICE_ID" ]]; then
DEVICE_ID="$(adb devices | awk '
NR>1 && $1 ~ /[0-9]/ {print $1; exit}
')"
fi
}

retry_cmd() {
local attempts=$1
shift
local cmd=("$@")

for ((i=1; i<=attempts; i++)); do
if "${cmd[@]}"; then
return 0
fi
echo "Attempt $i failed, retrying..."
sleep 2
done

return 1
}

# --- MAIN ---

echo
echo "=== ADB Wireless Auto-Connect (Linux) ==="
echo "=== Enable: Developer options -> Wireless debugging ==="
echo

find_adb
echo "Using ADB: $ADB"
echo

echo "Checking existing ADB devices..."
get_device_id

if [[ -n "${DEVICE_ID:-}" ]]; then
echo "Already connected on $DEVICE_ID"
echo "Switching to TCP/IP 5555..."
adb -s "$DEVICE_ID" tcpip 5555
adb connect "$PHONE_IP:5555"
DEVICE_ID="$PHONE_IP:5555"
else
echo "Not connected. Need to pair."
echo

read -rp "Enter phone IP [$PHONE_IP]: " ip_in
[[ -n "$ip_in" ]] && PHONE_IP="$ip_in"

read -rp "Enter pairing port: " PAIR_PORT
read -rp "Enter pairing code: " PAIR_CODE
read -rp "Enter debug port: " DEBUG_PORT

echo
echo

# end of adbconnect.sh
--
On Usenet are helpful kind-hearted volunteers who know how do to things.
And then, there are the trolls... who do not.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

It is hard to me find any reason to use your scripts from this thread.
Maybe they will be useful, when I return to commercial Android programming.

But I have "a buddy-to-buddy reprimand" for you:
Publishing files here like you did is against Netiquette. Because it is allowed only for "binary groups".
So, if you think your scripts are useful, and you can maintain them for
long time (for eg. 5y. - like typical commercial products), then please publish them on separate server. It can be just *.zip, or *.tar.xz
archive on your home page (github.com is not mandatory, and I do not
recommend it due to generating "secret debt" for their users).
--
Z totaliztycznym salutem!
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska Efc|Efc#, UE Efc-Efc|;
tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
UWAGA:
NIE ZACI-aGAJ "UKRYTEGO D+UUGU"! P+UA-a ZA PROG. FOSS I INFO. INTERNETOWE! CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On Mon, 6/15/2026 5:08 AM, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:

It is hard to me find any reason to use your scripts from this thread. Maybe they will be useful, when I return to commercial Android programming.

But I have "a buddy-to-buddy reprimand" for you:
Publishing files here like you did is against Netiquette. Because it is allowed only for "binary groups".
So, if you think your scripts are useful, and you can maintain them for long time (for eg. 5y. - like typical commercial products), then please publish them on separate server. It can be just *.zip, or *.tar.xz archive on your home page (github.com is not mandatory, and I do not recommend it due to generating "secret debt" for their users).

Where did you get this strange idea ?????????????

Script is NOT BINARY FFS. It's text.

And anyone coming here, should review carefully anything
of this nature they find in a posting.

The scripts in the post, are short. Short enough
you would spend the time reading what each command
does, check the manual page of the command, and so on.

A lot of the time, when someone asks for help, it will
require working at the command line (if a GUI tool is not
available to make a change). The instructions in the
post you just read, are barely script quality. You
could execute the lines one by one, in terminal if you want.

I treat the things I find in newsgroup posts, as "conceptual ideas".
Not generally as finished products of a commercial nature,
complete with tech support and a free lunch.

And I believe that the remaining people who come to USENET,
understand this. In the same way if they went to Superuser,
or StackExchange, they would treat any source code or script
with the same "normal suspicion" they always use, and review
it before using it.

The very first time I downloaded FOSS source, I read it
line for line, from one end to the other. 1MB of it!
Why did I do that ? I wanted to see how practical it
would be, to review a work properly before doing
a make, make install. It was a lot of work. The works
in USENET, tend to be shorter posts, like 60 lines of
script would be a relatively long work here. And you should
be prepared to read and research what you just copied off
the screen, before using it. The materials may also receive
feedback from people familiar with the code, and they may
suggest corrections. It is then, a "work in progress".
And if you've been here long enough, you understand all
the dynamics.

*******

Treat what you see here as "illustrations" and don't
be making up silly rules for nothing.

If you "did not allow us to do anything technical here",
what the hell use would this place be ?????????? Get a clue.

Paul
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

W dniu 15.06.2026 o-a18:11, Paul pisze:

Treat what you see here as "illustrations" and don't
be making up silly rules for nothing.

If you "did not allow us to do anything technical here",
what the hell use would this place be ?????????? Get a clue.

You miss one thing: she don't ask anything, but she just publish there
her scripts like on github.com . Usenet is not intended for this except
binary groups.

And please don't introduce me as "mentally mad"! Because I very like discussion with cleaver and smart people. But again: this is not that case.

BTW: I have "mentally mad" diagnosis, but this is pure evil and parasite polish government medics propaganda.
--
Z totaliztycznym salutem!
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska Efc|Efc#, UE Efc-Efc|;
tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
UWAGA:
NIE ZACI-aGAJ "UKRYTEGO D+UUGU"! P+UA-a ZA PROG. FOSS I INFO. INTERNETOWE! CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Paul wrote:

Where did you get this strange idea ?????????????

Script is NOT BINARY FFS. It's text.

Hi Paul,

You are correct that all the script does is show the user what textual commands they can run themselves, by copying and pasting, one at a time,
each line of the script into their console window to see what happens.

The whole point, of course, is that if something takes 10 steps, we reduce
it in half & if it takes 2 steps, we still reduce it in half (if we can).

But there is a PITA with adb.
And a different PITA with scrcpy.

The PITA with adb is that wi-fi connections require all that security stuff and the PITA with scrcpy is that it leaves an open useless console window.

The adb scripts previously posted eliminate the security complications,
but they don't correctly eliminate the scrcpy useless console window yet.

Luckily, I've been using Herbert Kleebauer's ShowWin() script for years.
His script uses a clever method to *hide* the console using ShowWin().

So, if our Polish friend Jacek Marcin Jaworski wants to see some "binary" stuff, here's a version of Herbert's script that I've been using for years!

@echo off
REM C:\app\editor\android\scrcpy\showwin.bat
REM adb mdns services
REM List of discovered mdns services
REM netstat -ano -p tcp | findstr "192.168.1.10"
REM TCP 192.168.1.27:15919 192.168.1.10:41913 ESTABLISHED 7904
REM
cd /d "c:\app\editor\android\scrcpy"
certutil -f -decode %~f0 showwin.exe>nul
REM Port 5555 was needed when you established adb connections over USB
REM And then you disconnected the USB cable to subsequently work on Wi-Fi
REM But as of Android 11 or 12, you can establish the connection over Wi-Fi
REM But that "Developer option" "Wireless debugging" port is assigned by Android!
REM So you have to get it on Android or on Windows to know what it is
REM adb connect 192.168.1.10:5555
REM You can get the current port from the following command
REM c:\> netstat -ano -p tcp | findstr "192.168.1.10"
REM
REM maybe we do NOT need this command after all???
REM adb connect 192.168.1.10:41913

:: now we hide console window
showwin.exe 0

REM scrcpy --always-on-top --tcpip=192.168.1.10:5555
REM Maybe we can then remove the IP:PORT after all???
REM scrcpy --always-on-top --tcpip=192.168.1.10:41913
REM We don't really need --always-on-top after all???
REM scrcpy --always-on-top
REM scrcpy
REM scrcpy -s adb-SERIALNUMBER-kFSyj8._adb-tls-connect._tcp.
REM scrcpy -s 192.168.1.21
REM scrcpy -s SERIALNUMBER
scrcpy -s 192.168.1.4

:: after scrcpy is closed we show console window again
showwin.exe 5

del showwin.exe
goto :eof

-----BEGIN CERTIFICATE-----
TVpgAQEAAAAEAAAA//8AAGABAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAoAAAAA4fug4AtAnNIbgBTM0hTmljZSB0byBtZWV0IHNvbWVi
b2R5IHdobyBpcyBzdGlsbCB1c2luZyBET1MsDQpidXQgdGhpcyBwcm9ncmFtIHJl
cXVpcmVzIFdpbjMyLg0KJFBFAABMAQEAUHmlNgAAAAAAAAAA4AAPAQsBBQwAAgAA
AAAAAAAAAADIEAAAABAAAAAgAAAAAEAAABAAAAACAAAFAAAAAAAAAAQAAAAAAAAA
ACAAAAACAAAAAAAAAwAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA
GBAAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAYAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAAAmAQAAABAAAAACAAAAAgAA
AAAAAAAAAAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoEAAAAAAAAJQQAACmEAAA
uhAAAAAAAABgEAAAAAAAAAAAAABUEAAAABAAAIQQAAAAAAAAAAAAAHYQAAAIEAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABVU0VSMzIuZGxsAABoEAAAAAAAAAAAU2hvd1dp
bmRvdwAAS0VSTkVMMzIuZGxsAACUEAAAphAAALoQAAAAAAAAAABHZXRDb21tYW5k
TGluZUEAAABHZXRDb25zb2xlV2luZG93AAAAAEV4aXRQcm9jZXNzAP8VCBBAADHS
SECAOAB0EYA4InUC99IJ0nXvgDggdepAMfa9BQAAAA+2EEAI0nQTgOowcvOA+gl3
7mv2CgHWMe3r5QntdAKJ7v8VDBBAAFZQ/xUAEEAAagD/FRAQQAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA==
-----END CERTIFICATE-----
--
(Now Jacek Marcin Jaworski has a binary to complain about!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Jacek Marcin Jaworski wrote:

You miss one thing, they don't ask anything, but just publish their scripts Usenet is not intended for this except binary groups.

The question is how to run adb/scrcpy over Wi-Fi in a single step.
And, how to launch scrcpy mirroring without the console window.

In the past, many people offered help, as we've been asking for years.
For example, I posted previously Herbert Kleebauer's ShowWin() method.

But I think in this latest version, today, I solved the two main issues:
a. How to connect Android to desktop over Wi-Fi without hassle, and,
b. How to run scrcpy without having to deal with a worthless console.

The previous versions of the script eliminated as much of the PITA that adb enforces in later versions of Android for security purposes, but they still didn't correctly eliminate that scrcpy.exe forces an active console window.

If anyone who uses scrcpy has ever found a single use for that active
console window, please let me know because it just wastes real estate.

Since I can't figure out why I'd want a console window just doing nothing,
I went to some trouble today to get rid of it in this latest version.

Basically, I incorporated the scrcpy-noconsole.vbs script that comes native with adb (or maybe it came with scrcpy, it has been so long that I forget).

'scrcpy-noconsole.vbs
' strCommand = "cmd /c scrcpy.exe"
strCommand = "cmd /c scrcpy.exe --keyboard=sdk --always-on-top"

For Each Arg In WScript.Arguments
strCommand = strCommand & " """ & replace(Arg, """", """""""""") & """"
Next

CreateObject("Wscript.Shell").Run strCommand, 0, false

In v1p6 yesterday, I called that file from the adbconnect.bat script.
But in v1p7 below, I removed the need for that file to exist in the path.


:: adbconnect.bat
:: No-USB, Wi-Fi only, adb/scrcpy static IP and static 5555 port connect
:: v1p7 20260615
:: Removed the requirement for the "no-console" vbs script
:: by injecting the necessary commands into a temporary file
:: This is the cleanest way I can think of to eliminate the console.
:: v1p6 20260614
:: Called the vbs "no-console" script that comes with adb.
:: If the script isn't there, then it defaults to the old method.
:: The problem is getting completely rid of the scrcpy console isn't working.
:: These are the known scrcpy console-hiding methods:
:: (a) cmd /c start "" /min (minimizes the console)
:: The console is not hidden. It's just minimized.
:: (b) cmd start "" /B (background launch of detached console)
:: This detaches scrcpy from the batch console
:: (c) adb default VBS no-console wrapper (fully hidden window)
:: Default GUI-subsystem scrcpy launch (so no console is created)
:: CreateObject("Wscript.Shell").Run strCommand, 0, False
:: (d) Kleebauer ShowWindow() controller trick to hide the batch console
:: showwin.exe 0 SW_HIDE (Hides the batch console)
:: (e) Powershell ShowWindowAsync (similar idea to Herbert's ShowWindow()
:: Add-Type '[DllImport("user32.dll")]
:: public static extern bool
:: ShowWindowAsync(IntPtr hWnd, int nCmdShow);'
:: Here is the original scrcpy-noconsole.vbs that comes with adb
:: strCommand = "cmd /c scrcpy.exe"
:: For Each Arg In WScript.Arguments
:: strCommand = strCommand & " """ & replace(Arg, """", """""""""") & """"
:: Next
:: CreateObject("Wscript.Shell").Run strCommand, 0, false
:: v1p5 20260613 Added query asking for the LAN IP address of the phone
:: Reordered comments to allow the current version to be obvious
:: v1p4 20260612 minimized the scrcpy console (but it's still there)
:: using cmd /c start "" /min (minimizes the console only)
:: The only known choices are
:: (a) Minimized console-subsystem launch (cmd /c start "" /min)
:: (b) Background detached launch (start "" /B)
:: (c) Hidden GUI-subsystem VBS launcher (no console created)
:: (d) External ShowWindow() console-visibility controller (Kleebauer trick)
:: (e) PowerShell ShowWindowAsync console hider (similar to ShowWindow())
:: v1p3 20260612 moved the pipe outside the FOR command for reliability
:: v1p2 20260611 further reliability improvements added to v1p1
:: Use separate retry counters for pair/connect to avoid loop
:: interference (ATTEMPTS_PAIR, ATTEMPTS_CONN)
:: Added fail-fast with clear error codes and user hints after retry
:: exhaustion
:: Added a detection of the device id after initial connect
:: (handles ephemeral adb ports like 192.168.1.4:54321)
:: Use DEVICE_ID for subsequent -s tcpip command (quoted)
:: to avoid parsing issues with colons
:: Fallback device-id lookup when initial pattern match fails
:: (robust parsing of "adb devices")
:: Consistent quoting of %ADB% and device identifiers to avoid
:: CMD parsing errors
:: v1p1 20260611 reliability improvements added to v1p0
:: Added better device lookup (skip header,ignore blanks,avoid false matches)
:: Added retry logic for adb pair & adb connect (for when phone not ready)
:: Improved polish (consistent quoting, stable scrcpy launch)
:: v1p0 20260611 converted adbconnect.vbs to adbconnect.bat
:: Connects desktop & phone over adb & mirrors phone on the monitor
:: No USB cord is used in this process as it's all done over Wi-Fi
:: Should work even if either the PC and/or the phone is rebooted
:: The script will ask only for the minimum amount of data needed
:: Change the phone static IP address as needed to fit your LAN IP address
@echo off
setlocal enabledelayedexpansion
:: For phones with static IP addresses, change the next line
set PHONE_IP=192.168.1.4
set SCRCPY_OPTS=--keyboard=sdk --always-on-top

echo.
echo === ADB Wireless Auto-Connect ===
echo === [Developer options > Wireless debugging > on] ===
echo.

REM 1. Find adb
for /f "delims=" %%A in ('where adb 2^>nul') do (
if not defined ADB set ADB=%%A
)

if not defined ADB (
echo [ERROR] adb.exe not found.
exit /b
)

REM Ensure .exe extension
if /i not "%ADB:~-4%"==".exe" set ADB=%ADB%.exe

echo Using ADB: "%ADB%"
echo.

REM 2. Check if already connected
echo Checking existing ADB devices...

REM v1p1 fixed device lookup:
REM a. skip header line
REM b. ignore blank lines
REM c. only process lines containing digits
REM d. avoid CMD parser bugs by NOT piping inside the FOR command
REM v1p3 moved pipe OUTSIDE the for loop
:: for /f "skip=1 tokens=1" %%D in ('"%ADB%" devices') do (

set DEVICE_ID=
for /f "skip=1 tokens=1" %%I in ('"%ADB%" devices') do (
echo %%I | findstr /R "[0-9]" >nul && (
echo %%I | findstr /I "%PHONE_IP%" >nul && (
if not defined DEVICE_ID set DEVICE_ID=%%I
)
)
)

if defined DEVICE_ID (
echo Already connected on %DEVICE_ID%
goto RUN_TCPIP
)

echo %%D | findstr /R "[0-9]" >nul && (
echo %%D | findstr /i "%PHONE_IP%" >nul && (
echo Already connected on %%D
set DEVICE_ID=%%D
goto RUN_TCPIP
)
)
)

echo Not connected. Need to pair.
echo.

REM 3. Ask user for pairing info
echo Necessary pairing information will be shown on the phone:
set /p PHONE_IP=Phone IP [%PHONE_IP%] :
set /p PAIR_PORT=Wireless debugging pairing port (e.g., 333123 on phone):
set /p PAIR_CODE=Wireless debugging pairing code (e.g., 555123 on phone):
set /p DEBUG_PORT=Wireless debugging debug port (e.g., 444123 on phone):

echo.
echo Pairing with: %PHONE_IP%:%PAIR_PORT%

REM Retry logic for adb pair (3 attempts)
set ATTEMPTS_PAIR=0
:PAIR_RETRY
set /a ATTEMPTS_PAIR+=1
"%ADB%" pair %PHONE_IP%:%PAIR_PORT% %PAIR_CODE%
if errorlevel 1 (
if !ATTEMPTS_PAIR! lss 3 (
echo Pair failed, retrying...
timeout /t 2 >nul
goto PAIR_RETRY
) else (
echo [ERROR] adb pair failed after %ATTEMPTS_PAIR% attempts.
echo Hint: Open Wireless debugging -> "Pair device with pairing code" on the phone, then re-run this script.
exit /b 1
)
)
echo.

echo Connecting to debug port: %PHONE_IP%:%DEBUG_PORT%

REM Retry logic for adb connect (3 attempts)
set ATTEMPTS_CONN=0
:CONNECT_RETRY
set /a ATTEMPTS_CONN+=1
"%ADB%" connect %PHONE_IP%:%DEBUG_PORT%
if errorlevel 1 (
if !ATTEMPTS_CONN! lss 3 (
echo Connect failed, retrying...
timeout /t 2 >nul
goto CONNECT_RETRY
) else (
echo [ERROR] adb connect %PHONE_IP%:%DEBUG_PORT% failed after %ATTEMPTS_CONN% attempts.
echo Hint: Ensure phone is on the same Wi-Fi and Wireless debugging pairing UI is active.
exit /b 2
)
)
echo.

REM After connect, get the actual device id reported by adb (handles ephemeral ports)
set DEVICE_ID=
for /f "tokens=1" %%I in ('"%ADB%" devices ^| findstr /R /C:"%PHONE_IP%[: ]"') do (
if not defined DEVICE_ID set DEVICE_ID=%%I
)

if not defined DEVICE_ID (
REM fallback: try to find any non-empty device id line
for /f "skip=1 tokens=1" %%I in ('"%ADB%" devices') do (
echo %%I | findstr /R "[0-9]" >nul && if not defined DEVICE_ID set DEVICE_ID=%%I
)
)

if defined DEVICE_ID (
echo Found device id: "%DEVICE_ID%"
) else (
echo [WARN] No device id found after connect. Continuing using %PHONE_IP%:%DEBUG_PORT% for tcpip attempt.
set DEVICE_ID=%PHONE_IP%:%DEBUG_PORT%
)

echo Switching to TCP/IP 5555...
"%ADB%" -s "%DEVICE_ID%" tcpip 5555
echo.

echo Connecting final port: %PHONE_IP%:5555
"%ADB%" connect %PHONE_IP%:5555
echo.

set DEVICE_ID=%PHONE_IP%:5555
goto RUN_SCRCPY

:RUN_TCPIP
echo Switching device !DEVICE_ID! to TCP/IP 5555...
"%ADB%" -s "%DEVICE_ID%" tcpip 5555
"%ADB%" connect "%PHONE_IP%:5555"
goto RUN_SCRCPY

:: Removed in v1p6 versions and up
:: :RUN_SCRCPY
:: Launch scrcpy in a detached process so the console can be killed
:: v1p4 Divorced the console from the mirrored image and vice versa
:: start "" /B scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS% >nul 2>&1
:: echo Launching scrcpy...
:: start "" scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS% >nul 2>&1
:: echo(
:: exit /b

:: Calling the default adb scrcpy-noconsole.vbs script in v1p6
:: :RUN_SCRCPY
:: echo Launching scrcpy silently...
:: :: Target the official adb VBS wrapper instead of the raw .exe
:: if exist "scrcpy-noconsole.vbs" (
:: wscript.exe "scrcpy-noconsole.vbs" --tcpip=%PHONE_IP% %SCRCPY_OPTS%
:: ) else (
:: :: Fallback just in case the file isn't in the same directory
:: start "" /B scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS% >nul 2>&1
:: )
:: echo(
:: exit /b

:: v1p7 Inject temporary file instead of calling existing no-console vbs
:RUN_SCRCPY
echo Launching scrcpy completely silent...

set "VBS_TEMP=%TEMP%\scrcpy_runner.vbs"

:: Build the standalone VBS command string directly into the temp file
echo strCommand = "cmd /c scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%" > "%VBS_TEMP%"
echo CreateObject("Wscript.Shell").Run strCommand, 0, false >> "%VBS_TEMP%"

:: Execute the temporary VBS script
wscript.exe "%VBS_TEMP%"

:: Brief pause to ensure script allocation completes before cleaning up the temp file
timeout /t 1 >nul
if exist "%VBS_TEMP%" del "%VBS_TEMP%"

echo Done.
exit /b

REM end of adbconnect.bat
--
The question is how to run adb/scrcpy in a single step without the security stuff.
And, how to launch scrcpy mirroring without the console window taking up space. --- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

The question is how to run adb/scrcpy over Wi-Fi in a single step.
And, how to launch scrcpy mirroring without the console window.

Since everything we automate should also work on Linux, here's an
(untested) shell script that Linux users can test out for the team.

The goal is to eliminate *all* the haslses when using adb over Wi-Fi (or
USB) and when using scrcpy to mirror the Android phone onto the monitor.

#!/bin/bash

# ###########################################################################
# adbconnect.sh (Automate Android-to-desktop Wi-Fi adb/scrcpy connections)
# Solves two problems when connecting a desktop to adb/scrcpy for Android.
# 1. Eliminate all useless random-security steps in a Wi-Fi adb connection
# 2. Eliminate the useless scrcpy console window which just takes up space
#
# v1p7_lnx 20260615
# Ported to Linux bash syntax. Removed all Windows VBS console-hiding
# workarounds. Used native Linux backgrounding (&) and disown.
# ###########################################################################

# ---------------------------------------------------------------------------
# USER VARIABLES & CONFIGURATION
# ---------------------------------------------------------------------------
# For phones with static IP addresses, change the next line
PHONE_IP="192.168.1.2"
SCRCPY_OPTS="--keyboard=sdk --always-on-top"

echo ""
echo "=== ADB Wireless Auto-Connect ==="
echo "=== [Developer options > Wireless debugging > on] ==="
echo ""

# ---------------------------------------------------------------------------
# STEP 1: LOCATE ADB BINARY
# ---------------------------------------------------------------------------
# 'which' locates a command binary path in Linux.
# If not found, output errors to /dev/null (silence)
ADB=$(which adb 2>/dev/null)

if [ -z "$ADB" ]; then
echo "[ERROR] adb binary not found in your PATH."
echo "Please install adb via your package manager (e.g., sudo apt install adb)."
exit 1
fi

echo "Using ADB: $ADB"
echo ""

# ---------------------------------------------------------------------------
# STEP 2: CHECK EXISTING CONNECTIONS
# ---------------------------------------------------------------------------
echo "Checking existing ADB devices..."

# 'adb devices' returns a header followed by active devices.
# We skip the first line (header) using tail, look for a line matching our IP,
# and extract the first block (the exact target identifier).
DEVICE_ID=$("$ADB" devices | tail -n +2 | grep "$PHONE_IP" | awk '{print $1}')

if [ -not -z "$DEVICE_ID" ]; then
echo "Already connected on $DEVICE_ID"

# Re-verify and jump to standard TCP/IP fallback sequence
echo "Switching device $DEVICE_ID to TCP/IP 5555..."
"$ADB" -s "$DEVICE_ID" tcpip 5555
"$ADB" connect "$PHONE_IP:5555"

# Jump to final scrcpy phase
DEVICE_ID="$PHONE_IP:5555"
echo "Launching scrcpy completely silent..."
scrcpy --tcpip="$PHONE_IP" $SCRCPY_OPTS >/dev/null 2>&1 &
disown
echo "Done."
exit 0
fi

echo "Not connected. Need to pair."
echo ""

# ---------------------------------------------------------------------------
# STEP 3: CONSOLE PROMPTS FOR PAIRING DATA
# ---------------------------------------------------------------------------
echo "Necessary pairing information will be shown on the phone:"

# Prompt syntax: read -p "Prompt message: " VARIABLE
# The code syntax '${VARIABLE:-default}' preserves default values if input is blank
read -p "Phone IP [$PHONE_IP] : " INPUT_IP
PHONE_IP=${INPUT_IP:-$PHONE_IP}

read -p "Wireless debugging pairing port (e.g., 333123 on phone): " PAIR_PORT
read -p "Wireless debugging pairing code (e.g., 555123 on phone): " PAIR_CODE
read -p "Wireless debugging debug port (e.g., 444123 on phone): " DEBUG_PORT

echo ""
echo "Pairing with: $PHONE_IP:$PAIR_PORT"

# ---------------------------------------------------------------------------
# STEP 4: RETRY LOGIC FOR ADB PAIRING
# ---------------------------------------------------------------------------
ATTEMPTS_PAIR=0
while [ $ATTEMPTS_PAIR -lt 3 ]; do
ATTEMPTS_PAIR=$((ATTEMPTS_PAIR + 1))

"$ADB" pair "$PHONE_IP:$PAIR_PORT" "$PAIR_CODE"
if [ $? -eq 0 ]; then
# Pair succeeded break the retry loop
break
else
if [ $ATTEMPTS_PAIR -lt 3 ]; then
echo "Pair failed, retrying in 2 seconds..."
sleep 2
else
echo "[ERROR] adb pair failed after $ATTEMPTS_PAIR attempts."
echo "Hint: Open Wireless debugging -> 'Pair device with pairing code' on the phone, then re-run this script."
exit 1
fi
fi
done

echo ""
echo "Connecting to debug port: $PHONE_IP:$DEBUG_PORT"

# ---------------------------------------------------------------------------
# STEP 5: RETRY LOGIC FOR ADB CONNECTION
# ---------------------------------------------------------------------------
ATTEMPTS_CONN=0
while [ $ATTEMPTS_CONN -lt 3 ]; do
ATTEMPTS_CONN=$((ATTEMPTS_CONN + 1))

"$ADB" connect "$PHONE_IP:$DEBUG_PORT"
if [ $? -eq 0 ]; then
# Connection succeeded break the loop
break
else
if [ $ATTEMPTS_CONN -lt 3 ]; then
echo "Connect failed, retrying in 2 seconds..."
sleep 2
else
echo "[ERROR] adb connect $PHONE_IP:$DEBUG_PORT failed after $ATTEMPTS_CONN attempts."
echo "Hint: Ensure phone is on the same Wi-Fi and Wireless debugging pairing UI is active."
exit 2
fi
fi
done
echo ""

# ---------------------------------------------------------------------------
# STEP 6: CAPTURE EMISSIVE IP/PORT SCHEMES
# ---------------------------------------------------------------------------
# Re-scan adb devices to parse dynamic port assignments
DEVICE_ID=$("$ADB" devices | grep "$PHONE_IP" | awk '{print $1}' | head -n 1)

if [ -z "$DEVICE_ID" ]; then
# Fallback structure: isolate any active digital network string address
DEVICE_ID=$("$ADB" devices | tail -n +2 | grep -E '[0-9]' | awk '{print $1}' | head -n 1)
fi

if [ ! -z "$DEVICE_ID" ]; then
echo "Found device id: \"$DEVICE_ID\""
else
echo "[WARN] No device id found after connect. Continuing using $PHONE_IP:$DEBUG_PORT for tcpip attempt."
DEVICE_ID="$PHONE_IP:$DEBUG_PORT"
fi

# ---------------------------------------------------------------------------
# STEP 7: TRANSITION TO PERSISTENT PORT 5555
# ---------------------------------------------------------------------------
echo "Switching to TCP/IP 5555..."
"$ADB" -s "$DEVICE_ID" tcpip 5555
echo ""

echo "Connecting final port: $PHONE_IP:5555"
"$ADB" connect "$PHONE_IP:5555"
echo ""

# ---------------------------------------------------------------------------
# STEP 8: SILENTLY DEPLOY SCRCPY
# ---------------------------------------------------------------------------
echo "Launching scrcpy completely silent..."

# How it works in Linux:
# '>/dev/null 2>&1' strips all console logs/outputs out completely.
# '&' forks the program safely to a background daemon worker thread.
# 'disown' severs ties to the controlling terminal, ensuring it stays open when this terminal closes.
scrcpy --tcpip="$PHONE_IP" $SCRCPY_OPTS >/dev/null 2>&1 &
disown

echo "Done."
exit 0
--
On Usenet, volunteers can find a solution which everyone can then use.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 15/06/2026 19:56, Maria Sophia wrote:

The whole point, of course, is that if something takes 10 steps, we reduce
it in half & if it takes 2 steps, we still reduce it in half (if we can).

This is where people use Warpinator. It allows them to transfer files
between any operating systems, including Android, iOS, macOS, Linux and Windows. Why waste time reinventing a wheel that might not even work?
Go and try it and post your tutorial for Jacek Marcin Jaworski <jmj@energokod.gda.pl> to follow.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Warpinator wrote:

This is where people use Warpinator. It allows them to transfer files between any operating systems, including Android, iOS, macOS, Linux and Windows. Why waste time reinventing a wheel that might not even work?

First, to be clear, transferring files is just one minor thing that adb
does, along with screen copy, between desktops and Android phones.

However...

If I wanted to "transfer files" only, between *any* two operating systems,
I'd use LocalSend first, since it's the canonical app for that purpose.
<https://localsend.org/download>

Even with that in mind, since I have never heard of warpinator, I looked up what it is and how it compares to local send in terms of what matters.
<https://warpinator.net/>

Apparently LocalSend and Warpinator both transfer files over the local
network without using the cloud, so they only fundamentally differ in architecture, platform support, and workflow.
Android: https://github.com/slowscript/warpinator-android
Windows: https://winpinator.swisz.cz
Windows: https://github.com/slowscript/warpinator-windows

Apparently LocalSend uses HTTPS with self-generated TLS certificates, encrypting all traffic without relying on external authorities. By way of contrast, apparently Warpinator uses SSH-based secure transfers.

Apparently LocalSend has a more mature GUI but the Linux Warpinator GUI is apparently tried and true, so it's a good choice for the Linux team. It's especially useful on Mint systems as it comes pre-installed by default.

It's a little disturbing that the canonical warpinator page is broken
(at least when I went there using the MS Edge browser on Windows 10)
1. https://warpinator.net/
2. https://warpinator.net/download/
3. https://warpinator.net/Warpinator-Download
"Page Not Found
The page you are looking for does not exist, or it has been moved.
Please try searching using the form below."

Luckily, there is an unofficial warpinator for Windows distribution
<https://github.com/slowscript/warpinator-windows>

Note that web page above warns people ...
"http://warpinator.com is a fake website, potentially malicious!"

REFERENCES:
<https://wowmania.es/en/LocalSend-vs-Warpinator%3A-A-Real-World-Local-Area-Network-Comparison/>
--
I am not here for my ego; nor for my amusement; but to teach & learn.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Efc|Efc#Jacek Marcin JaworskiEfc|Efc# <jmj@energokod.gda.pl> wrote:

It is hard to me find any reason to use your scripts from this thread.
Maybe they will be useful, when I return to commercial Android programming.

But I have "a buddy-to-buddy reprimand" for you:
Publishing files here like you did is against Netiquette. Because it is allowed only for "binary groups".
So, if you think your scripts are useful, and you can maintain them for
long time (for eg. 5y. - like typical commercial products), then please publish them on separate server. It can be just *.zip, or *.tar.xz
archive on your home page (github.com is not mandatory, and I do not recommend it due to generating "secret debt" for their users).

I agree that pointing to a stable online resource designed for code is so
much better than this particular poster's constant tweaking of their
personal scripts on usenet.

I mean, how is anyone meant to know which is the final and definitive
version without trawling through screeds of threads? Assuming they even
work outside of his very non-standard set up.

You're flogging an already dead and turned into dog food horse. I've made
the same suggestion to "Arlen" several times over the years, but he refuses
for "privacy" reasons (sic). He just doesn't understand how internet
anonymity really works.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

I agree that pointing to a stable online resource designed for code is so much better than this particular poster's constant tweaking of their
personal scripts on usenet.

Hi Chris,

C'mon. You're actually complaining that I provided fully working Windows scripts, and that I improved them, and that I ported them to Linux for you?

Or are you complaining that I didn't test on Linux (as I don't have Linux).

Bear in mind I could have simply asked the perfectly valid question:
Q: How do you connect to ADB & scrcpy in a single step?
A: ?

But I did better than that.
Not only did I ask the question, but I answered the question that I asked.

If you have a *better* method, then I'm all ears.

Q: What do *you* do to run adb & scrcpy in one step on Windows or Linux?
A: ?
--
Some people can do good things, but others simply complain that they can't.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-06-16 02:18, Maria Sophia wrote:

Apparently LocalSend has a more mature GUI but the Linux Warpinator GUI is apparently tried and true, so it's a good choice for the Linux team. It's especially useful on Mint systems as it comes pre-installed by default.

It is available on openSUSE Leap 16.0.
I never heard of it.
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-06-16 09:21, Maria Sophia wrote:

Chris wrote:

I agree that pointing to a stable online resource designed for code is so
much better than this particular poster's constant tweaking of their
personal scripts on usenet.

Hi Chris,

C'mon. You're actually complaining that I provided fully working Windows scripts, and that I improved them, and that I ported them to Linux for you?

You do not understand the criticism. Or you feign not understanding.

The rest of the post is unrelated, thus deleted
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia <mariasophia@comprehension.com> wrote:

Chris wrote:

I agree that pointing to a stable online resource designed for code is so
much better than this particular poster's constant tweaking of their
personal scripts on usenet.

Hi Chris,

C'mon. You're actually complaining that I provided fully working Windows scripts, and that I improved them, and that I ported them to Linux for you?

Nope. Try comprehending what I actually wrote rather than responding to something I didn't.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. wrote:

C'mon. You're actually complaining that I provided fully working Windows
scripts, and that I improved them, and that I ported them to Linux for you?

You do not understand the criticism.

If Chris had even once in his entire life ever invested the time and energy
to post a working tutorial or PSA or working code that he labored on to
help himself and others, I'd understand better his complaint that he can't.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

I agree that pointing to a stable online resource designed for code is so >>> much better than this particular poster's constant tweaking of their
personal scripts on usenet.

Hi Chris,

C'mon. You're actually complaining that I provided fully working Windows
scripts, and that I improved them, and that I ported them to Linux for you?

Nope. Try comprehending what I actually wrote rather than responding to something I didn't.

In your entire life, how many times have you invested the time and energy
to post a working tutorial or PSA or working code that you labored on to
help yourself and others, and where did you post that working example to?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-06-16 19:07, Maria Sophia wrote:

Carlos E. R. wrote:

C'mon. You're actually complaining that I provided fully working Windows >>> scripts, and that I improved them, and that I ported them to Linux for you? >>

You do not understand the criticism.

If Chris had even once in his entire life ever invested the time and energy to post a working tutorial or PSA or working code that he labored on to
help himself and others, I'd understand better his complaint that he can't.

Accusing others doesn't change facts.
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. wrote:

On 2026-06-16 19:07, Maria Sophia wrote:

Carlos E. R. wrote:

C'mon. You're actually complaining that I provided fully working Windows >>>> scripts, and that I improved them, and that I ported them to Linux for you?

You do not understand the criticism.

If Chris had even once in his entire life ever invested the time and energy >> to post a working tutorial or PSA or working code that he labored on to
help himself and others, I'd understand better his complaint that he can't.

Accusing others doesn't change facts.

Well, I'm going to ask *you* to provide something that is worth value.

Given I've posted, oh, I don't know, hundreds of useful scripts...
Q: What specific web site do you suggest I post the final script to?
a. It needs to have no requirement for a login/account
b. It needs to be free
c. It needs to be easy to post to (and to update, if necessary)?
A: ???

To help you add value (instead of just complaining I add too much value),
all I ask you to do is answer the question above so that I can post it.

Here's a README description of how it simplifies Wi-Fi adb/scrcpy usage
which should help you find the location you claim I should post it to.

README: adbconnect.bat
Automate Android-to-desktop Wi-Fi adb and scrcpy connections

1. Purpose
A. This script automates connecting a desktop to an Android phone over
Wi-Fi using adb and scrcpy on your local LAN (in a single step).
B. It removes unnecessary pairing steps normally required by adb/scrcpy
C. It launches scrcpy without leaving a console window visible.

2. What the script solves
A. Eliminates repeated manual pairing steps for Wi-Fi adb.
B. Avoids the scrcpy console window by generating a temporary VBS
launcher that runs scrcpy in a hidden window.
C. Handles device discovery, retries, and fallback logic so the
connection works even after reboots.

3. How it works
A. Finds adb automatically on the system path.
B. Checks whether the phone is already connected.
C. If not connected, it asks for:
a. Phone IP address
b. Pairing port
c. Pairing code
d. Debug port
D. Performs adb pair with retry logic.
E. Performs adb connect with retry logic.
F. Detects the actual device id reported by adb, including ephemeral
ports.
G. Switches the device to tcpip mode on port 5555.
H. Connects again on port 5555 for the final stable link.
I. Builds a temporary VBS file that launches scrcpy silently.
J. Runs the VBS file, then deletes it.

4. Version history summary
A. v1p7
a. Removes dependency on the external no-console VBS file.
b. Generates a temporary VBS launcher instead.
B. v1p6
a. Used the official scrcpy-noconsole.vbs when available.
C. v1p5
a. Added prompt for phone LAN IP.
D. v1p4
a. Minimized scrcpy console but could not hide it fully.
E. v1p3
a. Improved device lookup reliability.
F. v1p2
a. Added separate retry counters, fail-fast behavior,
and added a much more robust device-id parsing.
G. v1p1
a. Improved device lookup and retry logic.
H. v1p0
a. First batch version replacing the older VBS script.

5. Requirements (root is not required)
A. Android phone with Wireless debugging enabled.
B. Desktop with adb and scrcpy installed.
C. Phone reachable on LAN over Wi-Fi via its IP address.

6. Typical workflow
A. Run the script.
B. If already connected, it switches to tcpip mode & launches scrcpy.
C. If not connected, it asks for pairing info and completes the
connection automatically.
D. scrcpy Android mirroring appears without any console window.

7. Notes
A. The script uses only temporary files and cleans them up.
B. It avoids all non-essential console output.
C. It is designed to be safe to run repeatedly.
D. A Linux port has been provided, but is as yet untested.
--
There are people who spend inordinate energy always helping others.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-06-16 21:40, Maria Sophia wrote:

Carlos E. R. wrote:

On 2026-06-16 19:07, Maria Sophia wrote:

Carlos E. R. wrote:

C'mon. You're actually complaining that I provided fully working Windows >>>>> scripts, and that I improved them, and that I ported them to Linux for you?

You do not understand the criticism.

If Chris had even once in his entire life ever invested the time and energy >>> to post a working tutorial or PSA or working code that he labored on to
help himself and others, I'd understand better his complaint that he can't. >>

Accusing others doesn't change facts.

Well, I'm going to ask *you* to provide something that is worth value.

Given I've posted, oh, I don't know, hundreds of useful scripts...
Q: What specific web site do you suggest I post the final script to?

Up to you, and it wasn't my idea, anyway :-)

I have never done this, so I can not advise

You could use github, or hire a server of your own somewhere. Or set up
a server at home. Sourceforge, perhaps (this one I have used).

a. It needs to have no requirement for a login/account
b. It needs to be free
c. It needs to be easy to post to (and to update, if necessary)?
A: ???

To help you add value (instead of just complaining I add too much value),
all I ask you to do is answer the question above so that I can post it.

Here's a README description of how it simplifies Wi-Fi adb/scrcpy usage
which should help you find the location you claim I should post it to.

No, this is not relevant to the question.
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. wrote:

Given I've posted, oh, I don't know, hundreds of useful scripts...
Q: What specific web site do you suggest I post the final script to?

Up to you, and it wasn't my idea, anyway :-)

I have never done this, so I can not advise

You could use github, or hire a server of your own somewhere. Or set up
a server at home. Sourceforge, perhaps (this one I have used).

The point of the rhetorical question is that it likely doesn't exist.

Only Usenet will allow me to post the code sans creating a login/account.

So Chris is asking me to do that which nobody can do, as far as we know.
--
Most people are intuitive so they make guesses without checking them;
but when they check their intuitive assumptions, they are often wrong.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia <mariasophia@comprehension.com> wrote:

Chris wrote:

I agree that pointing to a stable online resource designed for code is so >>>> much better than this particular poster's constant tweaking of their
personal scripts on usenet.

Hi Chris,

C'mon. You're actually complaining that I provided fully working Windows >>> scripts, and that I improved them, and that I ported them to Linux for you? >>

Nope. Try comprehending what I actually wrote rather than responding to
something I didn't.

In your entire life, how many times have you invested the time and energy
to post a working tutorial or PSA or working code that you labored on to
help yourself and others, and where did you post that working example to?

Given I'm a University academic teaching Masters students and supervise PhD students, plus I've provided professional training to other academics in software coding principles; quite a lot.

*I* have posted those on github (search Software Carpentry lessons for an
idea of the kind of thing), on internal student teaching platforms and
staff sharepoint sites. If *I* referenced ("thousands", lol) unfindable so-called tutorials on usenet in my appraisals, I'd lose all credibility.

In a former life, I also contributed to the codebase of a linux
distribution. Anonymously <gasp>!

This is why *I* know what *I* am talking about.

Now, back to *you*. What help do *you* need to do things properly?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 06/16/2026 3:40 PM, Maria Sophia wrote:

Carlos E. R. wrote:

On 2026-06-16 19:07, Maria Sophia wrote:

Carlos E. R. wrote:

C'mon. You're actually complaining that I provided fully working Windows >>>>> scripts, and that I improved them, and that I ported them to Linux for you?

You do not understand the criticism.

If Chris had even once in his entire life ever invested the time and energy >>> to post a working tutorial or PSA or working code that he labored on to
help himself and others, I'd understand better his complaint that he can't. >>

Accusing others doesn't change facts.

Well, I'm going to ask *you* to provide something that is worth value.

At this stage...those requests(to anyone) get closer the edge of pettiness.

Be confident in your content, regardless of the feedback especially when
few reply on its value.
- for a better assessment of what's been read, a blog might prove more visits, then just a simple link to the blog article would/could be
appropriate for nntp users.
--
...w-i|#-o-#-n|#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

At Mon, 15 Jun 2026 14:10:00 -0500, Maria Sophia <mariasophia@comprehension.com> wrote:

Jacek Marcin Jaworski wrote:

You miss one thing, they don't ask anything, but just publish their scripts Usenet is not intended for this except binary groups.

The question is how to run adb/scrcpy over Wi-Fi in a single step.
And, how to launch scrcpy mirroring without the console window.

While I am usually quite annoyed with your windows spew, you did
just let me know about scrcpy.

I just finised a digital signage app that uses a Linux box
to control a Fire TV over the web. Just discovered that
scrcpy will connect to it, thus allowing me to verify that
the slide show is running properly. (I use ssh -X to connect
to the Linux box remotely, and scrcpy works great over that X
connection.)

So thank you for that.
--
-v System76 Thelio Mega v1.1 x86_64 Mem: 258G
OS: Linux 7.1.0 D: Mint 22.3 DE: Xfce 4.18 (X11)
NVIDIA GeForce RTX 3090Ti (24G) (610.43.02)
"Check book: a book with a unhappy ending."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

vallor wrote:

I just finised a digital signage app that uses a Linux box
to control a Fire TV over the web. Just discovered that
scrcpy will connect to it, thus allowing me to verify that
the slide show is running properly. (I use ssh -X to connect
to the Linux box remotely, and scrcpy works great over that X
connection.)

Since the whole point is to help others, I'm elated to hear the scrcpy tip
was useful to you in your efforts. For others, here's the canonical link:
<https://github.com/Genymobile/scrcpy>

I mostly post to Windows, which won't be of use to you, but what you
disdain is presumably when I sometimes offer cross-platform advice to all.

Your Linux-to-Fire-TV control pipeline sounds well-designed, and it's good
to know scrcpy behaves reliably even when forwarded over X11. That's a nice
way to validate the slideshow without needing direct access to the device.

I presume what you're doing is running ADB and scrcpy directly on the Linux
box that controls the Fire TV. In that setup, the Fire TV exposes its ADB interface over TCP (typically on port 5555), so the Linux machine can
connect to it with a straightforward adb connect <fire-tv-ip>:5555 without going through Android's newer "Wireless debugging" pairing workflow. Once connected, you launch scrcpy on the Linux box, which mirrors the Fire TV's display into an X11 window generated on that machine.

From your own workstation, you then SSH into the Linux box using X11
forwarding (ssh -X), which causes the scrcpy GUI window to be rendered
locally even though the program is executing remotely. That means the Linux
box handles all ADB communication with the Fire TV, while your local
machine simply displays the forwarded scrcpy window. Presumably this allows
you to visually verify the signage slideshow running on the Fire TV without needing physical access to the display or running scrcpy on your own
system. .
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

....winston wrote:

Be confident in your content, regardless of the feedback especially when
few reply on its value.
- for a better assessment of what's been read, a blog might prove more visits, then just a simple link to the blog article would/could be appropriate for nntp users.

Thanks. I won't respond further unless someone comments on the script.

You're correct that I should go ot the trouble of setting up a blog.

But I don't know how to do that...
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris <ithinkiam@gmail.com> wrote:

In a former life, I also contributed to the codebase of a linux
distribution. Anonymously <gasp>!

This is why *I* know what *I* am talking about.

Now, back to *you*. What help do *you* need to do things properly?

<crickets>

And, he's gone....

As per usual "the Donald" is only interested in sycophancy or animosity.

When an offer for help and advice is made he disengages and runs away.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-06-16 22:51, Maria Sophia wrote:

Carlos E. R. wrote:

Given I've posted, oh, I don't know, hundreds of useful scripts...
Q: What specific web site do you suggest I post the final script to?

Up to you, and it wasn't my idea, anyway :-)

I have never done this, so I can not advise

You could use github, or hire a server of your own somewhere. Or set up
a server at home. Sourceforge, perhaps (this one I have used).

The point of the rhetorical question is that it likely doesn't exist.

Oh, yes, they do exist. Many. But you will not like any of them, as they
serve to find you.

Only Usenet will allow me to post the code sans creating a login/account.

So Chris is asking me to do that which nobody can do, as far as we know.

Anybody can do it, and we do. YOU, only you, can not. :-P
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. wrote on 6/17/2026 5:45 PM:

On 2026-06-16 22:51, Maria Sophia wrote:

Carlos E. R. wrote:

Given I've posted, oh, I don't know, hundreds of useful scripts...
Q: What specific web site do you suggest I post the final script to?

Up to you, and it wasn't my idea, anyway :-)

I have never done this, so I can not advise

You could use github, or hire a server of your own somewhere. Or set up
a server at home. Sourceforge, perhaps (this one I have used).

The point of the rhetorical question is that it likely doesn't exist.

Oh, yes, they do exist. Many. But you will not like any of them, as they serve to find you.

Only Usenet will allow me to post the code sans creating a login/account.

So Chris is asking me to do that which nobody can do, as far as we know.

Anybody can do it, and we do. YOU, only you, can not. :-P

Be gentle here. Mary Sophe is probably a secret agent, and cannot use
any normal method to distribute her wonderful tutorials.

It's obviously a secret underground thing. And she faces much danger
with every tutorial posted.

I admit, it is damn STRANGE. And I've not yet seen anything of much
"value". Perhaps she is holding back the good stuff?


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-06-17 20:59, Chris wrote:

Chris <ithinkiam@gmail.com> wrote:

In a former life, I also contributed to the codebase of a linux
distribution. Anonymously <gasp>!

This is why *I* know what *I* am talking about.

Now, back to *you*. What help do *you* need to do things properly?

<crickets>

And, he's gone....

Maybe he only reads alt.os.linux, which you removed. :-?

As per usual "the Donald" is only interested in sycophancy or animosity.

When an offer for help and advice is made he disengages and runs away.

--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

[resetting follow-ups]

Maria Sophia <mariasophia@comprehension.com> wrote:

Chris wrote:

What help do *you* need to do things properly?

Find me the web site you claim exists where I can post the tutorials,
PSAs & scripts for others to benefit from that has no account login.

Why? You've already stated you're happy to submit to fora which require a login. You're intentionally being awkward simply for the sake of it.

There are plenty of pastebin-like solutions, which are one-off links. https://www.geeksforgeeks.org/blogs/top-7-code-sharing-website-for-developers/

However, a more sensible solution is to include some of version control
given you're regularly changing your "tutorials" and it makes sense to
always point to the most recent (and most correct) version.

The model these days revolves around git-like functionality. The de facto standard is github, but there are many others like gitlab, bitbucket,
gitea, sourceforge, etc.
https://opensource.com/article/18/8/github-alternatives

All will need some form of login, but you probably can use throwaway logins
or just create multiple for different types of scripts. All unnecessary as thousands of people are able to remain totally anonymous while maintaining longterm histories on github and developing credibility.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. <robin_listas@es.invalid> wrote:

On 2026-06-17 20:59, Chris wrote:

Chris <ithinkiam@gmail.com> wrote:

In a former life, I also contributed to the codebase of a linux
distribution. Anonymously <gasp>!

This is why *I* know what *I* am talking about.

Now, back to *you*. What help do *you* need to do things properly?

<crickets>

And, he's gone....

Maybe he only reads alt.os.linux, which you removed. :-?

Turns out he removed the android ng and only replied in the Windows10 ng.
Odd?




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

Maybe he only reads alt.os.linux, which you removed. :-?

Turns out he removed the android ng and only replied in the Windows10 ng. Odd?

NOTE: I haven't been able to reply because of a news server issue...
(and paga says "forbidden crosspost" for these two groups
alt.comp.os.windows-10,comp.mobile.android
So I'll just post it to the Android newsgroup instead
since responding to Chris' wrongful insults adds no value anyway.

I appreciate that Carlos understood that Chris' accusations were unwarranted.

I generally do not remove groups, as I want my messages to be as useful to
as many as possible, so it's not likely that I was who removed the groups.

But I do appreciate that Chris will apologize now that he's found out that
I did reply, so all his politically motivated hatred was unwarranted.

While I was waiting for an apology from Chris for his incessant attacks,
I added a few more useful PSAs to help streamline desktop:android debug.

Newsgroups: comp.mobile.android,alt.comp.os.windows-10,alt.os.linux
Subject: PSA: How to capture Android crash logs or app errors & warnings on your desktop using adb & logcat
Date: Wed, 17 Jun 2026 01:13:00 -0500
Message-ID: <110tdtc$2qt$1@nnrp.usenet.blueworldhosting.com>

Newsgroups: comp.mobile.android
Subject: PSA: How to ID from the desktop what just made Android beep (using adb logcat)
Date: Wed, 17 Jun 2026 14:53:46 -0500
Message-ID: <110uu09$39vsm$1@paganini.bofh.team>
--
Some people can add value by building useful cross-platform tool suites.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-06-18 22:09, Maria Sophia wrote:

Chris wrote:

Maybe he only reads alt.os.linux, which you removed. :-?

Turns out he removed the android ng and only replied in the Windows10 ng.
Odd?

NOTE: I haven't been able to reply because of a news server issue...
(and paga says "forbidden crosspost" for these two groups
alt.comp.os.windows-10,comp.mobile.android
So I'll just post it to the Android newsgroup instead
since responding to Chris' wrongful insults adds no value anyway.

There have been no insults, Arlen. Criticism, yes.

...
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. wrote:

NOTE: I haven't been able to reply because of a news server issue...
(and paga says "forbidden crosspost" for these two groups
alt.comp.os.windows-10,comp.mobile.android
So I'll just post it to the Android newsgroup instead
since responding to Chris' wrongful insults adds no value anyway.

There have been no insults,

Hi Carlos,

While you ignore the incessant insults by Chris against me, and while it's
impossible for Chris (or anyone) to insult me, he never stops trying.

So I'm allowed to flag them.
Because Chris never stops hurling insults toward me every chance he gets.

Even when he's dead wrong.
And, he's never apologized even though he was dead wrong, as you know.

I'm extremely intelligent so when I say something, it is based on facts.
I don't bullshit as I call the shots the way they are and I provide proof.

1. Proof that they were insults are in Chris' own words.
2. Proof that my server is having a problem is in the admin response.
3. While Chris is hurling never-ending insults, I'm adding value to the ng.

REFERENCES:
1. Proof that they were insults are in Chris' own words, especially
as Chris constantly hurls his political insults even as this is
not a political newsgroup (and even when he's the one who is wrong).

From: Chris <ithinkiam@gmail.com>
Newsgroups: comp.mobile.android,alt.comp.os.windows-10
Subject: Re: PSA: Streamlined persistent ADB port over WirCaFi without repeated pairing
Date: Wed, 17 Jun 2026 18:59:27 -0000 (UTC)
Message-ID: <110uqqf$235pk$1@dont-email.me>

And, he's gone....
As per usual "the Donald" is only interested in sycophancy or animosity.
When an offer for help and advice is made he disengages and runs away.

2. Proof that my server is having a problem is in the admin response.
From: Jesse Rehmer <jesse.rehmer@blueworldhosting.com>
Newsgroups: alt.free.newsservers
Subject: Re: Anyone else getting errors posting to blueworld lately?
Date: Thu, 18 Jun 2026 21:18:39 -0000 (UTC)
Message-ID: <1111nbe$2t7m2$1@dont-email.me>

> I'm getting strange errors in the past two days.
> Anyone else?

I should have posted, but got swamped and forgot.
We'll be down for maintenance for a while longer.
New articles weren't making their way to the reader server
and I thought it was due to a corrupt history file, so it's
currently rebuilding the history file. (Though I later figured
out it was a strange issue with Diablo's queue files. Sigh.)

3. While Chris is hurling never-ending insults, I'm adding value to the ng.
Newsgroups: comp.mobile.android,alt.comp.os.windows-10,alt.os.linux
Subject: PSA: How to capture Android crash logs or app errors & warnings on your desktop using adb & logcat
Date: Wed, 17 Jun 2026 01:13:00 -0500
Message-ID: <110tdtc$2qt$1@nnrp.usenet.blueworldhosting.com>

Newsgroups: comp.mobile.android
Subject: PSA: How to ID from the desktop what just made Android beep (using adb logcat)
Date: Wed, 17 Jun 2026 14:53:46 -0500
Message-ID: <110uu09$39vsm$1@paganini.bofh.team>
--
Even kind-heartd people who help others have their limits with the trolls.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia <mariasophia@comprehension.com> wrote:

Carlos E. R. wrote:

NOTE: I haven't been able to reply because of a news server issue...
(and paga says "forbidden crosspost" for these two groups
alt.comp.os.windows-10,comp.mobile.android
So I'll just post it to the Android newsgroup instead
since responding to Chris' wrongful insults adds no value anyway.

There have been no insults,

Hi Carlos,

While you ignore the incessant insults by Chris against me

Like Carlos says, there have been no insults. Unlike you like to do by
calling people stupid.

You simply prefer to play victim rather than address genuine criticism or
take on valuable insight that doesn't align with your wrongheadedness.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

PSA:
Persistent ADB over Wi-Fi without repeated pairing of desktop to Android

UPDATE!
The debug port is a legacy step that ADB no longer strictly requires!

The latest adbconnect script has been working wonderfully, as the goal is always to reduce everything we do on any computer to a single quick step.

But... the strangest thing happened earlier today...
I found out that the debug port is a legacy port. It's not actually needed.

It was almost like when I found out that gravity isn't actually a force.
And that everything moves at the speed of light through curved spacetime.
So gravity is due to the curvature of time (mostly) & not to space curvature.

Yet, everyone (including me) always thought that gravity was a force.
And that it was due to the curvature of space (mostly) and less so of time.

It's not. And the adb connect step is also not needed either.
All we need is the adb pairing step.

How do I know this (without being a window washer falling off a roof)?

I ran adbconnect but I accidentally mistyped the debug port.
Yet the desktop still connected over Wi-Fi to adb and to scrcpy mirroring.

Huh?

Turns out, the debug port is ... um... er... optional.
Who knew. Not me. Now I do.

All we really need is:
a. Pair over Wi-Fi
b. Run adb tcpip 5555
c. Connect to 5555
d. Launch scrcpy

Pairing port = authentication
Debug port = optional first-connect helper

Once pairing succeeds, ADB has a trusted identity token for the device.

USB connection between phone & desktop:
a. Already trusted
b. No pairing needed
c. No debug port needed
d. We can immediately run adb tcpip 5555

Wi-Fi connection between phone & desktop:
a. We must pair
b. Pairing gives ADB the same trust token USB normally provides
c. After pairing, the debug port becomes optional
Because Wi-Fi pairing replaces the need for USB.
And once paired, the debug port becomes irrelevant.

The debug port is a legacy step that ADB no longer strictly requires.
Yet, when I commented out the debug port, the script logic unexpectedly
broke when re-launching scrcpy (when it was already running). Huh?

Turns out once paired, the PC is permanently authorized to connect to that phone over Wi-Fi, regardless of what port is used next (until rebooted).

In addition, I added logic to detect if scrcpy is already running & if so, to use the existing running connection instead of killing/restarting it.

:: adbconnect.bat (Automate Android-to-desktop Wi-Fi adb/scrcpy connections)
:: Solves two problems when connecting a desktop to adb/scrcpy for Android.
:: 1. Eliminate all useless random-security steps in a Wi-Fi adb connection
:: 2. Eliminate the useless scrcpy console window which just takes up space
:: v1p8 20260619
:: a. The debug port user-input query was removed
:: b. And the pairing to TCP/IP flow was simplified as a result
:: c. Plus, detection of scrcpy already running was added to prevent scrcpy
:: from respawning if it was already running when adbconnect is run.
:: Note: While Wi-Fi pairing replaces the need for the USB cable,
:: once paired, the Android debug port actually becomes irrelevant.
:: Once paired, even if the PC is rebooted, the PC is permanently authorized
:: to connect to that phone over Wi-Fi regardless of the debug port.
:: (ADB pairing only needs to be replenished after the phone has rebooted.)
:: v1p7 20260615
:: Removed the requirement for the "no-console" vbs script
:: by injecting the necessary commands into a temporary file
:: This is the cleanest way I can think of to eliminate the console.
:: v1p6 20260614
:: Called the vbs "no-console" script that comes with adb.
:: If the script isn't there, then it defaults to the old method.
:: The problem is getting completely rid of the scrcpy console isn't working.
:: These are the known scrcpy console-hiding methods:
:: (a) cmd /c start "" /min (minimizes the console)
:: The console is not hidden. It's just minimized.
:: (b) cmd start "" /B (background launch of detached console)
:: This detaches scrcpy from the batch console
:: (c) adb default VBS no-console wrapper (fully hidden window)
:: Default GUI-subsystem scrcpy launch (so no console is created)
:: CreateObject("Wscript.Shell").Run strCommand, 0, False
:: (d) Kleebauer ShowWindow() controller trick to hide the batch console
:: showwin.exe 0 SW_HIDE (Hides the batch console)
:: (e) Powershell ShowWindowAsync (similar idea to Herbert's ShowWindow()
:: Add-Type '[DllImport("user32.dll")]
:: public static extern bool
:: ShowWindowAsync(IntPtr hWnd, int nCmdShow);'
:: Here is the original scrcpy-noconsole.vbs that comes with adb
:: strCommand = "cmd /c scrcpy.exe"
:: For Each Arg In WScript.Arguments
:: strCommand = strCommand & " """ & replace(Arg, """", """""""""") & """"
:: Next
:: CreateObject("Wscript.Shell").Run strCommand, 0, false
:: v1p5 20260613 Added query asking for the LAN IP address of the phone
:: Reordered comments to allow the current version to be obvious
:: v1p4 20260612 minimized the scrcpy console (but it's still there)
:: using cmd /c start "" /min (minimizes the console only)
:: The only known choices are
:: (a) Minimized console-subsystem launch (cmd /c start "" /min)
:: (b) Background detached launch (start "" /B)
:: (c) Hidden GUI-subsystem VBS launcher (no console created)
:: (d) External ShowWindow() console-visibility controller (Kleebauer trick)
:: (e) PowerShell ShowWindowAsync console hider (similar to ShowWindow())
:: v1p3 20260612 moved the pipe outside the FOR command for reliability
:: v1p2 20260611 further reliability improvements added to v1p1
:: Use separate retry counters for pair/connect to avoid loop
:: interference (ATTEMPTS_PAIR, ATTEMPTS_CONN)
:: Added fail-fast with clear error codes and user hints after retry
:: exhaustion
:: Added a detection of the device id after initial connect
:: (handles ephemeral adb ports like 192.168.1.4:54321)
:: Use DEVICE_ID for subsequent -s tcpip command (quoted)
:: to avoid parsing issues with colons
:: Fallback device-id lookup when initial pattern match fails
:: (robust parsing of "adb devices")
:: Consistent quoting of %ADB% and device identifiers to avoid
:: CMD parsing errors
:: v1p1 20260611 reliability improvements added to v1p0
:: Added better device lookup (skip header,ignore blanks,avoid false matches)
:: Added retry logic for adb pair & adb connect (for when phone not ready)
:: Improved polish (consistent quoting, stable scrcpy launch)
:: v1p0 20260611 converted adbconnect.vbs to adbconnect.bat
:: Connects desktop & phone over adb & mirrors phone on the monitor
:: No USB cord is used in this process as it's all done over Wi-Fi
:: Should work even if either the PC and/or the phone is rebooted
:: The script will ask only for the minimum amount of data needed
:: Change the phone static IP address as needed to fit your LAN IP address

@echo off
setlocal enabledelayedexpansion
:: For phones with static IP addresses, change the next line
set PHONE_IP=192.168.1.4
set SCRCPY_OPTS=--keyboard=sdk --always-on-top

echo.
echo === ADB Wireless Auto-Connect ===
echo === [Developer options > Wireless debugging > on] ===
echo.

REM 1. Find adb
for /f "delims=" %%A in ('where adb 2^>nul') do (
if not defined ADB set ADB=%%A
)

if not defined ADB (
echo [ERROR] adb.exe not found.
exit /b
)

REM Ensure .exe extension
if /i not "%ADB:~-4%"==".exe" set ADB=%ADB%.exe

echo Using ADB: "%ADB%"
echo.

REM 2. Check if already connected
echo Checking existing ADB devices...

set DEVICE_ID=
for /f "skip=1 tokens=1" %%I in ('"%ADB%" devices') do (
echo %%I | findstr /R "[0-9]" >nul && (
echo %%I | findstr /I "%PHONE_IP%" >nul && (
if not defined DEVICE_ID set DEVICE_ID=%%I
)
)
)

if defined DEVICE_ID (
echo Already connected on %DEVICE_ID%
goto RUN_TCPIP
)

echo Not connected. Need to pair.
echo.

REM 3. Ask user for pairing info
echo Necessary pairing information will be shown on the phone:
set /p PHONE_IP=Phone IP [%PHONE_IP%] :
set /p PAIR_PORT=Wireless debugging pairing port :
set /p PAIR_CODE=Wireless debugging pairing code :

echo.
echo Pairing with: %PHONE_IP%:%PAIR_PORT%

REM Retry logic for adb pair (3 attempts)
set ATTEMPTS_PAIR=0
:PAIR_RETRY
set /a ATTEMPTS_PAIR+=1
"%ADB%" pair %PHONE_IP%:%PAIR_PORT% %PAIR_CODE%
if errorlevel 1 (
if !ATTEMPTS_PAIR! lss 3 (
echo Pair failed, retrying...
timeout /t 2 >nul
goto PAIR_RETRY
) else (
echo [ERROR] adb pair failed after %ATTEMPTS_PAIR% attempts.
echo Hint: Open Wireless debugging -> "Pair device with pairing code" on the phone, then re-run this script.
exit /b 1
)
)
echo.

:: NEW: Debug port removed in v1p8. Skip directly to TCP/IP mode.
echo Skipping obsolete debug-port connect step...
echo.

:: NEW: After pairing, ADB already trusts the device. Switch directly to TCP/IP.
echo Switching to TCP/IP 5555...
"%ADB%" tcpip 5555
echo.

echo Connecting final port: %PHONE_IP%:5555
"%ADB%" connect %PHONE_IP%:5555
echo.

set DEVICE_ID=%PHONE_IP%:5555
goto RUN_SCRCPY

:RUN_TCPIP
echo Switching device !DEVICE_ID! to TCP/IP 5555...
"%ADB%" -s "%DEVICE_ID%" tcpip 5555
"%ADB%" connect "%PHONE_IP%:5555"
goto RUN_SCRCPY

:RUN_SCRCPY
echo Launching scrcpy completely silent...

:: NEW: Check if scrcpy is already running to avoid killing visible session
tasklist | findstr /I "scrcpy.exe" >nul
if not errorlevel 1 (
echo scrcpy is already running. Skipping relaunch.
echo Done.
exit /b
)

set "VBS_TEMP=%TEMP%\scrcpy_runner.vbs"

:: Build the standalone VBS command string directly into the temp file
echo strCommand = "cmd /c scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%" > "%VBS_TEMP%"
echo CreateObject("Wscript.Shell").Run strCommand, 0, false >> "%VBS_TEMP%"

:: Execute the temporary VBS script
wscript.exe "%VBS_TEMP%"

:: Brief pause to ensure script allocation completes before cleaning up the temp file
timeout /t 1 >nul
if exist "%VBS_TEMP%" del "%VBS_TEMP%"

echo Done.
exit /b

REM end of adbconnect.bat
--
Posted out of the goodness of my heart to help others do what I do.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

The debug port is a legacy step that ADB no longer strictly requires!

Here's the Linux equivalent to the Windows script, but I did not test it.

#!/bin/sh
#
# adbconnect.sh
# Wi-Fi-only ADB + scrcpy auto-connect
# Linux bash version of adbconnect.bat
# v1p8 (20260619)
# Mirrors the Windows logic but adapted for Linux shell behavior.
# No debug port is used because adb pairing makes it unnecessary.
#

PHONE_IP="192.168.1.4"
SCRCPY_OPTS="--keyboard=sdk --always-on-top"

echo
echo "=== ADB Wireless Auto-Connect (Linux) ==="
echo "=== [Developer options > Wireless debugging > on] ==="
echo

# 1. Find adb
ADB="$(command -v adb)"

if [ -z "$ADB" ]; then
echo "[ERROR] adb not found in PATH."
exit 1
fi

echo "Using ADB: $ADB"
echo

# 2. Check if already connected
echo "Checking existing ADB devices..."

DEVICE_ID=""
# Skip header line and match only lines containing the phone IP
$ADB devices | tail -n +2 | while read -r line; do
echo "$line" | grep -q "$PHONE_IP" && DEVICE_ID="$(echo "$line" | awk '{print $1}')"
done

# If DEVICE_ID was found, skip pairing
if $ADB devices | grep -q "$PHONE_IP"; then
DEVICE_ID="$PHONE_IP:5555"
echo "Already connected on $DEVICE_ID"
echo "Switching device to TCP/IP 5555..."
$ADB -s "$DEVICE_ID" tcpip 5555
$ADB connect "$PHONE_IP:5555"
echo
# Jump to scrcpy section
else
echo "Not connected. Need to pair."
echo

echo "Necessary pairing information will be shown on the phone."
printf "Phone IP [%s]: " "$PHONE_IP"
read USER_IP
[ -n "$USER_IP" ] && PHONE_IP="$USER_IP"

printf "Wireless debugging pairing port: "
read PAIR_PORT

printf "Wireless debugging pairing code: "
read PAIR_CODE

echo
echo "Pairing with: $PHONE_IP:$PAIR_PORT"

ATTEMPTS_PAIR=0
while true; do
ATTEMPTS_PAIR=$((ATTEMPTS_PAIR + 1))
$ADB pair "$PHONE_IP:$PAIR_PORT" "$PAIR_CODE"
if [ $? -eq 0 ]; then
break
fi
if [ $ATTEMPTS_PAIR -ge 3 ]; then
echo "[ERROR] adb pair failed after $ATTEMPTS_PAIR attempts."
exit 1
fi
echo "Pair failed, retrying..."
sleep 2
done

echo
echo "Switching to TCP/IP 5555..."
$ADB tcpip 5555
echo

echo "Connecting final port: $PHONE_IP:5555"
$ADB connect "$PHONE_IP:5555"
echo

DEVICE_ID="$PHONE_IP:5555"
fi

# 3. Launch scrcpy
echo "Launching scrcpy..."

# NEW: Do not relaunch scrcpy if already running
if pgrep -x "scrcpy" >/dev/null; then
echo "scrcpy is already running. Skipping relaunch."
echo "Done."
exit 0
fi

# Linux scrcpy has no console window to hide, so just run it normally
scrcpy --tcpip="$PHONE_IP" $SCRCPY_OPTS >/dev/null 2>&1 &

echo "Done."
exit 0

# end of adbconnect.sh
--
Posted out of the goodness of my heart to help others do what I do.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

Turns out once paired, the PC is permanently authorized to connect
to that phone over Wi-Fi, regardless of what port is used next
(until the phone is rebooted).

The script is working perfectly to connect the desktop & phone
over Wi-Fi by asking for the bare-minimum connection information.

However... I noted a spurious warning in the output, which shows
up as an error but which is a warning due to the script logic.

After rebooting the desktop & the phone, running it in the morning

adbconnect

=== ADB Wireless Auto-Connect ===
Using ADB: "C:\app\editor\android\scrcpy\adb.exe"
Checking existing ADB devices...
* daemon not running; starting now at tcp:5037
* daemon started successfully
Not connected. Need to pair.
Necessary pairing information will be shown on the phone:
Phone IP [192.168.1.4] : <return>
Wireless debugging pairing port :45811
Wireless debugging pairing code :359070
Pairing with: 192.168.1.4:45811
Successfully paired to 192.168.1.4:45811 [guid=adb-SERIAL-GUID]
Skipping obsolete debug-port connect step...
Switching to TCP/IP 5555...
error: no devices/emulators found <============huh???
Connecting final port: 192.168.1.4:5555
connected to 192.168.1.4:5555
Launching scrcpy completely silent...
Done.

The updated version below eliminates the adb tcpip 5555 step because
wireless debugging already runs ADB over port 5555 internally anyway.

While I was improving the logic, I removed extraneous connection steps.

:: adbconnect.bat (Automate Android-to-desktop Wi-Fi adb/scrcpy connections)
:: Solves two problems when connecting a desktop to adb/scrcpy for Android.
:: 1. Eliminate all useless random-security steps in a Wi-Fi adb connection
:: 2. Eliminate the useless scrcpy console window which just takes up space
:: v1p9 20260620
:: Added logic to avoid unnecessary reconnect attempts
:: While v1p8 was working flawlessly, an extraneous error showed up:
:: Checking existing ADB devices...
:: * daemon not running; starting now at tcp:5037
:: * daemon started successfully
:: Not connected. Need to pair.
:: Necessary pairing information will be shown on the phone:
:: Phone IP [192.168.1.4] :
:: Wireless debugging pairing port :45811
:: Wireless debugging pairing code :359070
:: Pairing with: 192.168.1.4:45811
:: Successfully paired to 192.168.1.4:45811 [guid=adb-SERIAL-GUID]
:: Skipping obsolete debug-port connect step...
:: Switching to TCP/IP 5555...
:: error: no devices/emulators found
:: Connecting final port: 192.168.1.4:5555
:: connected to 192.168.1.4:5555
:: Launching scrcpy completely silent...
:: Done.
:: This version skips the adb tcpip 5555 step entirely when using
:: wireless debugging pairing because wireless debugging already
:: runs ADB over port 5555 internally so we do not need to switch modes.
:: v1p8 20260619
:: a. The debug port user-input query was removed
:: b. And the pairing to TCP/IP flow was simplified as a result
:: c. Plus, detection of scrcpy already running was added to prevent scrcpy
:: from respawning if it was already running when adbconnect is run.
:: Note: While Wi-Fi pairing replaces the need for the USB cable,
:: once paired, the Android debug port actually becomes irrelevant.
:: Once paired, even if the PC is rebooted, the PC is permanently authorized
:: to connect to that phone over Wi-Fi regardless of the debug port.
:: (ADB pairing only needs to be replenished after the phone has rebooted.)
:: v1p7 20260615
:: Removed the requirement for the "no-console" vbs script
:: by injecting the necessary commands into a temporary file
:: This is the cleanest way I can think of to eliminate the console.
:: v1p6 20260614
:: Called the vbs "no-console" script that comes with adb.
:: If the script isn't there, then it defaults to the old method.
:: The problem is getting completely rid of the scrcpy console isn't working.
:: These are the known scrcpy console-hiding methods:
:: (a) cmd /c start "" /min (minimizes the console)
:: The console is not hidden. It's just minimized.
:: (b) cmd start "" /B (background launch of detached console)
:: This detaches scrcpy from the batch console
:: (c) adb default VBS no-console wrapper (fully hidden window)
:: Default GUI-subsystem scrcpy launch (so no console is created)
:: CreateObject("Wscript.Shell").Run strCommand, 0, False
:: (d) Kleebauer ShowWindow() controller trick to hide the batch console
:: showwin.exe 0 SW_HIDE (Hides the batch console)
:: (e) Powershell ShowWindowAsync (similar idea to Herbert's ShowWindow()
:: Add-Type '[DllImport("user32.dll")]
:: public static extern bool
:: ShowWindowAsync(IntPtr hWnd, int nCmdShow);'
:: Here is the original scrcpy-noconsole.vbs that comes with adb
:: strCommand = "cmd /c scrcpy.exe"
:: For Each Arg In WScript.Arguments
:: strCommand = strCommand & " """ & replace(Arg, """", """""""""") & """"
:: Next
:: CreateObject("Wscript.Shell").Run strCommand, 0, false
:: v1p5 20260613 Added query asking for the LAN IP address of the phone
:: Reordered comments to allow the current version to be obvious
:: v1p4 20260612 minimized the scrcpy console (but it's still there)
:: using cmd /c start "" /min (minimizes the console only)
:: The only known choices are
:: (a) Minimized console-subsystem launch (cmd /c start "" /min)
:: (b) Background detached launch (start "" /B)
:: (c) Hidden GUI-subsystem VBS launcher (no console created)
:: (d) External ShowWindow() console-visibility controller (Kleebauer trick)
:: (e) PowerShell ShowWindowAsync console hider (similar to ShowWindow())
:: v1p3 20260612 moved the pipe outside the FOR command for reliability
:: v1p2 20260611 further reliability improvements added to v1p1
:: Use separate retry counters for pair/connect to avoid loop
:: interference (ATTEMPTS_PAIR, ATTEMPTS_CONN)
:: Added fail-fast with clear error codes and user hints after retry
:: exhaustion
:: Added a detection of the device id after initial connect
:: (handles ephemeral adb ports like 192.168.1.4:54321)
:: Use DEVICE_ID for subsequent -s tcpip command (quoted)
:: to avoid parsing issues with colons
:: Fallback device-id lookup when initial pattern match fails
:: (robust parsing of "adb devices")
:: Consistent quoting of %ADB% and device identifiers to avoid
:: CMD parsing errors
:: v1p1 20260611 reliability improvements added to v1p0
:: Added better device lookup (skip header,ignore blanks,avoid false matches)
:: Added retry logic for adb pair & adb connect (for when phone not ready)
:: Improved polish (consistent quoting, stable scrcpy launch)
:: v1p0 20260611 converted adbconnect.vbs to adbconnect.bat
:: Connects desktop & phone over adb & mirrors phone on the monitor
:: No USB cord is used in this process as it's all done over Wi-Fi
:: Should work even if either the PC and/or the phone is rebooted
:: The script will ask only for the minimum amount of data needed
:: Change the phone static IP address as needed to fit your LAN IP address

@echo off
setlocal enabledelayedexpansion
:: For phones with static IP addresses, change the next line
set PHONE_IP=192.168.1.4
set SCRCPY_OPTS=--keyboard=sdk --always-on-top

echo.
echo === ADB Wireless Auto-Connect ===
echo === [Developer options > Wireless debugging > on] ===
echo.

REM 1. Find adb
for /f "delims=" %%A in ('where adb 2^>nul') do (
if not defined ADB set ADB=%%A
)

if not defined ADB (
echo [ERROR] adb.exe not found.
exit /b
)

REM Ensure .exe extension
if /i not "%ADB:~-4%"==".exe" set ADB=%ADB%.exe

echo Using ADB: "%ADB%"
echo.

REM 2. Check if already connected
echo Checking existing ADB devices...

set DEVICE_ID=
for /f "skip=1 tokens=1" %%I in ('"%ADB%" devices') do (
echo %%I | findstr /R "[0-9]" >nul && (
echo %%I | findstr /I "%PHONE_IP%" >nul && (
if not defined DEVICE_ID set DEVICE_ID=%%I
)
)
)

if defined DEVICE_ID (
echo Already connected on %DEVICE_ID%
goto RUN_TCPIP
)

echo Not connected. Need to pair.
echo.

REM 3. Ask user for pairing info
echo Necessary pairing information will be shown on the phone:
set /p PHONE_IP=Phone IP [%PHONE_IP%] :
set /p PAIR_PORT=Wireless debugging pairing port :
set /p PAIR_CODE=Wireless debugging pairing code :

echo.
echo Pairing with: %PHONE_IP%:%PAIR_PORT%

REM Retry logic for adb pair (3 attempts)
set ATTEMPTS_PAIR=0
:PAIR_RETRY
set /a ATTEMPTS_PAIR+=1
"%ADB%" pair %PHONE_IP%:%PAIR_PORT% %PAIR_CODE%
if errorlevel 1 (
if !ATTEMPTS_PAIR! lss 3 (
echo Pair failed, retrying...
timeout /t 2 >nul
goto PAIR_RETRY
) else (
echo [ERROR] adb pair failed after %ATTEMPTS_PAIR% attempts.
echo Hint: Open Wireless debugging -> "Pair device with pairing code" on the phone, then re-run this script.
exit /b 1
)
)
echo.

:: NEW: Debug port removed in v1p8. Skip directly to TCP/IP mode.
echo Skipping obsolete debug-port connect step...
echo.

:: NEW: After pairing, ADB already trusts the device. Switch directly to TCP/IP.
:: Removed in v1p9
:: echo Switching to TCP/IP 5555...
:: "%ADB%" tcpip 5555
:: Added in v1p9 After pairing, ADB already trusts the device.
:: No tcpip mode is needed.

echo Wireless debugging active. Skipping tcpip 5555 step...
echo.

:: Added this already-connected check in v1p9
:: Check if device is already connected wirelessly
for /f "skip=1 tokens=1" %%I in ('"%ADB%" devices"') do (
echo %%I | findstr /I "%PHONE_IP%" >nul && (
echo Already connected wirelessly on %%I
set DEVICE_ID=%%I
goto RUN_SCRCPY
)
)

echo Connecting final port: %PHONE_IP%:5555
"%ADB%" connect %PHONE_IP%:5555
echo.

set DEVICE_ID=%PHONE_IP%:5555
goto RUN_SCRCPY

:: This secion only applies to USB debugging, not wireless debugging.
:RUN_TCPIP
echo Switching device !DEVICE_ID! to TCP/IP 5555...
"%ADB%" -s "%DEVICE_ID%" tcpip 5555
"%ADB%" connect "%PHONE_IP%:5555"
goto RUN_SCRCPY

:RUN_SCRCPY
echo Launching scrcpy completely silent...

:: NEW: Check if scrcpy is already running to avoid killing visible session
tasklist | findstr /I "scrcpy.exe" >nul
if not errorlevel 1 (
echo scrcpy is already running. Skipping relaunch.
echo Done.
exit /b
)

set "VBS_TEMP=%TEMP%\scrcpy_runner.vbs"

:: Build the standalone VBS command string directly into the temp file
echo strCommand = "cmd /c scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%" > "%VBS_TEMP%"
echo CreateObject("Wscript.Shell").Run strCommand, 0, false >> "%VBS_TEMP%"

:: Execute the temporary VBS script
wscript.exe "%VBS_TEMP%"

:: Brief pause to ensure script allocation completes before cleaning up the temp file
timeout /t 1 >nul
if exist "%VBS_TEMP%" del "%VBS_TEMP%"

echo Done.
exit /b

REM end of adbconnect.bat
--
Usenet is where kind people daily gather to voluntarily help others.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

To further leverage the effort, I posted the latest adbconnect to XDA
<https://xdaforums.com/t/this-adbconnect-script-connects-android-to-the-windows-linux-macos-desktop-laptop-in-a-single-step-over-wi-fi-without-using-usb-allowing-reconnect.4792987/>

For tactical reasons, the title is keyword rich so it shows up in searches.
*This adbconnect script connects Android to the (Windows/Linux/macOS)*
*desktop/laptop in a single step over Wi-Fi without using USB*
*(allowing reconnect)*

I'll add the Linux/macOS scripts separately there so all can benefit.
--
Usenet isn't for amusement; it's for learning from and teaching each other.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

UPDATE!
Things have drastically changed for the better! Ports are not needed!

Aurgh. I just found out, by accident, that Android 12+ introduced a *new*
way to connect to adb over Wi-Fi that does not need pairing or debug ports.

So the previous script will work to connect over the LAN for Android 11+,
but this works on Android 12+ because of the new TLS design, which...
a. bypasses pairing
b. bypasses USB authorization
c. bypasses debug ports
d. auto-connects whenever ADB restarts

Android added a second Wi-Fi ADB system called ADB-over-TLS Auto-Discovery.
It is fundamentally completely different from classic Wireless Debugging.

What's DIFFERENT is Wi-Fi ADB-over-TLS Auto-Discovery works even when
a. USB is dead
b. We never paired
c. No pairing code appears
d. No debug ports are open
e. Wireless Debugging toggle is OFF or ON
f. We never authorized the desktop PC

When the desktop PC's ADB server starts, it automatically:
a. Scans the LAN for TLS ADB devices
b. Finds the phone (if the phone's broadcast is awake)
c. Connects with no pairing
d. Shows it as:
adb-SERIAL-GUID._adb-tls-connect._tcp device

This TLS connection:
a. uses encrypted channels
b. uses dynamic ports (which we do not need to know)
c. requires no pairing
d. requires no USB authorization
e. works even if Wireless Debugging toggle is OFF after reboot

Even though ADB shows the TLS device as "device", scrcpy will fail unless
the connection is converted to TCP/IP mode because scrcpy only supports
a. USB
b. Classic TCP/IP ADB (port 5555)

While scrcpy cannot use this TLS device directly, scrcpy *can* use it indirectly by switching it to classic TCP/IP mode (port 5555).

The simple solution is to convert TLS to TCP/IP (port 5555):
adb -s adb-SERIAL-GUID._adb-tls-connect._tcp tcpip 5555

This forces Android to:
a. drop the TLS session
b. start the classic ADB-over-WiFi daemon
c. open port 5555
d. stay reachable on 5555 until the PHONE reboots

Then this simple sequence works every time:
adb connect PHONE_IP:5555
scrcpy --tcpip=PHONE_IP

The caveat is that the TLS ADB service is flaky. It can:
a. go idle
b. stop advertising
c. come back as "offline"
d. restart only when Wireless Debugging is toggled OFF -> ON

We can write a launcher to avoid this TLS flakiness by:
a. killing the PC ADB server
b. disconnecting all devices
c. reconnecting only to 5555
This removes the TLS ghost device entirely.

Below is the first rev of a vbs script for Windows 10 (Linux can be added later) which connects without USB and without knowing any pairing ports!

:: adbconnecttls.bat
:: Connects Android 12+ to adb & scrcpy WITHOUT needing any information!
:: v1p0 (Android 12+ TLS-to-TCPIP scrcpy launcher)
:: Simplest possible Wi-Fi scrcpy launcher for Android 12+ devices that
:: auto-advertise ADB-over-TLS. This script avoids pairing, avoids USB,
:: avoids debug ports, and avoids the TLS "ghost device" problem.
:: Android 12+ added a new ADB system called ADB-over-TLS Auto-Discovery.
:: It broadcasts on the LAN using mDNS as:
:: _adb-tls-connect._tcp
:: The desktop ADB server auto-connects to this TLS service with:
:: adb-SERIAL-GUID._adb-tls-connect._tcp
:: This TLS connection:
:: a. bypasses pairing
:: b. bypasses USB authorization
:: c. bypasses debug ports
:: d. auto-connects whenever ADB restarts
:: BUT scrcpy cannot use TLS directly. It only supports:
:: a. USB
:: b. Classic TCP/IP ADB (port 5555)
:: Note this script has no need for pairing or debug ports.
:: This script does not require USB nor does it depend on TLS being awake.
:: But Android's TLS ADB service is rather flaky in that it can:
:: a. go idle
:: b. stop advertising
:: c. return as "offline"
:: d. require Wireless Debugging toggle OFF->ON to wake up
:: So this script avoids TLS entirely by connecting only to port 5555.
:: This script:
:: 1. Kills the ADB server (removes stale TLS sessions)
:: 2. Starts the ADB server cleanly
:: 3. Disconnects all devices (removes TLS ghost device)
:: 4. Connects directly to PHONE_IP:5555
:: 5. Launches scrcpy silently using classic TCP/IP mode
:: Running "adb -s <tls-id> tcpip 5555" forces Android to open port 5555
:: even when Wireless Debugging is ON. Once opened, port 5555 stays active
:: until the PHONE reboots. This makes reconnections simple and stable.

@echo off
setlocal enabledelayedexpansion

echo ============================================
echo ADB-over-TLS to TCP/IP Launcher (Debug Mode)
echo ============================================
echo.

:: Set your phone IP here
set PHONE_IP=192.168.1.4
set SCRCPY_OPTS=--keyboard=sdk --always-on-top

echo STEP 1: adb kill-server
echo adb kill-server
adb kill-server
echo.

echo STEP 2: adb start-server
echo adb start-server
adb start-server
echo.

echo STEP 3: adb disconnect (kills TLS ghost)
echo adb disconnect
adb disconnect
echo.

echo STEP 4: adb connect %PHONE_IP%:5555
echo adb connect %PHONE_IP%:5555
adb connect %PHONE_IP%:5555
echo.

echo STEP 5: Launch scrcpy silently
set VBS_TEMP=%TEMP%\scrcpy_tls_runner.vbs

echo strCommand = "cmd /c scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%" > "%VBS_TEMP%"
echo CreateObject("Wscript.Shell").Run strCommand, 0, false >> "%VBS_TEMP%"

echo Running: scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%
wscript.exe "%VBS_TEMP%"

echo.
echo Done.
echo.

endlocal
exit /b

:: end of adbconnecttls.bat
--
Usenet isn't for amusement; it's for learning from and teaching each other.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 27/06/2026 13:58, Maria Sophia wrote:

Things have drastically changed for the better! Ports are not needed!

Does this mean that Israel won't require the ports of Haifa and Ashdod?
Could you please explain?

It seems that Israel wasted money on creating a new port at Ashdod in
1965. They could just use Android phones to transport cargo and run
their economy.






--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Nadia Jarvis wrote on 6/27/2026 1:38 PM:

On 27/06/2026 13:58, Maria Sophia wrote:

Things have drastically changed for the better! Ports are not needed!

Does this mean that Israel won't require the ports of Haifa and Ashdod?
Could you please explain?

It seems that Israel wasted money on creating a new port at Ashdod in
1965. They could just use Android phones to transport cargo and run
their economy.

Be patient. Mary will fix all the ports for the poor long suffering
jews. Maybe she will even give them some money to make them happy.



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Hank Rogers wrote:

fix all the ports

Good news.
Thanks to the advice in this ng, I've removed all the ports completely.

There's now no need to look at the Wireless debugging ports ever again!

I'm overjoyed with the poorly documented new Android 12+ ability to connect
the phone to adb/scrcpy over Wi-Fi without needing to know any ports!

This may be the best documention on the planet for that, for all I know!

Below is a debug script to help others figure out their adb daemon status.
adbdebugtls.bat (Linux/macOS will come later, after full testing is done)

This reports adb daemon status on the phone:
$ adb devices
a. device -> ADB daemon is alive and authenticated
b. offline -> ADB daemon is alive but handshake failed
c. unauthorized -> ADB daemon alive but waiting for authorization
d. (empty) -> ADB daemon is asleep or not advertising
e. adb-SERIAL._adb-tls-connect._tcp -> TLS advertiser is awake
f. 192.168.x.x:5555 -> classic TCP/IP daemon is awake

This gives internal daemon state for reachable devices:
$ adb shell getprop init.svc.adbd
a. running -> ADB daemon is active
b. stopped -> daemon is not running
c. restarting -> daemon is restarting (rare)

This checks whether Android 12+ TCP mode is active:
$ adb shell getprop service.adb.tcp.port
a. 5555 -> classic TCP/IP mode active
b. -1 or empty -> TCP mode off

This checks whether ADB is enabled:
$ adb shell getprop ro.adb.secure
a. 1 -> secure ADB enabled
b. 0 -> insecure ADB (rare on modern devices )

This checks whether the Android 12+ TLS advertiser is awake:
$ adb mdns services
adb-SERIAL-GUID._adb-tls-connect._tcp
a. Entry present -> TLS daemon is awake
b. Entry missing -> TLS daemon is asleep
c. Entry present but adb devices empty -> TLS handshake failed
Note that is the most important check as it often falls asleep!

This tests whether the classic TCP/IP daemon is alive:
$ adb connect 192.168.1.4:5555
a. connected -> TCP daemon alive
b. unable to connect -> TCP daemon not running
c. no route to host -> phone not on LAN
d. connection refused -> port 5555 closed

Here's a manual test of the commands while Android 12+ is connected.
C:\> adbconnecttls.bat
============================================
ADB-over-TLS to TCP/IP Launcher (Debug Mode)
============================================

STEP 1: adb kill-server
adb kill-server

STEP 2: adb start-server
adb start-server
* daemon not running; starting now at tcp:5037
* daemon started successfully

STEP 3: adb disconnect (kills TLS ghost)
adb disconnect
disconnected everything

STEP 4: adb connect 192.168.1.4:5555
adb connect 192.168.1.4:5555
connected to 192.168.1.4:5555

STEP 5: Launch scrcpy silently
Running: scrcpy.exe --tcpip=192.168.1.4 --keyboard=sdk

Done.

C:\> adb devices
List of devices attached
192.168.1.4:5555 device

C:\> adb shell getprop init.svc.adbd
running

C:\> adb shell getprop service.adb.tcp.port
5555

C:\> adb shell getprop ro.adb.secure
1

C:\> adb mdns services
List of discovered mdns services
adb-SERIAL_adb._tcp 192.168.1.4:5555
adb-SERIAL-GUID_adb-tls-connect._tcp 192.168.1.4:36401

Note that the TLS advertiser (_adb-tls-connect._tcp) is part of:
com.android.adb.adbd
Which is flaky because this service goes idle on the phone when:
a. Wireless Debugging hasn't been toggled recently
b. The phone has been idle
c. The system kills the advertiser to save power
d. The ADB daemon restarts internally
e. Wi-Fi reconnects
f. The phone roams between APs

When the TLS advertiser sleeps, adb mdns services returns nothing.
When that happens there are 3 reliable ways to wake the TLS advertiser:
a. Toggle Wireless Debugging OFF -> ON
b. Restart the ADB daemon on the phone
That works only if you already have a connection (USB or TCP)
c. Force ADB to reconnect via TCP/IP

This is the trick the adbconnecttls.bat launcher uses:
i. adb kill-server
ii. adb start-server
iii. adb disconnect
iv. adb connect PHONE_IP:5555
That does not wake TLS because it bypasses TLS entirely
which is done because scrcpy can't use TLS as far as I know.

This script below provides ADB-over-TLS, TCP/IP mode diagnostics
including adbd state, Wireless Debugging state & scrcpy readiness.

@echo off
setlocal enabledelayedexpansion

:: adbdebugtls.bat (Android 12+ ADB/TLS Diagnostic Tool)
:: Runs a full diagnostic of ADB-over-TLS, TCP/IP mode, adbd state,
:: Wireless Debugging state, and scrcpy readiness for Android 12+.
::
:: v1p0 20260627
:: Diagnose the state of Android's ADB daemon on Android 12+ devices,
:: including TLS advertiser status, TCP/IP mode, adbd internal state,
:: Wireless Debugging service state and scrcpy readiness.
::
:: Android 12+ introduced ADB-over-TLS Auto-Discovery, which broadcasts
:: on the LAN using mDNS as:
:: _adb-tls-connect._tcp
:: The desktop ADB server auto-connects to this TLS service as:
:: adb-SERIAL._adb-tls-connect._tcp
:: This TLS system:
:: a. bypasses pairing
:: b. bypasses USB authorization
:: c. bypasses debug ports
:: d. auto-connects whenever ADB restarts
:: But scrcpy cannot use TLS directly. It only supports:
:: a. USB
:: b. Classic TCP/IP ADB (port 5555)
:: Hence, this script checks:
:: 1. TLS advertiser status (adb mdns services)
:: 2. TCP/IP connectivity on port 5555
:: 3. adbd internal state via getprop
:: 4. Wireless Debugging service state via dumpsys
:: Note Samsung may hide or rename the Wireless Debugging service.
:: 5. scrcpy readiness (device state)
:: Note the wake attempts when the phone TLS service goes asleep.
:: i. Restarting the PC ADB server
:: ii. Restarting adbd on the phone (if reachable)
:: iii. Forcing TCP/IP fallback on port 5555
:: Note Android does not expose a command to toggle Wireless Debugging.
:: So the TLS advertiser cannot be automaticaly awakened from ADB.
:: Hence, this script reports TLS sleep but cannot force it awake.
::
echo ============================================
echo ADB Debug Tool (Android 12+ TLS Diagnostic)
echo ============================================
echo.

:: Set your phone IP here
set PHONE_IP=192.168.1.4

echo.
echo === 1. Restart PC ADB Server ===
echo adb kill-server
adb kill-server
echo adb start-server
adb start-server
echo.

echo.
echo === 2. TLS Status (mDNS Advertiser) ===
echo Command: adb mdns services
adb mdns services | findstr /I "_adb-tls-connect._tcp"
if errorlevel 1 (
echo TLS advertiser is asleep or not broadcasting.
) else (
echo TLS advertiser is active.
)
echo.

echo.
echo === 3. TCP/IP Status (Port 5555) ===
echo Command: adb connect %PHONE_IP%:5555
adb connect %PHONE_IP%:5555
echo.

echo Command: adb devices
adb devices
echo.

echo.
echo === 4. Attempting to Wake adbd (if reachable) ===
echo Trying: adb shell stop adbd
adb shell stop adbd 2>nul
echo Trying: adb shell start adbd
adb shell start adbd 2>nul
echo.

echo.
echo === 5. adbd Internal State ===
echo Command: adb shell getprop init.svc.adbd
adb shell getprop init.svc.adbd
echo.

echo Command: adb shell getprop service.adb.tcp.port
adb shell getprop service.adb.tcp.port
echo.

echo Command: adb shell getprop ro.adb.secure
adb shell getprop ro.adb.secure
echo.

echo.
echo === 6. Wireless Debugging State ===
echo Command: adb shell dumpsys activity service ^
com.android.adb.adbd
adb shell dumpsys activity service com.android.adb.adbd
echo.

echo.
echo === 7. scrcpy Readiness Check ===
echo If device shows as "device", scrcpy can run.
echo If port 5555 is active, scrcpy --tcpip works.
echo.

echo Command: adb devices
adb devices
echo.

echo ============================================
echo Diagnostics complete.
echo ============================================

endlocal
exit /b

:: end of adbdebugtls.bat
--
Usenet isn't for amusement - it allows intelligent people to share ideas.
Some invest seconds to post stupid jokes but it takes hours to add value.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

In the beginning, I used USB to connect adb & scrcpy to the desktop PC.
Then in Android 11 I used Wi-Fi pairing with the pairing & debug port.
In Android 12, the ability to pair without knowing the ports was added.

In using the script to pair without knowing the ports, I've run into a bunch of situations depending on the state of the phone & the computer.

Hopefully I've added everything possible to this latest script for you.
Note it doesn't use TLS, per se, but TLS controls adb's reachability.

:: adbconnecttls.bat
:: Connects Android 12+ to adb & scrcpy WITHOUT needing any information!
::
:: This script launches scrcpy over classic TCPIP mode on Android 12
:: and newer devices. It does not use TLS for the scrcpy connection,
:: but it depends on the Wireless Debugging TLS service being awake
:: because TLS controls whether adbd is reachable. The script resets
:: the ADB server, removes stale TLS ghost sessions, checks TLS
:: advertiser state, tests TCPIP reachability, verifies USB debugging
:: authorization and attempts a direct connection to port 5555. It
:: then launches scrcpy silently and detects whether the connection
:: succeeded. If TLS is asleep, TCPIP is active but refusing
:: connections, USB debugging is authorized and scrcpy fails, the
:: script reports that the phone is in ADB Deep Sleep and instructs
:: the user to toggle Wireless debugging or reboot the phone to wake
:: adbd.
::
:: v1p4 20260630
:: Added deep sleep detector
::
:: v1p3 20260630
:: Added TCP/IP sleep detector and USB authorization detector
::
:: v1p2 20260630
:: Added detection and reporting if scrcpy didn't launch
::
:: v1p1 20260630
:: Added version string
:: Added TLS sleep detection
:: Added user guidance when TLS is asleep
:: Removed parentheses and arrows from comments
:: Cleaned formatting for stability
::
:: v1p0 20260601
:: Simplest possible Wi-Fi scrcpy launcher for Android 12+ devices that
:: auto-advertise ADB-over-TLS. This script avoids pairing, avoids USB,
:: avoids debug ports, and avoids the TLS "ghost device" problem.
:: Android 12+ added a new ADB system called ADB-over-TLS Auto-Discovery.
:: It broadcasts on the LAN using mDNS as:
:: _adb-tls-connect._tcp
:: The desktop ADB server auto-connects to this TLS service with:
:: adb-SERIAL-GUID._adb-tls-connect._tcp
:: This TLS connection:
:: a. bypasses pairing
:: b. bypasses USB authorization
:: c. bypasses debug ports
:: d. auto-connects whenever ADB restarts
:: BUT scrcpy cannot use TLS directly. It only supports:
:: a. USB
:: b. Classic TCP/IP ADB (port 5555)
:: Note this script has no need for pairing or debug ports.
:: This script does not require USB nor does it depend on TLS being awake.
:: But Android's TLS ADB service is rather flaky in that it can:
:: a. go idle
:: b. stop advertising
:: c. return as "offline"
:: d. require Wireless Debugging toggle OFF->ON to wake up
:: So this script avoids TLS entirely by connecting only to port 5555.
:: This script:
:: 1. Kills the ADB server (removes stale TLS sessions)
:: 2. Starts the ADB server cleanly
:: 3. Disconnects all devices (removes TLS ghost device)
:: 4. Connects directly to PHONE_IP:5555
:: 5. Launches scrcpy silently using classic TCP/IP mode
:: Running "adb -s <tls-id> tcpip 5555" forces Android to open port 5555
:: even when Wireless Debugging is ON. Once opened, port 5555 stays active
:: until the PHONE reboots. This makes reconnections simple and stable.

@echo off
setlocal enabledelayedexpansion

:: Version string
set SCRIPT_VERSION=v1p4
set SCRIPT_DATE=20260630

echo ============================================
echo ADB-over-TLS to TCPIP Launcher Debug Mode
echo Running adbconnecttls.bat %SCRIPT_VERSION% %SCRIPT_DATE%
echo ============================================
echo.

:: Set your phone IP here
set PHONE_IP=192.168.1.4
set SCRCPY_OPTS=--keyboard=sdk

echo STEP 1: adb kill-server
echo adb kill-server
adb kill-server
echo.

echo STEP 2: adb start-server
echo adb start-server
adb start-server
echo.

echo STEP 3: adb disconnect to remove TLS ghost
echo adb disconnect
adb disconnect
echo.

echo STEP 4: Check TLS advertiser status
echo Command: adb mdns services
adb mdns services | findstr /I "_adb-tls-connect._tcp" >nul

if errorlevel 1 (
echo.
echo TLS advertiser is ASLEEP.
echo Wireless Debugging is ON but the phone is not broadcasting TLS.
echo.
echo Meaning:
echo The phone cannot auto-connect over TLS.
echo The PC cannot wake the phone via TLS.
echo.
echo Fix:
echo On the phone, toggle Wireless debugging OFF then ON.
echo Or reboot the phone to restart Wireless Debugging.
echo.
echo After waking TLS, re-run adbconnecttls.bat.
echo.
) else (
echo TLS advertiser is ACTIVE.
echo The phone is broadcasting TLS normally.
)

echo.

echo STEP 5: adb connect %PHONE_IP%:5555
echo adb connect %PHONE_IP%:5555
adb connect %PHONE_IP%:5555
echo.

echo Checking TCPIP mode...
adb connect %PHONE_IP%:5555 >nul

:: Added TCP/IP sleep detector and USB authorization detector in v1p3
if errorlevel 1 (
echo.
echo TCPIP mode is ASLEEP.
echo The phone refused the TCPIP connection.
echo adbd is asleep or Wireless Debugging is asleep.
echo.
echo Fix:
echo On the phone, toggle Wireless debugging OFF then ON.
echo Or reboot the phone to restart Wireless Debugging.
echo.
echo After waking TLS, re-run adbconnecttls.bat.
echo.
) else (
echo TCPIP mode is ACTIVE.
)

echo Checking USB authorization...
adb devices | findstr /I "device" | findstr /V ":" >nul

if errorlevel 1 (
echo.
echo USB debugging is NOT authorized.
echo USB is connected but the phone is not authorized for ADB.
echo.
echo Fix:
echo Unlock the phone and press Allow USB debugging.
echo.
) else (
echo USB debugging is authorized.
)

echo STEP 6: Launch scrcpy silently
set VBS_TEMP=%TEMP%\scrcpy_tls_runner.vbs

echo strCommand = "cmd /c scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%" > "%VBS_TEMP%"
echo CreateObject("Wscript.Shell").Run strCommand, 0, false >> "%VBS_TEMP%"

echo Running: scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%
wscript.exe "%VBS_TEMP%"

:: Detect if scrcpy didn't launch and suggest a fix v1p2
echo Checking if scrcpy connected...
adb devices | findstr /I "%PHONE_IP%" >nul

if errorlevel 1 (
echo.
echo scrcpy did NOT connect.
echo.
echo Meaning:
echo The phone did not accept TCPIP connection.
echo adbd is asleep or Wireless Debugging is asleep.
echo.
echo Fix:
echo On the phone, toggle Wireless debugging OFF then ON.
echo Or reboot the phone to restart Wireless Debugging.
echo.
echo After waking TLS, re-run adbconnecttls.bat.
echo.
) else (
echo scrcpy connected successfully.
echo.
echo scrcpy is running over TCP/IP.
echo Connection successful.
echo.
goto :EOF
)

echo.
echo Done.
echo.

endlocal
exit /b

:: end of adbconnecttls.bat
--
For some people, Usenet is amusement, but for me, it's for adding value.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

In the beginning, we used USB to connect adb & scrcpy to the desktop PC.
Then in Android 11 we used Wi-Fi pairing with the pairing & debug port.
$ adbconnect.bat

I used that method even up to Android 13, but I didn't know that in
Android 12, the ability to pair without knowing the ports was added.
$ adbconnecttls.bat

In using that script to pair without knowing the ports, I've run into a
bunch of situations depending on the state of the phone & the computer.

Hence, I wrote this debugging-only script to catch all known errors.
As always, please fix where I accidentally omit or err for overall value.

:: adbdebugtls.bat (Android 12+ ADB/TLS Diagnostic Tool)
::
:: Runs a full diagnostic of ADB-over-TLS, TCP/IP mode, adbd state,
:: Wireless Debugging state, and scrcpy readiness for Android 12+.
@echo off
setlocal enabledelayedexpansion

:: Version string
set SCRIPT_VERSION=v1p6
set SCRIPT_DATE=20260630

echo ============================================
echo ADB Debug Tool Android 12+ TLS Diagnostic
echo Running adbdebugtls.bat %SCRIPT_VERSION% %SCRIPT_DATE%
echo ============================================
echo.
::
:: v1p6 20260630
:: When in deep sleep, a reboot and wireless debugging toggle isn't enough.
:: Either we have to authenticate over USB or over Android 11 pairing so
:: this version will tell the user what they need to do so as to pair.
::
:: v1p5 20260629
:: Added hard deep-sleep check & warning that the phone must be rebooted
:: as just toggling Wireless debugging will not wake from hard deep sleep
:: Note that we might have to reboot and pair using Android 11 methods.
::
:: v1p4 20260628
:: Show TLS recovery suggestions whenever TLS advertiser is ASLEEP
:: Added Android 11 pairing-mode instructions (adb pair / adb connect)
:: Added Android 12+ Wireless Debugging toggle instructions
:: Kept USB fallback instructions for classic TCP/IP mode
::
:: v1p3 20260627
:: Added recovery suggestions
:: such as toggle Wireless Debugging, USB fallback, reboot
::
:: v1p2 20260626
:: Added TLS-only mode detection
:: Added TCP/IP mode detection
:: Added USB fallback detection
:: Added ADB Deep Sleep Summary block
:: Added auto-suggestions inside summary (v1p2)
::
:: v1p1 20260625
:: Added script version and date output
:: The TLS advertiser, adbd and the Wireless Debugging service enter
:: a deep sleep sate when the phone has been idle for a long time.
:: Added comments to explain the debug results when that happens.
::
:: v1p0 20260620
:: Diagnose the state of Android's ADB daemon on Android 12+ devices,
:: including TLS advertiser status, TCP/IP mode, adbd internal state,
:: Wireless Debugging service state and scrcpy readiness.
::
:: Android 12+ introduced ADB-over-TLS Auto-Discovery, which broadcasts
:: on the LAN using mDNS as:
:: _adb-tls-connect._tcp
:: The desktop ADB server auto-connects to this TLS service as:
:: adb-SERIAL._adb-tls-connect._tcp
:: This TLS system:
:: a. bypasses pairing
:: b. bypasses USB authorization
:: c. bypasses debug ports
:: d. auto-connects whenever ADB restarts
:: But scrcpy cannot use TLS directly. It only supports:
:: a. USB
:: b. Classic TCP/IP ADB (port 5555)
:: Hence, this script checks:
:: 1. TLS advertiser status (adb mdns services)
:: 2. TCP/IP connectivity on port 5555
:: 3. adbd internal state via getprop
:: 4. Wireless Debugging service state via dumpsys
:: Note Samsung may hide or rename the Wireless Debugging service.
:: 5. scrcpy readiness (device state)
:: Note the wake attempts when the phone TLS service goes asleep.
:: i. Restarting the PC ADB server
:: ii. Restarting adbd on the phone (if reachable)
:: iii. Forcing TCP/IP fallback on port 5555
:: Note Android does not expose a command to toggle Wireless Debugging.
:: So the TLS advertiser cannot be automaticaly awakened from ADB.
:: Hence, this script reports TLS sleep but cannot force it awake.
::
:: Set your phone IP here
set PHONE_IP=192.168.1.4

:: Begin 1
echo.
echo === 1. Restart PC ADB Server ===
echo adb kill-server
adb kill-server
echo adb start-server
adb start-server
echo.
:: End 1

:: Begin 2
echo.
echo === 2. TLS Status mDNS Advertiser ===
echo Command: adb mdns services
adb mdns services | findstr /I "_adb-tls-connect._tcp"
if errorlevel 1 (
echo TLS advertiser is ASLEEP.
echo.
echo Meaning:
echo The phone is NOT broadcasting _adb-tls-connect._tcp
echo The Wireless Debugging mDNS service is OFF or in deep sleep
echo ADB-over-TLS cannot auto-discover the device
echo The PC cannot wake the phone via TLS
echo.
echo Why this happens:
echo Phone idle for long periods
echo Wi-Fi reconnected or changed access points
echo Wireless Debugging has not been toggled recently
echo.
echo Result:
echo TLS mode is unavailable
echo Only USB or manual Wireless Debugging toggle can wake adbd
) else (
echo TLS advertiser is ACTIVE.
echo The phone is broadcasting _adb-tls-connect._tcp.
)

echo.

:: TLS-only mode detection
:: This sets %TLS_STATE% for later summary logic
if errorlevel 1 (
set TLS_STATE=ASLEEP
) else (
set TLS_STATE=ACTIVE
)

:: End 2

:: Begin 3
echo.
echo === 3. TCP/IP Status Port 5555 ===
echo Command: adb connect %PHONE_IP%:5555
adb connect %PHONE_IP%:5555

if errorlevel 1 (
echo.
echo TCP/IP mode is OFF.
echo Port 5555 is CLOSED on the phone.
echo.
echo Meaning:
echo Classic ADB-over-TCP is disabled
echo scrcpy cannot connect over Wi-Fi
echo The phone is in TLS-only Wireless Debugging mode
echo.
echo Why this happens:
echo Android 12+ disables TCP/IP mode automatically
echo Happens after reboot, Wi-Fi changes, or long idle periods
echo Happens when Wireless Debugging is ON but not paired recently
echo.
echo Result:
echo adb connect fails with "actively refused 10061"
echo Only USB can re-enable TCP/IP mode via "adb tcpip 5555"
) else (
echo TCP/IP mode is ACTIVE on port 5555.
echo Classic ADB-over-TCP is available.
)

echo.

echo Command: adb devices
adb devices
echo.

:: TCP/IP mode detection
if errorlevel 1 (
set TCPIP_STATE=OFF
) else (
set TCPIP_STATE=ON
)
:: End 3

:: Begin 4
echo.
echo === 4. Attempting to Wake adbd if reachable ===
echo Trying: adb shell stop adbd
adb shell stop adbd 2>nul
echo Trying: adb shell start adbd
adb shell start adbd 2>nul
echo.
:: End 4

:: Begin 5
echo.
echo === 5. adbd Internal State ===
echo Command: adb shell getprop init.svc.adbd
adb shell getprop init.svc.adbd
if errorlevel 1 (
echo.
echo adbd is UNREACHABLE.
echo.
echo Meaning:
echo No TLS connection
echo No TCP/IP connection
echo No USB connection
echo.
echo Result:
echo Cannot read adbd internal state
echo Cannot restart adbd remotely
echo Phone is in ADB Deep Sleep mode
) else (
echo adbd internal state retrieved.
)
echo.

echo Command: adb shell getprop service.adb.tcp.port
adb shell getprop service.adb.tcp.port
echo.

echo Command: adb shell getprop ro.adb.secure
adb shell getprop ro.adb.secure
echo.
:: End 5

:: Begin 6
echo.
echo === 6. Wireless Debugging State ===
echo Command: adb shell dumpsys activity service com.android.adb.adbd
adb shell dumpsys activity service com.android.adb.adbd
if errorlevel 1 (
echo.
echo Wireless Debugging service is ASLEEP.
echo.
echo Meaning:
echo The service is not running
echo The TLS advertiser is not active
echo The phone cannot accept TLS connections
echo.
echo Why this happens:
echo Android put the service into deep sleep
echo Happens after long idle periods or Wi-Fi changes
echo.
echo Result:
echo Wireless Debugging must be toggled OFF -> ON manually
echo Or USB must be used to wake adbd
) else (
echo Wireless Debugging service is ACTIVE.
)

echo.
:: End 6

:: Begin 7
echo.
echo === 7. scrcpy Readiness Check ===
echo If device shows as "device", scrcpy can run.
echo If port 5555 is active, scrcpy --tcpip works.
echo.

echo Command: adb devices
adb devices > devices.tmp

:: USB fallback detection
:: This detects whether
:: USB connected as device appears without an IP
:: TCP/IP connected as device appears with 192.168.x.x:5555
:: Neither, likely meaning deep sleep
findstr /I "device" devices.tmp | findstr /V ":" >nul
if not errorlevel 1 (
set USB_STATE=CONNECTED
) else (
set USB_STATE=DISCONNECTED
)

echo.
echo If no devices appear:

echo ADB cannot reach the phone
echo TLS is asleep
echo TCP/IP mode is off
echo scrcpy cannot run
echo.
echo If the phone appears as "device":
echo scrcpy can run over USB or TCP/IP
echo.
echo If the phone appears as "192.168.x.x:5555 device":
echo scrcpy --tcpip will work

echo.
:: End 7

:: Begin 8
echo.
echo === ADB Deep Sleep Summary ===

:: Determine deep sleep state
if "%TLS_STATE%"=="ASLEEP" (
if "%TCPIP_STATE%"=="OFF" (
if "%USB_STATE%"=="DISCONNECTED" (
echo.
echo OVERALL STATE: PHONE IS IN ADB DEEP SLEEP MODE.
echo.
echo Meaning:
echo TLS advertiser asleep
echo TCP/IP mode off
echo USB not connected
echo.
echo Recovery summary:
echo 1. Toggle Wireless Debugging OFF -> ON
echo 2. Connect USB and run: adb tcpip 5555
echo 3. Reboot the phone to restart adbd
)
)
)

if "%USB_STATE%"=="CONNECTED" (
echo.
echo OVERALL STATE: USB CONNECTED.
echo scrcpy can run over USB.
)

if "%TCPIP_STATE%"=="ON" (
echo.
echo OVERALL STATE: TCP/IP MODE ACTIVE.
echo scrcpy --tcpip will work.
)
:: End 8

:: Begin 9
echo Checking for Hard Deep Sleep...
adb mdns services | findstr /I "_adb-tls-connect._tcp" >nul
if errorlevel 1 (
set TLS_STATE=ASLEEP
) else (
set TLS_STATE=ACTIVE
)

adb connect %PHONE_IP%:5555 >nul
if errorlevel 1 (
set TCPIP_STATE=ASLEEP
) else (
set TCPIP_STATE=ACTIVE
)

adb devices | findstr /I "device" | findstr /V ":" >nul
if errorlevel 1 (
set USB_STATE=NOT_AUTH
) else (
set USB_STATE=AUTHORIZED
)

echo Checking for Hard Deep Sleep...

:: Hard Deep Sleep means:
:: TLS asleep
:: TCPIP refusing
:: adbd unreachable
:: scrcpy failed

if "%TLS_STATE%"=="ASLEEP" (
if "%TCPIP_STATE%"=="ASLEEP" (
echo.
echo Hard Deep Sleep detected.
echo Wireless Debugging is stuck.
echo TLS advertiser did not restart.
echo adbd is unreachable.
echo scrcpy cannot connect.
echo.
echo Fix:
echo Reboot the phone to restart Wireless Debugging.
echo After reboot, enable Wireless debugging.
echo Then re-run adbconnecttls.bat.
echo.
)
)


echo.
echo Android 12+ TLS auto-connect failed.
echo USB fallback unavailable.
echo Android 11 Wireless Debugging pairing mode is available.
echo.
echo This debug tool does not perform pairing or connection steps.
echo Use adbconnect.bat to run Android 11 pairing mode.
echo.
echo Steps:
echo 1. On the phone, open Wireless debugging
echo Choose "Pair device with pairing code"
echo 2. Note the IP, pairing port, pairing code, and debug port
echo 3. Run adbconnect.bat and enter the values when prompted
echo.
echo After pairing, adbconnect.bat will:
echo Connect to the debug port
echo Switch the device to TCP/IP 5555
echo Connect to port 5555
echo Launch scrcpy
echo.
echo This diagnostic script only reports the state and suggests actions.


:: End 9

:: Begin 10
echo.
echo ============================================
echo adbdebugtls.bat %SCRIPT_VERSION% %SCRIPT_DATE% Diagnostics complete
echo ============================================

echo.
echo ============================================
echo === Suggested Commands to Fix Wireless Debugging ===
echo ============================================
echo.
echo Your phone is NOT ready for TLS auto-connect.
echo To make adbconnecttls.bat succeed, do ONE of the following:
echo.

:: Normal Deep Sleep recommendation
if "%TLS_STATE%"=="ASLEEP" (
if "%TCPIP_STATE%"=="OFF" (
if "%USB_STATE%"=="DISCONNECTED" (
echo --- Normal Deep Sleep ---
echo 1. Open Developer options, Wireless debugging
echo Toggle Wireless debugging OFF, then ON
echo This wakes the TLS advertiser in normal Deep Sleep
echo.
)
)
)

:: Hard Deep Sleep recommendation
if "%TLS_STATE%"=="ASLEEP" (
if "%TCPIP_STATE%"=="ACTIVE" (
if "%USB_STATE%"=="AUTHORIZED" (
echo --- Hard Deep Sleep ---
echo 2. Reboot the phone from the power menu
echo Wireless Debugging and TLS will restart cleanly
echo After reboot, enable Wireless debugging again
echo.
)
)
)

echo --- Android 11 Pairing Code Mode ---
echo 3. On the phone, open Wireless debugging and choose
echo Pair device with pairing code
echo Note the IP and port shown on the phone
echo Then run on the PC
echo adb pair ^<ip^>:^<port^>
echo After pairing succeeds, run
echo adb connect ^<ip^>:^<port^>
echo.

echo --- USB fallback if USB works ---
echo 4. Connect USB and run on the PC
echo adb devices
echo adb tcpip 5555
echo adb connect %PHONE_IP%:5555
echo This wakes adbd and enables classic TCP/IP mode
echo.

echo After doing one of these, re-run adbconnecttls.bat
echo It should now be able to connect successfully
echo.

:: End 10

endlocal
exit /b

:: end of adbdebugtls.bat
--
For some people, Usenet is amusement, but for me, it's for adding value.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Since adb is as essential to Android as ls is to Linux or dir to Windows,
it's important to note that ADB plus scrcpy started as USB-only until
Android 11 introduced secure Wi-Fi pairing with a pairing code plus random port that we had to literally L@@K at in order to know them, but then
Android 12 refined this with TLS-based pairing that no longer required us
to manually know or even care about the specific Wireless connection port.
<https://gadgetguideonline.com/android/android-adb-wireless-debugging/>

For operating a phone on desktop monitor/mouse/keyboard/clipboard/speakers scrcpy itself does not implement wireless protocols because screen copy
simply uses whatever ADB transport is active.
a. USB debugging -> scrcpy works immediately.
b. ADB over TCP/IP (manual or automatic) -> scrcpy works over Wi-Fi.
c. Wireless debugging (Android 11+) -> scrcpy works after pairing

scrcpy added convenience flags like --tcpip to automate enabling ADB over Wi-Fi, but the underlying connection rules come from Android's ADB system.

To make those connections a single-step process, I wrote the three scripts which are pasted in cleartext in this thread so that others can benefit.
$ adbconnectusb.bat (USB debugging, classic, pre-Android-11)
$ adbconnect.bat (ADB over TCP/IP, manual Wi-Fi mode, pre-Android-11)
$ adbconnecttls.bat (Wireless Debugging with pairing, Android 11+)
$ adbdebugtls.bat (TLS Wireless Debugging, Android 12+)

They turn multi-step ADB commands into single-action shortcuts,
so scrcpy can immediately attach to whichever transport is active.

Below is the latest adbconnect script, with the latest bugfixes.
I should probably rename it adbconnecttcp.bat to line up conventions.

:: adbconnect.bat
:: Android-to-desktop Wi-Fi adb and scrcpy connections
:: Connects Android 11 and Android 12+ devices to adb and scrcpy using
:: pairing mode and classic TCPIP mode. This script uses the Android
:: Wireless Debugging pairing workflow to obtain the pairing port,
:: pairing code and debug port from the phone. It then performs adb
:: pair and adb connect with retry logic, switches the device to TCPIP
:: port 5555 and launches scrcpy silently. This script does not use TLS
:: for the scrcpy connection, but it depends on Wireless Debugging
:: being active because Wireless Debugging controls whether adbd is
:: reachable. Once TCPIP mode is enabled, the script reconnects to
:: port 5555 and starts scrcpy over classic TCPIP mode.
::
:: 1. Eliminates the useless scrcpy console window which takes up space
:: 2. Eliminates random security steps in Wi-Fi adb connections
:: 3. Solves reconnection problems when
:: a. The phone leaves the LAN and returns
:: b. The PC is rebooted
:: c. The phone is rebooted
:: d. A connection is attempted when already connected
:: Uses Wireless Debugging mode plus classic TCPIP ADB mode.
:: Wireless Debugging does not open port 5555 by itself.
:: Classic ADB-over-WiFi can use port 5555 to simplify reconnects.
:: Running adb tcpip 5555 forces Android to open port 5555 even in
:: Wireless Debugging mode. This makes reconnections simpler because
:: the phone stays open on port 5555 even if
:: a. the phone leaves and rejoins the LAN
:: b. the PC reboots
:: c. scrcpy drops and reconnects
:: Port 5555 remains active until the phone reboots because Android
:: rebooting disables Wireless Debugging and closes the TCPIP daemon.
::
:: USB authorization can eliminate pairing codes
:: i. Connect via USB
:: ii. adb connect PHONE_IP:5555
:: iii. scrcpy --tcpip=PHONE_IP
::
:: If a USB device is present and authorized, adb devices will show
:: PHONE_IP:5555 device
:: You cannot get device state without USB authorization
::
:: Android 12+ introduced ADB-over-TLS auto-advertised via mDNS.
:: It auto-connects over encrypted channels without pairing or ports.
:: It appears as adb-SERIAL-GUID._adb-tls-connect._tcp
:: Wireless Debugging controls whether this TLS service is awake.
:: scrcpy cannot use the TLS auto-connect device directly.
::
:: This script uses pairing mode and TCPIP mode only.
:: TLS auto-connect is not used for scrcpy, but TLS must be awake
:: for adbd to be reachable.
::
:: v2p5 20260630
:: Cleaned up the descriptions by summarizing the version comments.
::
:: v2p4 20260630
:: Added version output string and improved explanations
::
:: v2p3 20260624
:: Added ability to detect if USB authentication was already done
::
:: v2p2 20260622
:: Improved handling of offline and unauthorized states
::
:: v2p1 20260621
:: Added SUMMARY system for executed commands
::
:: v2p0 20260621
:: Restored working version from v1p7
::
:: v1p9 20260620
:: Removed debug-port connect step which broke Wireless Debugging
::
:: v1p8 20260619
:: Removed debug-port connect step which broke Wireless Debugging
::
:: v1p7 20260615
:: Removed requirement for scrcpy-noconsole.vbs
::
:: v1p6 20260614
:: Added VBS no-console launcher fallback
::
:: v1p5 20260613
:: Added query asking for phone LAN IP address
::
:: v1p4 20260612
:: Minimized scrcpy console window
::
:: v1p3 20260612
:: Improved reliability of adb devices parsing
::
:: v1p2 20260611
:: Added retry logic and improved device-id handling
::
:: v1p1 20260611
:: Improved device lookup and reliability
::
:: v1p0 20260611
:: Converted adbconnect.vbs to adbconnect.bat
:: Connects desktop and phone over Wi-Fi using adb and scrcpy
:: No USB cord required

@echo off
:: vi. debugging can be removed later
:: echo MARK 1
setlocal enabledelayedexpansion

:: Version string
set SCRIPT_VERSION=v2p5
set SCRIPT_DATE=20260630

echo ============================================
echo ADB-over-TLS to TCPIP Launcher Debug Mode
echo Running adbconnect.bat %SCRIPT_VERSION% %SCRIPT_DATE%
echo ============================================
echo.

:: initialize temp summary file
set SUMMARY_FILE=%TEMP%\adbconnect_summary.txt
if exist "%SUMMARY_FILE%" del "%SUMMARY_FILE%"

:: On phones with static IP addresses, change the next line
set PHONE_IP=192.168.1.4
set SCRCPY_OPTS=--keyboard=sdk --always-on-top

echo.
echo === ADB Wireless Auto-Connect ===
echo === [Developer options > Wireless debugging > on] ===
echo.

REM 1. Find adb
:: REM ii. debugging (can be removed later)
:: if defined TRACE echo BEFORE FIRST FOR

:: REM vii. debugging can be removed later
:: echo MARK 2
for /f "delims=" %%A in ('where adb 2^>nul') do (
if not defined ADB set ADB=%%A
)

:: REM viii. debugging can be removed later
:: echo MARK 3

:: REM iii. debugging (can be removed later)
:: if defined TRACE echo AFTER FIRST FOR


if not defined ADB (
echo [ERROR] adb.exe not found.
exit /b
)

REM Ensure .exe extension
if /i not "%ADB:~-4%"==".exe" set ADB=%ADB%.exe

echo Using ADB: "%ADB%"
echo.

REM 2. Check if already connected
echo Checking existing ADB devices...

:: REM i. debugging (can be removed later)
:: set TRACE=1

set DEVICE_ID=
set DEVICE_STATE=

REM Do not add extra quotes here as all these break batch parsing!
:: '"%ADB%" devices'
:: "%ADB%" devices
:: '"%ADB%" devices"'
:: '"%ADB%" devices"'

:: REM iv. debugging can be removed later
:: if defined TRACE echo BEFORE SECOND FOR

:: REM ix. debugging can be removed later
:: echo MARK 4
for /f "skip=1 tokens=1,2" %%I in ('%ADB% devices') do (
echo %%I | findstr /I "%PHONE_IP%" >nul && (
if not defined DEVICE_ID (
set DEVICE_ID=%%I
set DEVICE_STATE=%%J
)
)
)

:: REM x. debugging can be removed later
:: echo MARK 5

:: REM v. debugging can be removed later
:: if defined TRACE echo AFTER SECOND FOR

REM treat only "device" as connected

:: echo MARK 6
echo DEVICE_ID="%DEVICE_ID%" DEVICE_STATE="%DEVICE_STATE%"

REM if no device id, skip to NOT_CONNECTED
if "%DEVICE_ID%"=="" goto NOT_CONNECTED

REM if state is not "device", skip to NOT_CONNECTED
if /I not "%DEVICE_STATE%"=="device" goto NOT_CONNECTED

echo Already connected on %DEVICE_ID%
echo adb devices>>"%SUMMARY_FILE%"

REM skip redundant tcpip if already on 5555
if /I "%DEVICE_ID:~-5%"==":5555" (
echo Device already on port 5555. Skipping tcpip switch.
goto RUN_SCRCPY
)

goto RUN_TCPIP

:NOT_CONNECTED
:: echo MARK 8
echo Not connected. Need to pair.
echo.

REM 3. Ask user for pairing info
echo Necessary pairing information will be shown on the phone:
set /p PHONE_IP=Phone IP [%PHONE_IP%] :
set /p PAIR_PORT=Wireless debugging pairing port:
set /p PAIR_CODE=Wireless debugging pairing code:
set /p DEBUG_PORT=Wireless debugging debug port:

echo.
echo Pairing with: %PHONE_IP%:%PAIR_PORT%

REM Retry logic for adb pair (3 attempts)
set ATTEMPTS_PAIR=0
:PAIR_RETRY
set /a ATTEMPTS_PAIR+=1
"%ADB%" pair %PHONE_IP%:%PAIR_PORT% %PAIR_CODE%

if not errorlevel 1 (
echo adb pair %PHONE_IP%:%PAIR_PORT% %PAIR_CODE%>>"%SUMMARY_FILE%"
)

if errorlevel 1 (
if !ATTEMPTS_PAIR! lss 3 (
echo Pair failed, retrying...
timeout /t 2 >nul
goto PAIR_RETRY
) else (
echo [ERROR] adb pair failed after %ATTEMPTS_PAIR% attempts.
exit /b 1
)
)
echo.

echo Connecting to debug port: %PHONE_IP%:%DEBUG_PORT%

REM Retry logic for adb connect (3 attempts)
set ATTEMPTS_CONN=0
:CONNECT_RETRY
set /a ATTEMPTS_CONN+=1
"%ADB%" connect %PHONE_IP%:%DEBUG_PORT%

if not errorlevel 1 (
echo adb connect %PHONE_IP%:%DEBUG_PORT%>>"%SUMMARY_FILE%"
)

REM wait a few seconds for the Android adb daemon to be ready
timeout /t 2 >nul

if errorlevel 1 (
if !ATTEMPTS_CONN! lss 3 (
echo Connect failed, retrying...
timeout /t 2 >nul
goto CONNECT_RETRY
) else (
echo [ERROR] adb connect %PHONE_IP%:%DEBUG_PORT% failed after %ATTEMPTS_CONN% attempts.
exit /b 2
)
)
echo.

REM Do not add extra quotes here as all these break batch parsing!
:: '"%ADB%" devices'
:: "%ADB%" devices
:: '"%ADB%" devices"'
:: '"%ADB%" devices"'

REM After connect, get the actual device id
set DEVICE_ID=
for /f "tokens=1" %%I in ('%ADB% devices ^| findstr /C:"%PHONE_IP%:"') do (
if not defined DEVICE_ID set DEVICE_ID=%%I
)

if defined DEVICE_ID (
echo Found device id: "%DEVICE_ID%"
) else (
echo [WARN] No device id found after connect.
set DEVICE_ID=%PHONE_IP%:%DEBUG_PORT%
)

goto RUN_TCPIP

:RUN_TCPIP
echo Switching device %DEVICE_ID% to TCP/IP 5555...
"%ADB%" -s "%DEVICE_ID%" tcpip 5555
if not errorlevel 1 echo adb -s %DEVICE_ID% tcpip 5555>>"%SUMMARY_FILE%"

echo Connecting final port: %PHONE_IP%:5555
"%ADB%" connect %PHONE_IP%:5555
if not errorlevel 1 echo adb connect %PHONE_IP%:5555>>"%SUMMARY_FILE%"

set DEVICE_ID=%PHONE_IP%:5555

:RUN_SCRCPY
echo Launching scrcpy completely silent...

set "VBS_TEMP=%TEMP%\scrcpy_runner.vbs"

echo strCommand = "cmd /c scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%" > "%VBS_TEMP%"
echo CreateObject("Wscript.Shell").Run strCommand, 0, false >> "%VBS_TEMP%"

echo scrcpy --tcpip=%PHONE_IP% %SCRCPY_OPTS%>>"%SUMMARY_FILE%"

wscript.exe "%VBS_TEMP%"

timeout /t 1 >nul
if exist "%VBS_TEMP%" del "%VBS_TEMP%"

echo Done.
echo.
echo Summary of steps run in this instance:
type "%SUMMARY_FILE%"
echo.
echo.
echo.

exit /b

REM end of adbconnect.bat
--
Usenet is a team sport where each person adds unique value their own way.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-01 04:12, Maria Sophia wrote:

Since adb is as essential to Android as ls is to Linux or dir to Windows,

Huh, no. adb is not essential to Android. I have never used it. I use
'ls' daily.
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. wrote:

On 2026-07-01 04:12, Maria Sophia wrote:

Since adb is as essential to Android as ls is to Linux or dir to Windows,

Huh, no. adb is not essential to Android. I have never used it. I use
'ls' daily.

Hi Carlos,

Excellent point! I was speaking about us. We're all power users, I presume.

Given I never disagree with any logically sensible observation, I must
agree that the poor examples I used (of ls & dir) are "more essential" to
the average Linux and Windows user than adb is to the average Android user.

What I should have said more clearly is essential to whom.
I agree that adb is not essential to the masses of Android hoi polloi.

What adb is essential to is people like we are, who consider ourselves
power users, such as anyone who needs to automate, debloat, debug,
sideload, or recover a device, in addition to my main use of adb which is
to interoperate seamlessly the phone with any desktop PC on the planet.

In that power-user interoperability context, adb is as fundamental as a compiler is to a programmer, even as proletariat never touch a compiler.

Hence, I agree with you that a better analogy would have stayed within the realm of interoperability & efficiency tools rather than basic OS commands.

For example, on Linux a closer match would be something like ssh, rsync, or even udevadm. These are not essential to the average Linux user, but they
are absolutely essential to anyone who needs to automate, inspect, or interoperate with devices at a deeper level.

On Windows, a closer match would be something like PowerShell remoting,
pnputil or the various command-line tools in the Windows ADK. Again, normal users never touch interoperability tools for efficiency, but anyone who
needs to script, manage or interoperate with devices depends on them.

Those kinds of tools are optional for the masses but indispensable for
power users who need reliable, scriptable, cross-platform interoperability.

Given nothing else does what adb does, adb fits that same category.
--
A wise person never disagrees with any sensibly logically defensible point.
--- Synchronet 3.22a-Linux NewsLink 1.2