From Newsgroup: alt.os.linux

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: alt.os.linux

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: alt.os.linux

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: alt.os.linux

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: alt.os.linux

On 12/06/2026 22:32, Hank Rogers wrote:

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.

Agreed. It now works, and users will be able to achieve a very hard
erection in time for Mary to perform oral sex.



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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: alt.os.linux

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 🇵🇱, UE 🇪🇺;
tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <[email protected]>, 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ĄGAJ "UKRYTEGO DŁUGU"! PŁ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: alt.os.linux

On Mon, 6/15/2026 5:08 AM, 🇵🇱Jacek Marcin Jaworski🇵🇱 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: alt.os.linux

W dniu 15.06.2026 o 18: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 🇵🇱, UE 🇪🇺;
tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <[email protected]>, 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ĄGAJ "UKRYTEGO DŁUGU"! PŁ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: alt.os.linux

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: alt.os.linux

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: alt.os.linux

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: alt.os.linux

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 <[email protected]> to follow.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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: alt.os.linux

🇵🇱Jacek Marcin Jaworski🇵🇱 <[email protected]> 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: alt.os.linux

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: alt.os.linux

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.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Maria Sophia <[email protected]> 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: alt.os.linux

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: alt.os.linux

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: alt.os.linux

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.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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: alt.os.linux

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.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

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: alt.os.linux

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¡ñ§±¤ñ
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

At Mon, 15 Jun 2026 14:10:00 -0500, Maria Sophia <[email protected]> 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: alt.os.linux

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: alt.os.linux

....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