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
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).
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.
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).
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).
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.
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?
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?
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.
Carlos E. R. wrote:
On 2026-06-16 19:07, Maria Sophia wrote:
Carlos E. R. wrote:Accusing others doesn't change facts.
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. >>
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.
Chris wrote:
Nope. Try comprehending what I actually wrote rather than responding toI 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? >>
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?
Carlos E. R. wrote:
On 2026-06-16 19:07, Maria Sophia wrote:
Carlos E. R. wrote:Accusing others doesn't change facts.
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. >>
Well, I'm going to ask *you* to provide something that is worth value.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 11 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 169:02:42 |
| Calls: | 219 |
| Files: | 21,503 |
| Messages: | 83,448 |