Groups > comp.mobile.android > #154108 > unrolled thread

PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing

Started by	Maria Sophia <mariasophia@comprehension.com>
First post	2026-06-10 02:07 -0600
Last post	2026-06-27 08:58 -0400
Articles	20 on this page of 44 — 9 participants

Back to article view | Back to comp.mobile.android

  PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-10 02:07 -0600
    Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-11 21:49 -0500
      Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-12 16:17 -0500
        Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Hank Rogers <Hank@nospam.invalid> - 2026-06-12 16:32 -0500
          Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-13 11:31 -0500
    Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-06-15 11:08 +0200
      Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Paul <nospam@needed.invalid> - 2026-06-15 12:11 -0400
        Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-06-15 19:24 +0200
          Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-15 14:10 -0500
            Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-15 14:43 -0500
            Re: PSA: Streamlined persistent ADB port over   Wi‑Fi without repeated pairing vallor <vallor@vallor.earth> - 2026-06-17 00:16 +0000
              Re: PSA: Streamlined persistent ADB port over   Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-16 23:23 -0500
        Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-15 13:56 -0500
          Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Warpinator <invalid@invalid.invalid> - 2026-06-16 00:23 +0100
            Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-15 19:18 -0500
              Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-16 12:15 +0200
      Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Chris <ithinkiam@gmail.com> - 2026-06-16 07:07 +0000
        Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-16 02:21 -0500
          Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-16 12:30 +0200
            Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-16 12:07 -0500
              Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-16 20:11 +0200
                Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-16 14:40 -0500
                  Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-16 22:47 +0200
                    Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-16 15:51 -0500
                      Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-18 00:45 +0200
                        Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Hank Rogers <Hank@nospam.invalid> - 2026-06-17 17:56 -0500
                  Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing "....winston" <winstonmvp@gmail.com> - 2026-06-16 19:47 -0400
                    Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-16 23:26 -0500
          Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Chris <ithinkiam@gmail.com> - 2026-06-16 12:10 +0000
            Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-16 12:09 -0500
              Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Chris <ithinkiam@gmail.com> - 2026-06-16 23:34 +0000
                Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Chris <ithinkiam@gmail.com> - 2026-06-17 18:59 +0000
                  Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-18 01:31 +0200
                    Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Chris <ithinkiam@gmail.com> - 2026-06-18 06:00 +0000
                      Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-18 15:09 -0500
                        Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-19 00:24 +0200
                          Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-18 19:19 -0500
                            Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Chris <ithinkiam@gmail.com> - 2026-06-19 06:59 +0000
                Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Chris <ithinkiam@gmail.com> - 2026-06-17 23:32 +0000
                Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-26 06:38 -0400
    Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-20 02:22 -0500
      Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-20 02:31 -0500
      Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-21 00:53 -0500
    Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-27 08:58 -0400

Page 1 of 3 [1] 2 3 Next page →

#154108 — PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing

From	Maria Sophia <mariasophia@comprehension.com>
Date	2026-06-10 02:07 -0600
Subject	PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing
Message-ID	<110b60u$25n1$1@nnrp.usenet.blueworldhosting.com>

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.

[toc] | [next] | [standalone]

#154134

From	Maria Sophia <mariasophia@comprehension.com>
Date	2026-06-11 21:49 -0500
Message-ID	<110fs49$lu4$1@nnrp.usenet.blueworldhosting.com>
In reply to	#154108

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.

[toc] | [prev] | [next] | [standalone]

#154142

From	Maria Sophia <mariasophia@comprehension.com>
Date	2026-06-12 16:17 -0500
Message-ID	<110ht1h$27co$1@nnrp.usenet.blueworldhosting.com>
In reply to	#154134

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.

[toc] | [prev] | [next] | [standalone]

#154143

From	Hank Rogers <Hank@nospam.invalid>
Date	2026-06-12 16:32 -0500
Message-ID	<110htt5$2groe$1@dont-email.me>
In reply to	#154142

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.

[toc] | [prev] | [next] | [standalone]

#154147

From	Maria Sophia <mariasophia@comprehension.com>
Date	2026-06-13 11:31 -0500
Message-ID	<110k0lo$1ecm$1@nnrp.usenet.blueworldhosting.com>
In reply to	#154143

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.

[toc] | [prev] | [next] | [standalone]

#154161

From	🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl>
Date	2026-06-15 11:08 +0200
Message-ID	<a_-dnRjhJc7QXLL3nZ2dnZfqnPGdnZ2d@giganews.com>
In reply to	#154108

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;
<jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW:                             <https://energokod.gda.pl>;
Mini Netykieta:         <https://energokod.gda.pl/MiniNetykieta.html>;
Mailowa Samoobrona:             <https://emailselfdefense.fsf.org/pl>.
UWAGA:
NIE ZACIĄ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>

[toc] | [prev] | [next] | [standalone]

#154166

From	Paul <nospam@needed.invalid>
Date	2026-06-15 12:11 -0400
Message-ID	<110p881$fqua$1@dont-email.me>
In reply to	#154161

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

[toc] | [prev] | [next] | [standalone]

#154167

From	🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl>
Date	2026-06-15 19:24 +0200
Message-ID	<GEadnXuS5InOqK33nZ2dnZfqnPadnZ2d@giganews.com>
In reply to	#154166

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;
<jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW:                             <https://energokod.gda.pl>;
Mini Netykieta:         <https://energokod.gda.pl/MiniNetykieta.html>;
Mailowa Samoobrona:             <https://emailselfdefense.fsf.org/pl>.
UWAGA:
NIE ZACIĄ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>

[toc] | [prev] | [next] | [standalone]

#154169

From	Maria Sophia <mariasophia@comprehension.com>
Date	2026-06-15 14:10 -0500
Message-ID	<110pim7$3104$1@nnrp.usenet.blueworldhosting.com>
In reply to	#154167

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.

[toc] | [prev] | [next] | [standalone]

#154171

From	Maria Sophia <mariasophia@comprehension.com>
Date	2026-06-15 14:43 -0500
Message-ID	<110pkl6$lip$1@nnrp.usenet.blueworldhosting.com>
In reply to	#154169

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.

[toc] | [prev] | [next] | [standalone]

#154195 — Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing

From	vallor <vallor@vallor.earth>
Date	2026-06-17 00:16 +0000
Subject	Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing
Message-ID	<110sp1k$1fvkv$7@dont-email.me>
In reply to	#154169

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

> Jacek Marcin Jaworski wrote:
> > You miss one thing, they don't ask anything, but just publish their scripts
> > Usenet is not intended for this except binary groups.
> 
> The question is how to run adb/scrcpy over Wi-Fi in a single step.
> And, how to launch scrcpy mirroring without the console window.

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

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

So thank you for that.

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

[toc] | [prev] | [next] | [standalone]

#154196 — Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing

From	Maria Sophia <mariasophia@comprehension.com>
Date	2026-06-16 23:23 -0500
Subject	Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing
Message-ID	<110t7g7$2l9d$1@nnrp.usenet.blueworldhosting.com>
In reply to	#154195

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

[toc] | [prev] | [next] | [standalone]

#154168

From	Maria Sophia <mariasophia@comprehension.com>
Date	2026-06-15 13:56 -0500
Message-ID	<110phsu$1ku4$1@nnrp.usenet.blueworldhosting.com>
In reply to	#154166

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!)

[toc] | [prev] | [next] | [standalone]

#154172

From	Warpinator <invalid@invalid.invalid>
Date	2026-06-16 00:23 +0100
Message-ID	<jU%XR.118310$SHu9.73006@fx45.iad>
In reply to	#154168

On 15/06/2026 19:56, Maria Sophia wrote:
> The whole point, of course, is that if something takes 10 steps, we reduce
> it in half & if it takes 2 steps, we still reduce it in half (if we can).

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

[toc] | [prev] | [next] | [standalone]

#154173

From	Maria Sophia <mariasophia@comprehension.com>
Date	2026-06-15 19:18 -0500
Message-ID	<110q4op$nt5$1@nnrp.usenet.blueworldhosting.com>
In reply to	#154172

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.

[toc] | [prev] | [next] | [standalone]

#154179

From	"Carlos E. R." <robin_listas@es.invalid>
Date	2026-06-16 12:15 +0200
Message-ID	<n9cm1iFas8nU1@mid.individual.net>
In reply to	#154173

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🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154174

From	Chris <ithinkiam@gmail.com>
Date	2026-06-16 07:07 +0000
Message-ID	<110qsns$ubq8$1@dont-email.me>
In reply to	#154161

🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> wrote:
> It is hard to me find any reason to use your scripts from this thread. 
> Maybe they will be useful, when I return to commercial Android programming.
> 
> But I have "a buddy-to-buddy reprimand" for you:
> Publishing files here like you did is against Netiquette. Because it is 
> allowed only for "binary groups".
> So, if you think your scripts are useful, and you can maintain them for 
> long time (for eg. 5y. - like typical commercial products), then please 
> publish them on separate server. It can be just *.zip, or *.tar.xz 
> archive on your home page (github.com is not mandatory, and I do not 
> recommend it due to generating "secret debt" for their users).

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

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

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

[toc] | [prev] | [next] | [standalone]

#154177

From	Maria Sophia <mariasophia@comprehension.com>
Date	2026-06-16 02:21 -0500
Message-ID	<110qtho$1nk6$1@nnrp.usenet.blueworldhosting.com>
In reply to	#154174

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.

[toc] | [prev] | [next] | [standalone]

#154180

From	"Carlos E. R." <robin_listas@es.invalid>
Date	2026-06-16 12:30 +0200
Message-ID	<n9cmu2Fas8nU2@mid.individual.net>
In reply to	#154177

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🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154184

From	Maria Sophia <mariasophia@comprehension.com>
Date	2026-06-16 12:07 -0500
Message-ID	<110rvt4$2fpb$1@nnrp.usenet.blueworldhosting.com>
In reply to	#154180

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3 [1] 2 3 Next page →

csiph-web

PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing

Contents

#154108 — PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing

#154134

#154142

#154143

#154147

#154161

#154166

#154167

#154169

#154171

#154195 — Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing

#154196 — Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing

#154168

#154172

#154173

#154179

#154174

#154177

#154180

#154184