Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.mobile.android > #154108 > unrolled thread
| Started by | Maria Sophia <mariasophia@comprehension.com> |
|---|---|
| First post | 2026-06-10 02:07 -0600 |
| Last post | 2026-06-30 21:40 -0400 |
| Articles | 12 on this page of 52 — 10 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 Maria Sophia <mariasophia@comprehension.com> - 2026-06-30 22:12 -0400
Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing "Carlos E. R." <robin_listas@es.invalid> - 2026-07-01 11:51 +0200
Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-07-01 13:57 -0400
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 Maria Sophia <mariasophia@comprehension.com> - 2026-06-30 21:46 -0400
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
Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Nadia Jarvis <invalid@invalid.invalid> - 2026-06-27 19:38 +0100
Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Hank Rogers <Hank@nospam.invalid> - 2026-06-27 19:53 -0500
Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-27 23:01 -0600
Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Maria Sophia <mariasophia@comprehension.com> - 2026-06-30 21:40 -0400
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Maria Sophia <mariasophia@comprehension.com> |
|---|---|
| Date | 2026-06-18 19:19 -0500 |
| Message-ID | <11121tt$3s1e2$1@paganini.bofh.team> |
| In reply to | #154228 |
Carlos E. R. wrote: >> NOTE: I haven't been able to reply because of a news server issue... >> (and paga says "forbidden crosspost" for these two groups >> alt.comp.os.windows-10,comp.mobile.android >> So I'll just post it to the Android newsgroup instead >> since responding to Chris' wrongful insults adds no value anyway. > > There have been no insults, Hi Carlos, While you ignore the incessant insults by Chris against me, and while it's impossible for Chris (or anyone) to insult me, he never stops trying. So I'm allowed to flag them. Because Chris never stops hurling insults toward me every chance he gets. Even when he's dead wrong. And, he's never apologized even though he was dead wrong, as you know. I'm extremely intelligent so when I say something, it is based on facts. I don't bullshit as I call the shots the way they are and I provide proof. 1. Proof that they were insults are in Chris' own words. 2. Proof that my server is having a problem is in the admin response. 3. While Chris is hurling never-ending insults, I'm adding value to the ng. REFERENCES: 1. Proof that they were insults are in Chris' own words, especially as Chris constantly hurls his political insults even as this is not a political newsgroup (and even when he's the one who is wrong). From: Chris <ithinkiam@gmail.com> Newsgroups: comp.mobile.android,alt.comp.os.windows-10 Subject: Re: PSA: Streamlined persistent ADB port over Wi‑Fi without repeated pairing Date: Wed, 17 Jun 2026 18:59:27 -0000 (UTC) Message-ID: <110uqqf$235pk$1@dont-email.me> And, he's gone.... As per usual "the Donald" is only interested in sycophancy or animosity. When an offer for help and advice is made he disengages and runs away. 2. Proof that my server is having a problem is in the admin response. From: Jesse Rehmer <jesse.rehmer@blueworldhosting.com> Newsgroups: alt.free.newsservers Subject: Re: Anyone else getting errors posting to blueworld lately? Date: Thu, 18 Jun 2026 21:18:39 -0000 (UTC) Message-ID: <1111nbe$2t7m2$1@dont-email.me> > I'm getting strange errors in the past two days. > Anyone else? I should have posted, but got swamped and forgot. We'll be down for maintenance for a while longer. New articles weren't making their way to the reader server and I thought it was due to a corrupt history file, so it's currently rebuilding the history file. (Though I later figured out it was a strange issue with Diablo's queue files. Sigh.) 3. While Chris is hurling never-ending insults, I'm adding value to the ng. Newsgroups: comp.mobile.android,alt.comp.os.windows-10,alt.os.linux Subject: PSA: How to capture Android crash logs or app errors & warnings on your desktop using adb & logcat Date: Wed, 17 Jun 2026 01:13:00 -0500 Message-ID: <110tdtc$2qt$1@nnrp.usenet.blueworldhosting.com> Newsgroups: comp.mobile.android Subject: PSA: How to ID from the desktop what just made Android beep (using adb logcat) Date: Wed, 17 Jun 2026 14:53:46 -0500 Message-ID: <110uu09$39vsm$1@paganini.bofh.team> -- Even kind-heartd people who help others have their limits with the trolls.
[toc] | [prev] | [next] | [standalone]
| From | Chris <ithinkiam@gmail.com> |
|---|---|
| Date | 2026-06-19 06:59 +0000 |
| Message-ID | <1112pc9$351qn$1@dont-email.me> |
| In reply to | #154229 |
Maria Sophia <mariasophia@comprehension.com> wrote: > Carlos E. R. wrote: >>> NOTE: I haven't been able to reply because of a news server issue... >>> (and paga says "forbidden crosspost" for these two groups >>> alt.comp.os.windows-10,comp.mobile.android >>> So I'll just post it to the Android newsgroup instead >>> since responding to Chris' wrongful insults adds no value anyway. >> >> There have been no insults, > > Hi Carlos, > > While you ignore the incessant insults by Chris against me Like Carlos says, there have been no insults. Unlike you like to do by calling people stupid. You simply prefer to play victim rather than address genuine criticism or take on valuable insight that doesn't align with your wrongheadedness.
[toc] | [prev] | [next] | [standalone]
| From | Chris <ithinkiam@gmail.com> |
|---|---|
| Date | 2026-06-17 23:32 +0000 |
| Message-ID | <110vaq4$27rb0$1@dont-email.me> |
| In reply to | #154192 |
[resetting follow-ups] Maria Sophia <mariasophia@comprehension.com> wrote: > Chris wrote: >> What help do *you* need to do things properly? > > Find me the web site you claim exists where I can post the tutorials, > PSAs & scripts for others to benefit from that has no account login. Why? You've already stated you're happy to submit to fora which require a login. You're intentionally being awkward simply for the sake of it. There are plenty of pastebin-like solutions, which are one-off links. https://www.geeksforgeeks.org/blogs/top-7-code-sharing-website-for-developers/ However, a more sensible solution is to include some of version control given you're regularly changing your "tutorials" and it makes sense to always point to the most recent (and most correct) version. The model these days revolves around git-like functionality. The de facto standard is github, but there are many others like gitlab, bitbucket, gitea, sourceforge, etc. https://opensource.com/article/18/8/github-alternatives All will need some form of login, but you probably can use throwaway logins or just create multiple for different types of scripts. All unnecessary as thousands of people are able to remain totally anonymous while maintaining longterm histories on github and developing credibility.
[toc] | [prev] | [next] | [standalone]
| From | Maria Sophia <mariasophia@comprehension.com> |
|---|---|
| Date | 2026-06-26 06:38 -0400 |
| Message-ID | <111lkqi$2gvi$1@nnrp.usenet.blueworldhosting.com> |
| In reply to | #154192 |
To further leverage the effort, I posted the latest adbconnect to XDA <https://xdaforums.com/t/this-adbconnect-script-connects-android-to-the-windows-linux-macos-desktop-laptop-in-a-single-step-over-wi-fi-without-using-usb-allowing-reconnect.4792987/> For tactical reasons, the title is keyword rich so it shows up in searches. *This adbconnect script connects Android to the (Windows/Linux/macOS)* *desktop/laptop in a single step over Wi-Fi without using USB* *(allowing reconnect)* I'll add the Linux/macOS scripts separately there so all can benefit. -- Usenet isn't for amusement; it's for learning from and teaching each other.
[toc] | [prev] | [next] | [standalone]
| From | Maria Sophia <mariasophia@comprehension.com> |
|---|---|
| Date | 2026-06-20 02:22 -0500 |
| Message-ID | <1115f42$2l12$1@nnrp.usenet.blueworldhosting.com> |
| In reply to | #154108 |
Maria Sophia wrote:
> PSA:
> Persistent ADB over Wi-Fi without repeated pairing of desktop to Android
UPDATE!
The debug port is a legacy step that ADB no longer strictly requires!
The latest adbconnect script has been working wonderfully, as the goal is
always to reduce everything we do on any computer to a single quick step.
But... the strangest thing happened earlier today...
I found out that the debug port is a legacy port. It's not actually needed.
It was almost like when I found out that gravity isn't actually a force.
And that everything moves at the speed of light through curved spacetime.
So gravity is due to the curvature of time (mostly) & not to space curvature.
Yet, everyone (including me) always thought that gravity was a force.
And that it was due to the curvature of space (mostly) and less so of time.
It's not. And the adb connect step is also not needed either.
All we need is the adb pairing step.
How do I know this (without being a window washer falling off a roof)?
I ran adbconnect but I accidentally mistyped the debug port.
Yet the desktop still connected over Wi-Fi to adb and to scrcpy mirroring.
Huh?
Turns out, the debug port is ... um... er... optional.
Who knew. Not me. Now I do.
All we really need is:
a. Pair over Wi-Fi
b. Run adb tcpip 5555
c. Connect to 5555
d. Launch scrcpy
Pairing port = authentication
Debug port = optional first-connect helper
Once pairing succeeds, ADB has a trusted identity token for the device.
USB connection between phone & desktop:
a. Already trusted
b. No pairing needed
c. No debug port needed
d. We can immediately run adb tcpip 5555
Wi-Fi connection between phone & desktop:
a. We must pair
b. Pairing gives ADB the same trust token USB normally provides
c. After pairing, the debug port becomes optional
Because Wi-Fi pairing replaces the need for USB.
And once paired, the debug port becomes irrelevant.
The debug port is a legacy step that ADB no longer strictly requires.
Yet, when I commented out the debug port, the script logic unexpectedly
broke when re-launching scrcpy (when it was already running). Huh?
Turns out once paired, the PC is permanently authorized to connect to that phone over Wi-Fi, regardless of what port is used next (until rebooted).
In addition, I added logic to detect if scrcpy is already running & if so, to use the existing running connection instead of killing/restarting it.
:: adbconnect.bat (Automate Android-to-desktop Wi-Fi adb/scrcpy connections)
:: Solves two problems when connecting a desktop to adb/scrcpy for Android.
:: 1. Eliminate all useless random-security steps in a Wi-Fi adb connection
:: 2. Eliminate the useless scrcpy console window which just takes up space
:: v1p8 20260619
:: a. The debug port user-input query was removed
:: b. And the pairing to TCP/IP flow was simplified as a result
:: c. Plus, detection of scrcpy already running was added to prevent scrcpy
:: from respawning if it was already running when adbconnect is run.
:: Note: While Wi-Fi pairing replaces the need for the USB cable,
:: once paired, the Android debug port actually becomes irrelevant.
:: Once paired, even if the PC is rebooted, the PC is permanently authorized
:: to connect to that phone over Wi-Fi regardless of the debug port.
:: (ADB pairing only needs to be replenished after the phone has rebooted.)
:: v1p7 20260615
:: Removed the requirement for the "no-console" vbs script
:: by injecting the necessary commands into a temporary file
:: This is the cleanest way I can think of to eliminate the console.
:: v1p6 20260614
:: Called the vbs "no-console" script that comes with adb.
:: If the script isn't there, then it defaults to the old method.
:: The problem is getting completely rid of the scrcpy console isn't working.
:: These are the known scrcpy console-hiding methods:
:: (a) cmd /c start "" /min (minimizes the console)
:: The console is not hidden. It's just minimized.
:: (b) cmd start "" /B (background launch of detached console)
:: This detaches scrcpy from the batch console
:: (c) adb default VBS no-console wrapper (fully hidden window)
:: Default GUI-subsystem scrcpy launch (so no console is created)
:: CreateObject("Wscript.Shell").Run strCommand, 0, False
:: (d) Kleebauer ShowWindow() controller trick to hide the batch console
:: showwin.exe 0 SW_HIDE (Hides the batch console)
:: (e) Powershell ShowWindowAsync (similar idea to Herbert's ShowWindow()
:: Add-Type '[DllImport("user32.dll")]
:: public static extern bool
:: ShowWindowAsync(IntPtr hWnd, int nCmdShow);'
:: Here is the original scrcpy-noconsole.vbs that comes with adb
:: strCommand = "cmd /c scrcpy.exe"
:: For Each Arg In WScript.Arguments
:: strCommand = strCommand & " """ & replace(Arg, """", """""""""") & """"
:: Next
:: CreateObject("Wscript.Shell").Run strCommand, 0, false
:: v1p5 20260613 Added query asking for the LAN IP address of the phone
:: Reordered comments to allow the current version to be obvious
:: v1p4 20260612 minimized the scrcpy console (but it's still there)
:: using cmd /c start "" /min (minimizes the console only)
:: The only known choices are
:: (a) Minimized console-subsystem launch (cmd /c start "" /min)
:: (b) Background detached launch (start "" /B)
:: (c) Hidden GUI-subsystem VBS launcher (no console created)
:: (d) External ShowWindow() console-visibility controller (Kleebauer trick)
:: (e) PowerShell ShowWindowAsync console hider (similar to ShowWindow())
:: v1p3 20260612 moved the pipe outside the FOR command for reliability
:: v1p2 20260611 further reliability improvements added to v1p1
:: Use separate retry counters for pair/connect to avoid loop
:: interference (ATTEMPTS_PAIR, ATTEMPTS_CONN)
:: Added fail-fast with clear error codes and user hints after retry
:: exhaustion
:: Added a detection of the device id after initial connect
:: (handles ephemeral adb ports like 192.168.1.4:54321)
:: Use DEVICE_ID for subsequent -s tcpip command (quoted)
:: to avoid parsing issues with colons
:: Fallback device-id lookup when initial pattern match fails
:: (robust parsing of "adb devices")
:: Consistent quoting of %ADB% and device identifiers to avoid
:: CMD parsing errors
:: v1p1 20260611 reliability improvements added to v1p0
:: Added better device lookup (skip header,ignore blanks,avoid false matches)
:: Added retry logic for adb pair & adb connect (for when phone not ready)
:: Improved polish (consistent quoting, stable scrcpy launch)
:: v1p0 20260611 converted adbconnect.vbs to adbconnect.bat
:: Connects desktop & phone over adb & mirrors phone on the monitor
:: No USB cord is used in this process as it's all done over Wi-Fi
:: Should work even if either the PC and/or the phone is rebooted
:: The script will ask only for the minimum amount of data needed
:: Change the phone static IP address as needed to fit your LAN IP address
@echo off
setlocal enabledelayedexpansion
:: For phones with static IP addresses, change the next line
set PHONE_IP=192.168.1.4
set SCRCPY_OPTS=--keyboard=sdk --always-on-top
echo.
echo === ADB Wireless Auto-Connect ===
echo === [Developer options > Wireless debugging > on] ===
echo.
REM 1. Find adb
for /f "delims=" %%A in ('where adb 2^>nul') do (
if not defined ADB set ADB=%%A
)
if not defined ADB (
echo [ERROR] adb.exe not found.
exit /b
)
REM Ensure .exe extension
if /i not "%ADB:~-4%"==".exe" set ADB=%ADB%.exe
echo Using ADB: "%ADB%"
echo.
REM 2. Check if already connected
echo Checking existing ADB devices...
set DEVICE_ID=
for /f "skip=1 tokens=1" %%I in ('"%ADB%" devices') do (
echo %%I | findstr /R "[0-9]" >nul && (
echo %%I | findstr /I "%PHONE_IP%" >nul && (
if not defined DEVICE_ID set DEVICE_ID=%%I
)
)
)
if defined DEVICE_ID (
echo Already connected on %DEVICE_ID%
goto RUN_TCPIP
)
echo Not connected. Need to pair.
echo.
REM 3. Ask user for pairing info
echo Necessary pairing information will be shown on the phone:
set /p PHONE_IP=Phone IP [%PHONE_IP%] :
set /p PAIR_PORT=Wireless debugging pairing port :
set /p PAIR_CODE=Wireless debugging pairing code :
echo.
echo Pairing with: %PHONE_IP%:%PAIR_PORT%
REM Retry logic for adb pair (3 attempts)
set ATTEMPTS_PAIR=0
:PAIR_RETRY
set /a ATTEMPTS_PAIR+=1
"%ADB%" pair %PHONE_IP%:%PAIR_PORT% %PAIR_CODE%
if errorlevel 1 (
if !ATTEMPTS_PAIR! lss 3 (
echo Pair failed, retrying...
timeout /t 2 >nul
goto PAIR_RETRY
) else (
echo [ERROR] adb pair failed after %ATTEMPTS_PAIR% attempts.
echo Hint: Open Wireless debugging -> "Pair device with pairing code" on the phone, then re-run this script.
exit /b 1
)
)
echo.
:: NEW: Debug port removed in v1p8. Skip directly to TCP/IP mode.
echo Skipping obsolete debug-port connect step...
echo.
:: NEW: After pairing, ADB already trusts the device. Switch directly to TCP/IP.
echo Switching to TCP/IP 5555...
"%ADB%" tcpip 5555
echo.
echo Connecting final port: %PHONE_IP%:5555
"%ADB%" connect %PHONE_IP%:5555
echo.
set DEVICE_ID=%PHONE_IP%:5555
goto RUN_SCRCPY
:RUN_TCPIP
echo Switching device !DEVICE_ID! to TCP/IP 5555...
"%ADB%" -s "%DEVICE_ID%" tcpip 5555
"%ADB%" connect "%PHONE_IP%:5555"
goto RUN_SCRCPY
:RUN_SCRCPY
echo Launching scrcpy completely silent...
:: NEW: Check if scrcpy is already running to avoid killing visible session
tasklist | findstr /I "scrcpy.exe" >nul
if not errorlevel 1 (
echo scrcpy is already running. Skipping relaunch.
echo Done.
exit /b
)
set "VBS_TEMP=%TEMP%\scrcpy_runner.vbs"
:: Build the standalone VBS command string directly into the temp file
echo strCommand = "cmd /c scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%" > "%VBS_TEMP%"
echo CreateObject("Wscript.Shell").Run strCommand, 0, false >> "%VBS_TEMP%"
:: Execute the temporary VBS script
wscript.exe "%VBS_TEMP%"
:: Brief pause to ensure script allocation completes before cleaning up the temp file
timeout /t 1 >nul
if exist "%VBS_TEMP%" del "%VBS_TEMP%"
echo Done.
exit /b
REM end of adbconnect.bat
--
Posted out of the goodness of my heart to help others do what I do.
[toc] | [prev] | [next] | [standalone]
| From | Maria Sophia <mariasophia@comprehension.com> |
|---|---|
| Date | 2026-06-20 02:31 -0500 |
| Message-ID | <1115fjs$875$1@nnrp.usenet.blueworldhosting.com> |
| In reply to | #154250 |
Maria Sophia wrote:
> The debug port is a legacy step that ADB no longer strictly requires!
Here's the Linux equivalent to the Windows script, but I did not test it.
#!/bin/sh
#
# adbconnect.sh
# Wi-Fi-only ADB + scrcpy auto-connect
# Linux bash version of adbconnect.bat
# v1p8 (20260619)
# Mirrors the Windows logic but adapted for Linux shell behavior.
# No debug port is used because adb pairing makes it unnecessary.
#
PHONE_IP="192.168.1.4"
SCRCPY_OPTS="--keyboard=sdk --always-on-top"
echo
echo "=== ADB Wireless Auto-Connect (Linux) ==="
echo "=== [Developer options > Wireless debugging > on] ==="
echo
# 1. Find adb
ADB="$(command -v adb)"
if [ -z "$ADB" ]; then
echo "[ERROR] adb not found in PATH."
exit 1
fi
echo "Using ADB: $ADB"
echo
# 2. Check if already connected
echo "Checking existing ADB devices..."
DEVICE_ID=""
# Skip header line and match only lines containing the phone IP
$ADB devices | tail -n +2 | while read -r line; do
echo "$line" | grep -q "$PHONE_IP" && DEVICE_ID="$(echo "$line" | awk '{print $1}')"
done
# If DEVICE_ID was found, skip pairing
if $ADB devices | grep -q "$PHONE_IP"; then
DEVICE_ID="$PHONE_IP:5555"
echo "Already connected on $DEVICE_ID"
echo "Switching device to TCP/IP 5555..."
$ADB -s "$DEVICE_ID" tcpip 5555
$ADB connect "$PHONE_IP:5555"
echo
# Jump to scrcpy section
else
echo "Not connected. Need to pair."
echo
echo "Necessary pairing information will be shown on the phone."
printf "Phone IP [%s]: " "$PHONE_IP"
read USER_IP
[ -n "$USER_IP" ] && PHONE_IP="$USER_IP"
printf "Wireless debugging pairing port: "
read PAIR_PORT
printf "Wireless debugging pairing code: "
read PAIR_CODE
echo
echo "Pairing with: $PHONE_IP:$PAIR_PORT"
ATTEMPTS_PAIR=0
while true; do
ATTEMPTS_PAIR=$((ATTEMPTS_PAIR + 1))
$ADB pair "$PHONE_IP:$PAIR_PORT" "$PAIR_CODE"
if [ $? -eq 0 ]; then
break
fi
if [ $ATTEMPTS_PAIR -ge 3 ]; then
echo "[ERROR] adb pair failed after $ATTEMPTS_PAIR attempts."
exit 1
fi
echo "Pair failed, retrying..."
sleep 2
done
echo
echo "Switching to TCP/IP 5555..."
$ADB tcpip 5555
echo
echo "Connecting final port: $PHONE_IP:5555"
$ADB connect "$PHONE_IP:5555"
echo
DEVICE_ID="$PHONE_IP:5555"
fi
# 3. Launch scrcpy
echo "Launching scrcpy..."
# NEW: Do not relaunch scrcpy if already running
if pgrep -x "scrcpy" >/dev/null; then
echo "scrcpy is already running. Skipping relaunch."
echo "Done."
exit 0
fi
# Linux scrcpy has no console window to hide, so just run it normally
scrcpy --tcpip="$PHONE_IP" $SCRCPY_OPTS >/dev/null 2>&1 &
echo "Done."
exit 0
# end of adbconnect.sh
--
Posted out of the goodness of my heart to help others do what I do.
[toc] | [prev] | [next] | [standalone]
| From | Maria Sophia <mariasophia@comprehension.com> |
|---|---|
| Date | 2026-06-21 00:53 -0500 |
| Message-ID | <1117u9c$22bi$1@nnrp.usenet.blueworldhosting.com> |
| In reply to | #154250 |
Maria Sophia wrote:
> Turns out once paired, the PC is permanently authorized to connect
> to that phone over Wi-Fi, regardless of what port is used next
> (until the phone is rebooted).
The script is working perfectly to connect the desktop & phone
over Wi-Fi by asking for the bare-minimum connection information.
However... I noted a spurious warning in the output, which shows
up as an error but which is a warning due to the script logic.
After rebooting the desktop & the phone, running it in the morning
C:]> adbconnect
=== ADB Wireless Auto-Connect ===
Using ADB: "C:\app\editor\android\scrcpy\adb.exe"
Checking existing ADB devices...
* daemon not running; starting now at tcp:5037
* daemon started successfully
Not connected. Need to pair.
Necessary pairing information will be shown on the phone:
Phone IP [192.168.1.4] : <return>
Wireless debugging pairing port :45811
Wireless debugging pairing code :359070
Pairing with: 192.168.1.4:45811
Successfully paired to 192.168.1.4:45811 [guid=adb-SERIAL-GUID]
Skipping obsolete debug-port connect step...
Switching to TCP/IP 5555...
error: no devices/emulators found <============huh???
Connecting final port: 192.168.1.4:5555
connected to 192.168.1.4:5555
Launching scrcpy completely silent...
Done.
The updated version below eliminates the adb tcpip 5555 step because
wireless debugging already runs ADB over port 5555 internally anyway.
While I was improving the logic, I removed extraneous connection steps.
:: adbconnect.bat (Automate Android-to-desktop Wi-Fi adb/scrcpy connections)
:: Solves two problems when connecting a desktop to adb/scrcpy for Android.
:: 1. Eliminate all useless random-security steps in a Wi-Fi adb connection
:: 2. Eliminate the useless scrcpy console window which just takes up space
:: v1p9 20260620
:: Added logic to avoid unnecessary reconnect attempts
:: While v1p8 was working flawlessly, an extraneous error showed up:
:: Checking existing ADB devices...
:: * daemon not running; starting now at tcp:5037
:: * daemon started successfully
:: Not connected. Need to pair.
:: Necessary pairing information will be shown on the phone:
:: Phone IP [192.168.1.4] :
:: Wireless debugging pairing port :45811
:: Wireless debugging pairing code :359070
:: Pairing with: 192.168.1.4:45811
:: Successfully paired to 192.168.1.4:45811 [guid=adb-SERIAL-GUID]
:: Skipping obsolete debug-port connect step...
:: Switching to TCP/IP 5555...
:: error: no devices/emulators found
:: Connecting final port: 192.168.1.4:5555
:: connected to 192.168.1.4:5555
:: Launching scrcpy completely silent...
:: Done.
:: This version skips the adb tcpip 5555 step entirely when using
:: wireless debugging pairing because wireless debugging already
:: runs ADB over port 5555 internally so we do not need to switch modes.
:: v1p8 20260619
:: a. The debug port user-input query was removed
:: b. And the pairing to TCP/IP flow was simplified as a result
:: c. Plus, detection of scrcpy already running was added to prevent scrcpy
:: from respawning if it was already running when adbconnect is run.
:: Note: While Wi-Fi pairing replaces the need for the USB cable,
:: once paired, the Android debug port actually becomes irrelevant.
:: Once paired, even if the PC is rebooted, the PC is permanently authorized
:: to connect to that phone over Wi-Fi regardless of the debug port.
:: (ADB pairing only needs to be replenished after the phone has rebooted.)
:: v1p7 20260615
:: Removed the requirement for the "no-console" vbs script
:: by injecting the necessary commands into a temporary file
:: This is the cleanest way I can think of to eliminate the console.
:: v1p6 20260614
:: Called the vbs "no-console" script that comes with adb.
:: If the script isn't there, then it defaults to the old method.
:: The problem is getting completely rid of the scrcpy console isn't working.
:: These are the known scrcpy console-hiding methods:
:: (a) cmd /c start "" /min (minimizes the console)
:: The console is not hidden. It's just minimized.
:: (b) cmd start "" /B (background launch of detached console)
:: This detaches scrcpy from the batch console
:: (c) adb default VBS no-console wrapper (fully hidden window)
:: Default GUI-subsystem scrcpy launch (so no console is created)
:: CreateObject("Wscript.Shell").Run strCommand, 0, False
:: (d) Kleebauer ShowWindow() controller trick to hide the batch console
:: showwin.exe 0 SW_HIDE (Hides the batch console)
:: (e) Powershell ShowWindowAsync (similar idea to Herbert's ShowWindow()
:: Add-Type '[DllImport("user32.dll")]
:: public static extern bool
:: ShowWindowAsync(IntPtr hWnd, int nCmdShow);'
:: Here is the original scrcpy-noconsole.vbs that comes with adb
:: strCommand = "cmd /c scrcpy.exe"
:: For Each Arg In WScript.Arguments
:: strCommand = strCommand & " """ & replace(Arg, """", """""""""") & """"
:: Next
:: CreateObject("Wscript.Shell").Run strCommand, 0, false
:: v1p5 20260613 Added query asking for the LAN IP address of the phone
:: Reordered comments to allow the current version to be obvious
:: v1p4 20260612 minimized the scrcpy console (but it's still there)
:: using cmd /c start "" /min (minimizes the console only)
:: The only known choices are
:: (a) Minimized console-subsystem launch (cmd /c start "" /min)
:: (b) Background detached launch (start "" /B)
:: (c) Hidden GUI-subsystem VBS launcher (no console created)
:: (d) External ShowWindow() console-visibility controller (Kleebauer trick)
:: (e) PowerShell ShowWindowAsync console hider (similar to ShowWindow())
:: v1p3 20260612 moved the pipe outside the FOR command for reliability
:: v1p2 20260611 further reliability improvements added to v1p1
:: Use separate retry counters for pair/connect to avoid loop
:: interference (ATTEMPTS_PAIR, ATTEMPTS_CONN)
:: Added fail-fast with clear error codes and user hints after retry
:: exhaustion
:: Added a detection of the device id after initial connect
:: (handles ephemeral adb ports like 192.168.1.4:54321)
:: Use DEVICE_ID for subsequent -s tcpip command (quoted)
:: to avoid parsing issues with colons
:: Fallback device-id lookup when initial pattern match fails
:: (robust parsing of "adb devices")
:: Consistent quoting of %ADB% and device identifiers to avoid
:: CMD parsing errors
:: v1p1 20260611 reliability improvements added to v1p0
:: Added better device lookup (skip header,ignore blanks,avoid false matches)
:: Added retry logic for adb pair & adb connect (for when phone not ready)
:: Improved polish (consistent quoting, stable scrcpy launch)
:: v1p0 20260611 converted adbconnect.vbs to adbconnect.bat
:: Connects desktop & phone over adb & mirrors phone on the monitor
:: No USB cord is used in this process as it's all done over Wi-Fi
:: Should work even if either the PC and/or the phone is rebooted
:: The script will ask only for the minimum amount of data needed
:: Change the phone static IP address as needed to fit your LAN IP address
@echo off
setlocal enabledelayedexpansion
:: For phones with static IP addresses, change the next line
set PHONE_IP=192.168.1.4
set SCRCPY_OPTS=--keyboard=sdk --always-on-top
echo.
echo === ADB Wireless Auto-Connect ===
echo === [Developer options > Wireless debugging > on] ===
echo.
REM 1. Find adb
for /f "delims=" %%A in ('where adb 2^>nul') do (
if not defined ADB set ADB=%%A
)
if not defined ADB (
echo [ERROR] adb.exe not found.
exit /b
)
REM Ensure .exe extension
if /i not "%ADB:~-4%"==".exe" set ADB=%ADB%.exe
echo Using ADB: "%ADB%"
echo.
REM 2. Check if already connected
echo Checking existing ADB devices...
set DEVICE_ID=
for /f "skip=1 tokens=1" %%I in ('"%ADB%" devices') do (
echo %%I | findstr /R "[0-9]" >nul && (
echo %%I | findstr /I "%PHONE_IP%" >nul && (
if not defined DEVICE_ID set DEVICE_ID=%%I
)
)
)
if defined DEVICE_ID (
echo Already connected on %DEVICE_ID%
goto RUN_TCPIP
)
echo Not connected. Need to pair.
echo.
REM 3. Ask user for pairing info
echo Necessary pairing information will be shown on the phone:
set /p PHONE_IP=Phone IP [%PHONE_IP%] :
set /p PAIR_PORT=Wireless debugging pairing port :
set /p PAIR_CODE=Wireless debugging pairing code :
echo.
echo Pairing with: %PHONE_IP%:%PAIR_PORT%
REM Retry logic for adb pair (3 attempts)
set ATTEMPTS_PAIR=0
:PAIR_RETRY
set /a ATTEMPTS_PAIR+=1
"%ADB%" pair %PHONE_IP%:%PAIR_PORT% %PAIR_CODE%
if errorlevel 1 (
if !ATTEMPTS_PAIR! lss 3 (
echo Pair failed, retrying...
timeout /t 2 >nul
goto PAIR_RETRY
) else (
echo [ERROR] adb pair failed after %ATTEMPTS_PAIR% attempts.
echo Hint: Open Wireless debugging -> "Pair device with pairing code" on the phone, then re-run this script.
exit /b 1
)
)
echo.
:: NEW: Debug port removed in v1p8. Skip directly to TCP/IP mode.
echo Skipping obsolete debug-port connect step...
echo.
:: NEW: After pairing, ADB already trusts the device. Switch directly to TCP/IP.
:: Removed in v1p9
:: echo Switching to TCP/IP 5555...
:: "%ADB%" tcpip 5555
:: Added in v1p9 After pairing, ADB already trusts the device.
:: No tcpip mode is needed.
echo Wireless debugging active. Skipping tcpip 5555 step...
echo.
:: Added this already-connected check in v1p9
:: Check if device is already connected wirelessly
for /f "skip=1 tokens=1" %%I in ('"%ADB%" devices"') do (
echo %%I | findstr /I "%PHONE_IP%" >nul && (
echo Already connected wirelessly on %%I
set DEVICE_ID=%%I
goto RUN_SCRCPY
)
)
echo Connecting final port: %PHONE_IP%:5555
"%ADB%" connect %PHONE_IP%:5555
echo.
set DEVICE_ID=%PHONE_IP%:5555
goto RUN_SCRCPY
:: This secion only applies to USB debugging, not wireless debugging.
:RUN_TCPIP
echo Switching device !DEVICE_ID! to TCP/IP 5555...
"%ADB%" -s "%DEVICE_ID%" tcpip 5555
"%ADB%" connect "%PHONE_IP%:5555"
goto RUN_SCRCPY
:RUN_SCRCPY
echo Launching scrcpy completely silent...
:: NEW: Check if scrcpy is already running to avoid killing visible session
tasklist | findstr /I "scrcpy.exe" >nul
if not errorlevel 1 (
echo scrcpy is already running. Skipping relaunch.
echo Done.
exit /b
)
set "VBS_TEMP=%TEMP%\scrcpy_runner.vbs"
:: Build the standalone VBS command string directly into the temp file
echo strCommand = "cmd /c scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%" > "%VBS_TEMP%"
echo CreateObject("Wscript.Shell").Run strCommand, 0, false >> "%VBS_TEMP%"
:: Execute the temporary VBS script
wscript.exe "%VBS_TEMP%"
:: Brief pause to ensure script allocation completes before cleaning up the temp file
timeout /t 1 >nul
if exist "%VBS_TEMP%" del "%VBS_TEMP%"
echo Done.
exit /b
REM end of adbconnect.bat
--
Usenet is where kind people daily gather to voluntarily help others.
[toc] | [prev] | [next] | [standalone]
| From | Maria Sophia <mariasophia@comprehension.com> |
|---|---|
| Date | 2026-06-27 08:58 -0400 |
| Message-ID | <111ohcu$2qlo$1@nnrp.usenet.blueworldhosting.com> |
| In reply to | #154108 |
UPDATE!
Things have drastically changed for the better! Ports are not needed!
Aurgh. I just found out, by accident, that Android 12+ introduced a *new*
way to connect to adb over Wi-Fi that does not need pairing or debug ports.
So the previous script will work to connect over the LAN for Android 11+,
but this works on Android 12+ because of the new TLS design, which...
a. bypasses pairing
b. bypasses USB authorization
c. bypasses debug ports
d. auto-connects whenever ADB restarts
Android added a second Wi-Fi ADB system called ADB-over-TLS Auto-Discovery.
It is fundamentally completely different from classic Wireless Debugging.
What's DIFFERENT is Wi-Fi ADB-over-TLS Auto-Discovery works even when
a. USB is dead
b. We never paired
c. No pairing code appears
d. No debug ports are open
e. Wireless Debugging toggle is OFF or ON
f. We never authorized the desktop PC
When the desktop PC's ADB server starts, it automatically:
a. Scans the LAN for TLS ADB devices
b. Finds the phone (if the phone's broadcast is awake)
c. Connects with no pairing
d. Shows it as:
adb-SERIAL-GUID._adb-tls-connect._tcp device
This TLS connection:
a. uses encrypted channels
b. uses dynamic ports (which we do not need to know)
c. requires no pairing
d. requires no USB authorization
e. works even if Wireless Debugging toggle is OFF after reboot
Even though ADB shows the TLS device as "device", scrcpy will fail unless
the connection is converted to TCP/IP mode because scrcpy only supports
a. USB
b. Classic TCP/IP ADB (port 5555)
While scrcpy cannot use this TLS device directly, scrcpy *can* use it
indirectly by switching it to classic TCP/IP mode (port 5555).
The simple solution is to convert TLS to TCP/IP (port 5555):
adb -s adb-SERIAL-GUID._adb-tls-connect._tcp tcpip 5555
This forces Android to:
a. drop the TLS session
b. start the classic ADB-over-WiFi daemon
c. open port 5555
d. stay reachable on 5555 until the PHONE reboots
Then this simple sequence works every time:
adb connect PHONE_IP:5555
scrcpy --tcpip=PHONE_IP
The caveat is that the TLS ADB service is flaky. It can:
a. go idle
b. stop advertising
c. come back as "offline"
d. restart only when Wireless Debugging is toggled OFF -> ON
We can write a launcher to avoid this TLS flakiness by:
a. killing the PC ADB server
b. disconnecting all devices
c. reconnecting only to 5555
This removes the TLS ghost device entirely.
Below is the first rev of a vbs script for Windows 10 (Linux can be added
later) which connects without USB and without knowing any pairing ports!
:: adbconnecttls.bat
:: Connects Android 12+ to adb & scrcpy WITHOUT needing any information!
:: v1p0 (Android 12+ TLS-to-TCPIP scrcpy launcher)
:: Simplest possible Wi-Fi scrcpy launcher for Android 12+ devices that
:: auto-advertise ADB-over-TLS. This script avoids pairing, avoids USB,
:: avoids debug ports, and avoids the TLS "ghost device" problem.
:: Android 12+ added a new ADB system called ADB-over-TLS Auto-Discovery.
:: It broadcasts on the LAN using mDNS as:
:: _adb-tls-connect._tcp
:: The desktop ADB server auto-connects to this TLS service with:
:: adb-SERIAL-GUID._adb-tls-connect._tcp
:: This TLS connection:
:: a. bypasses pairing
:: b. bypasses USB authorization
:: c. bypasses debug ports
:: d. auto-connects whenever ADB restarts
:: BUT scrcpy cannot use TLS directly. It only supports:
:: a. USB
:: b. Classic TCP/IP ADB (port 5555)
:: Note this script has no need for pairing or debug ports.
:: This script does not require USB nor does it depend on TLS being awake.
:: But Android's TLS ADB service is rather flaky in that it can:
:: a. go idle
:: b. stop advertising
:: c. return as "offline"
:: d. require Wireless Debugging toggle OFF->ON to wake up
:: So this script avoids TLS entirely by connecting only to port 5555.
:: This script:
:: 1. Kills the ADB server (removes stale TLS sessions)
:: 2. Starts the ADB server cleanly
:: 3. Disconnects all devices (removes TLS ghost device)
:: 4. Connects directly to PHONE_IP:5555
:: 5. Launches scrcpy silently using classic TCP/IP mode
:: Running "adb -s <tls-id> tcpip 5555" forces Android to open port 5555
:: even when Wireless Debugging is ON. Once opened, port 5555 stays active
:: until the PHONE reboots. This makes reconnections simple and stable.
@echo off
setlocal enabledelayedexpansion
echo ============================================
echo ADB-over-TLS to TCP/IP Launcher (Debug Mode)
echo ============================================
echo.
:: Set your phone IP here
set PHONE_IP=192.168.1.4
set SCRCPY_OPTS=--keyboard=sdk --always-on-top
echo STEP 1: adb kill-server
echo adb kill-server
adb kill-server
echo.
echo STEP 2: adb start-server
echo adb start-server
adb start-server
echo.
echo STEP 3: adb disconnect (kills TLS ghost)
echo adb disconnect
adb disconnect
echo.
echo STEP 4: adb connect %PHONE_IP%:5555
echo adb connect %PHONE_IP%:5555
adb connect %PHONE_IP%:5555
echo.
echo STEP 5: Launch scrcpy silently
set VBS_TEMP=%TEMP%\scrcpy_tls_runner.vbs
echo strCommand = "cmd /c scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%" > "%VBS_TEMP%"
echo CreateObject("Wscript.Shell").Run strCommand, 0, false >> "%VBS_TEMP%"
echo Running: scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%
wscript.exe "%VBS_TEMP%"
echo.
echo Done.
echo.
endlocal
exit /b
:: end of adbconnecttls.bat
--
Usenet isn't for amusement; it's for learning from and teaching each other.
[toc] | [prev] | [next] | [standalone]
| From | Nadia Jarvis <invalid@invalid.invalid> |
|---|---|
| Date | 2026-06-27 19:38 +0100 |
| Message-ID | <CRU%R.4397$DU%1.147@fx04.iad> |
| In reply to | #154297 |
On 27/06/2026 13:58, Maria Sophia wrote: > Things have drastically changed for the better! Ports are not needed! Does this mean that Israel won't require the ports of Haifa and Ashdod? Could you please explain? It seems that Israel wasted money on creating a new port at Ashdod in 1965. They could just use Android phones to transport cargo and run their economy.
[toc] | [prev] | [next] | [standalone]
| From | Hank Rogers <Hank@nospam.invalid> |
|---|---|
| Date | 2026-06-27 19:53 -0500 |
| Message-ID | <111prbc$3af9d$1@dont-email.me> |
| In reply to | #154298 |
Nadia Jarvis wrote on 6/27/2026 1:38 PM: > On 27/06/2026 13:58, Maria Sophia wrote: >> Things have drastically changed for the better! Ports are not needed! > > Does this mean that Israel won't require the ports of Haifa and Ashdod? > Could you please explain? > > It seems that Israel wasted money on creating a new port at Ashdod in > 1965. They could just use Android phones to transport cargo and run > their economy. Be patient. Mary will fix all the ports for the poor long suffering jews. Maybe she will even give them some money to make them happy.
[toc] | [prev] | [next] | [standalone]
| From | Maria Sophia <mariasophia@comprehension.com> |
|---|---|
| Date | 2026-06-27 23:01 -0600 |
| Message-ID | <111q9s0$3vovh$1@news.tcpreset.net> |
| In reply to | #154299 |
Hank Rogers wrote:
> fix all the ports
Good news.
Thanks to the advice in this ng, I've removed all the ports completely.
There's now no need to look at the Wireless debugging ports ever again!
I'm overjoyed with the poorly documented new Android 12+ ability to connect
the phone to adb/scrcpy over Wi-Fi without needing to know any ports!
This may be the best documention on the planet for that, for all I know!
Below is a debug script to help others figure out their adb daemon status.
adbdebugtls.bat (Linux/macOS will come later, after full testing is done)
This reports adb daemon status on the phone:
$ adb devices
a. device -> ADB daemon is alive and authenticated
b. offline -> ADB daemon is alive but handshake failed
c. unauthorized -> ADB daemon alive but waiting for authorization
d. (empty) -> ADB daemon is asleep or not advertising
e. adb-SERIAL._adb-tls-connect._tcp -> TLS advertiser is awake
f. 192.168.x.x:5555 -> classic TCP/IP daemon is awake
This gives internal daemon state for reachable devices:
$ adb shell getprop init.svc.adbd
a. running -> ADB daemon is active
b. stopped -> daemon is not running
c. restarting -> daemon is restarting (rare)
This checks whether Android 12+ TCP mode is active:
$ adb shell getprop service.adb.tcp.port
a. 5555 -> classic TCP/IP mode active
b. -1 or empty -> TCP mode off
This checks whether ADB is enabled:
$ adb shell getprop ro.adb.secure
a. 1 -> secure ADB enabled
b. 0 -> insecure ADB (rare on modern devices )
This checks whether the Android 12+ TLS advertiser is awake:
$ adb mdns services
adb-SERIAL-GUID._adb-tls-connect._tcp
a. Entry present -> TLS daemon is awake
b. Entry missing -> TLS daemon is asleep
c. Entry present but adb devices empty -> TLS handshake failed
Note that is the most important check as it often falls asleep!
This tests whether the classic TCP/IP daemon is alive:
$ adb connect 192.168.1.4:5555
a. connected -> TCP daemon alive
b. unable to connect -> TCP daemon not running
c. no route to host -> phone not on LAN
d. connection refused -> port 5555 closed
Here's a manual test of the commands while Android 12+ is connected.
C:\> adbconnecttls.bat
============================================
ADB-over-TLS to TCP/IP Launcher (Debug Mode)
============================================
STEP 1: adb kill-server
adb kill-server
STEP 2: adb start-server
adb start-server
* daemon not running; starting now at tcp:5037
* daemon started successfully
STEP 3: adb disconnect (kills TLS ghost)
adb disconnect
disconnected everything
STEP 4: adb connect 192.168.1.4:5555
adb connect 192.168.1.4:5555
connected to 192.168.1.4:5555
STEP 5: Launch scrcpy silently
Running: scrcpy.exe --tcpip=192.168.1.4 --keyboard=sdk
Done.
C:\> adb devices
List of devices attached
192.168.1.4:5555 device
C:\> adb shell getprop init.svc.adbd
running
C:\> adb shell getprop service.adb.tcp.port
5555
C:\> adb shell getprop ro.adb.secure
1
C:\> adb mdns services
List of discovered mdns services
adb-SERIAL_adb._tcp 192.168.1.4:5555
adb-SERIAL-GUID_adb-tls-connect._tcp 192.168.1.4:36401
Note that the TLS advertiser (_adb-tls-connect._tcp) is part of:
com.android.adb.adbd
Which is flaky because this service goes idle on the phone when:
a. Wireless Debugging hasn't been toggled recently
b. The phone has been idle
c. The system kills the advertiser to save power
d. The ADB daemon restarts internally
e. Wi-Fi reconnects
f. The phone roams between APs
When the TLS advertiser sleeps, adb mdns services returns nothing.
When that happens there are 3 reliable ways to wake the TLS advertiser:
a. Toggle Wireless Debugging OFF -> ON
b. Restart the ADB daemon on the phone
That works only if you already have a connection (USB or TCP)
c. Force ADB to reconnect via TCP/IP
This is the trick the adbconnecttls.bat launcher uses:
i. adb kill-server
ii. adb start-server
iii. adb disconnect
iv. adb connect PHONE_IP:5555
That does not wake TLS because it bypasses TLS entirely
which is done because scrcpy can't use TLS as far as I know.
This script below provides ADB-over-TLS, TCP/IP mode diagnostics
including adbd state, Wireless Debugging state & scrcpy readiness.
@echo off
setlocal enabledelayedexpansion
:: adbdebugtls.bat (Android 12+ ADB/TLS Diagnostic Tool)
:: Runs a full diagnostic of ADB-over-TLS, TCP/IP mode, adbd state,
:: Wireless Debugging state, and scrcpy readiness for Android 12+.
::
:: v1p0 20260627
:: Diagnose the state of Android's ADB daemon on Android 12+ devices,
:: including TLS advertiser status, TCP/IP mode, adbd internal state,
:: Wireless Debugging service state and scrcpy readiness.
::
:: Android 12+ introduced ADB-over-TLS Auto-Discovery, which broadcasts
:: on the LAN using mDNS as:
:: _adb-tls-connect._tcp
:: The desktop ADB server auto-connects to this TLS service as:
:: adb-SERIAL._adb-tls-connect._tcp
:: This TLS system:
:: a. bypasses pairing
:: b. bypasses USB authorization
:: c. bypasses debug ports
:: d. auto-connects whenever ADB restarts
:: But scrcpy cannot use TLS directly. It only supports:
:: a. USB
:: b. Classic TCP/IP ADB (port 5555)
:: Hence, this script checks:
:: 1. TLS advertiser status (adb mdns services)
:: 2. TCP/IP connectivity on port 5555
:: 3. adbd internal state via getprop
:: 4. Wireless Debugging service state via dumpsys
:: Note Samsung may hide or rename the Wireless Debugging service.
:: 5. scrcpy readiness (device state)
:: Note the wake attempts when the phone TLS service goes asleep.
:: i. Restarting the PC ADB server
:: ii. Restarting adbd on the phone (if reachable)
:: iii. Forcing TCP/IP fallback on port 5555
:: Note Android does not expose a command to toggle Wireless Debugging.
:: So the TLS advertiser cannot be automaticaly awakened from ADB.
:: Hence, this script reports TLS sleep but cannot force it awake.
::
echo ============================================
echo ADB Debug Tool (Android 12+ TLS Diagnostic)
echo ============================================
echo.
:: Set your phone IP here
set PHONE_IP=192.168.1.4
echo.
echo === 1. Restart PC ADB Server ===
echo adb kill-server
adb kill-server
echo adb start-server
adb start-server
echo.
echo.
echo === 2. TLS Status (mDNS Advertiser) ===
echo Command: adb mdns services
adb mdns services | findstr /I "_adb-tls-connect._tcp"
if errorlevel 1 (
echo TLS advertiser is asleep or not broadcasting.
) else (
echo TLS advertiser is active.
)
echo.
echo.
echo === 3. TCP/IP Status (Port 5555) ===
echo Command: adb connect %PHONE_IP%:5555
adb connect %PHONE_IP%:5555
echo.
echo Command: adb devices
adb devices
echo.
echo.
echo === 4. Attempting to Wake adbd (if reachable) ===
echo Trying: adb shell stop adbd
adb shell stop adbd 2>nul
echo Trying: adb shell start adbd
adb shell start adbd 2>nul
echo.
echo.
echo === 5. adbd Internal State ===
echo Command: adb shell getprop init.svc.adbd
adb shell getprop init.svc.adbd
echo.
echo Command: adb shell getprop service.adb.tcp.port
adb shell getprop service.adb.tcp.port
echo.
echo Command: adb shell getprop ro.adb.secure
adb shell getprop ro.adb.secure
echo.
echo.
echo === 6. Wireless Debugging State ===
echo Command: adb shell dumpsys activity service ^
com.android.adb.adbd
adb shell dumpsys activity service com.android.adb.adbd
echo.
echo.
echo === 7. scrcpy Readiness Check ===
echo If device shows as "device", scrcpy can run.
echo If port 5555 is active, scrcpy --tcpip works.
echo.
echo Command: adb devices
adb devices
echo.
echo ============================================
echo Diagnostics complete.
echo ============================================
endlocal
exit /b
:: end of adbdebugtls.bat
--
Usenet isn't for amusement - it allows intelligent people to share ideas.
Some invest seconds to post stupid jokes but it takes hours to add value.
[toc] | [prev] | [next] | [standalone]
| From | Maria Sophia <mariasophia@comprehension.com> |
|---|---|
| Date | 2026-06-30 21:40 -0400 |
| Message-ID | <1121r6q$ug7$1@nnrp.usenet.blueworldhosting.com> |
| In reply to | #154300 |
In the beginning, I used USB to connect adb & scrcpy to the desktop PC.
Then in Android 11 I used Wi-Fi pairing with the pairing & debug port.
In Android 12, the ability to pair without knowing the ports was added.
In using the script to pair without knowing the ports, I've run into a bunch of situations depending on the state of the phone & the computer.
Hopefully I've added everything possible to this latest script for you.
Note it doesn't use TLS, per se, but TLS controls adb's reachability.
:: adbconnecttls.bat
:: Connects Android 12+ to adb & scrcpy WITHOUT needing any information!
::
:: This script launches scrcpy over classic TCPIP mode on Android 12
:: and newer devices. It does not use TLS for the scrcpy connection,
:: but it depends on the Wireless Debugging TLS service being awake
:: because TLS controls whether adbd is reachable. The script resets
:: the ADB server, removes stale TLS ghost sessions, checks TLS
:: advertiser state, tests TCPIP reachability, verifies USB debugging
:: authorization and attempts a direct connection to port 5555. It
:: then launches scrcpy silently and detects whether the connection
:: succeeded. If TLS is asleep, TCPIP is active but refusing
:: connections, USB debugging is authorized and scrcpy fails, the
:: script reports that the phone is in ADB Deep Sleep and instructs
:: the user to toggle Wireless debugging or reboot the phone to wake
:: adbd.
::
:: v1p4 20260630
:: Added deep sleep detector
::
:: v1p3 20260630
:: Added TCP/IP sleep detector and USB authorization detector
::
:: v1p2 20260630
:: Added detection and reporting if scrcpy didn't launch
::
:: v1p1 20260630
:: Added version string
:: Added TLS sleep detection
:: Added user guidance when TLS is asleep
:: Removed parentheses and arrows from comments
:: Cleaned formatting for stability
::
:: v1p0 20260601
:: Simplest possible Wi-Fi scrcpy launcher for Android 12+ devices that
:: auto-advertise ADB-over-TLS. This script avoids pairing, avoids USB,
:: avoids debug ports, and avoids the TLS "ghost device" problem.
:: Android 12+ added a new ADB system called ADB-over-TLS Auto-Discovery.
:: It broadcasts on the LAN using mDNS as:
:: _adb-tls-connect._tcp
:: The desktop ADB server auto-connects to this TLS service with:
:: adb-SERIAL-GUID._adb-tls-connect._tcp
:: This TLS connection:
:: a. bypasses pairing
:: b. bypasses USB authorization
:: c. bypasses debug ports
:: d. auto-connects whenever ADB restarts
:: BUT scrcpy cannot use TLS directly. It only supports:
:: a. USB
:: b. Classic TCP/IP ADB (port 5555)
:: Note this script has no need for pairing or debug ports.
:: This script does not require USB nor does it depend on TLS being awake.
:: But Android's TLS ADB service is rather flaky in that it can:
:: a. go idle
:: b. stop advertising
:: c. return as "offline"
:: d. require Wireless Debugging toggle OFF->ON to wake up
:: So this script avoids TLS entirely by connecting only to port 5555.
:: This script:
:: 1. Kills the ADB server (removes stale TLS sessions)
:: 2. Starts the ADB server cleanly
:: 3. Disconnects all devices (removes TLS ghost device)
:: 4. Connects directly to PHONE_IP:5555
:: 5. Launches scrcpy silently using classic TCP/IP mode
:: Running "adb -s <tls-id> tcpip 5555" forces Android to open port 5555
:: even when Wireless Debugging is ON. Once opened, port 5555 stays active
:: until the PHONE reboots. This makes reconnections simple and stable.
@echo off
setlocal enabledelayedexpansion
:: Version string
set SCRIPT_VERSION=v1p4
set SCRIPT_DATE=20260630
echo ============================================
echo ADB-over-TLS to TCPIP Launcher Debug Mode
echo Running adbconnecttls.bat %SCRIPT_VERSION% %SCRIPT_DATE%
echo ============================================
echo.
:: Set your phone IP here
set PHONE_IP=192.168.1.4
set SCRCPY_OPTS=--keyboard=sdk
echo STEP 1: adb kill-server
echo adb kill-server
adb kill-server
echo.
echo STEP 2: adb start-server
echo adb start-server
adb start-server
echo.
echo STEP 3: adb disconnect to remove TLS ghost
echo adb disconnect
adb disconnect
echo.
echo STEP 4: Check TLS advertiser status
echo Command: adb mdns services
adb mdns services | findstr /I "_adb-tls-connect._tcp" >nul
if errorlevel 1 (
echo.
echo TLS advertiser is ASLEEP.
echo Wireless Debugging is ON but the phone is not broadcasting TLS.
echo.
echo Meaning:
echo The phone cannot auto-connect over TLS.
echo The PC cannot wake the phone via TLS.
echo.
echo Fix:
echo On the phone, toggle Wireless debugging OFF then ON.
echo Or reboot the phone to restart Wireless Debugging.
echo.
echo After waking TLS, re-run adbconnecttls.bat.
echo.
) else (
echo TLS advertiser is ACTIVE.
echo The phone is broadcasting TLS normally.
)
echo.
echo STEP 5: adb connect %PHONE_IP%:5555
echo adb connect %PHONE_IP%:5555
adb connect %PHONE_IP%:5555
echo.
echo Checking TCPIP mode...
adb connect %PHONE_IP%:5555 >nul
:: Added TCP/IP sleep detector and USB authorization detector in v1p3
if errorlevel 1 (
echo.
echo TCPIP mode is ASLEEP.
echo The phone refused the TCPIP connection.
echo adbd is asleep or Wireless Debugging is asleep.
echo.
echo Fix:
echo On the phone, toggle Wireless debugging OFF then ON.
echo Or reboot the phone to restart Wireless Debugging.
echo.
echo After waking TLS, re-run adbconnecttls.bat.
echo.
) else (
echo TCPIP mode is ACTIVE.
)
echo Checking USB authorization...
adb devices | findstr /I "device" | findstr /V ":" >nul
if errorlevel 1 (
echo.
echo USB debugging is NOT authorized.
echo USB is connected but the phone is not authorized for ADB.
echo.
echo Fix:
echo Unlock the phone and press Allow USB debugging.
echo.
) else (
echo USB debugging is authorized.
)
echo STEP 6: Launch scrcpy silently
set VBS_TEMP=%TEMP%\scrcpy_tls_runner.vbs
echo strCommand = "cmd /c scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%" > "%VBS_TEMP%"
echo CreateObject("Wscript.Shell").Run strCommand, 0, false >> "%VBS_TEMP%"
echo Running: scrcpy.exe --tcpip=%PHONE_IP% %SCRCPY_OPTS%
wscript.exe "%VBS_TEMP%"
:: Detect if scrcpy didn't launch and suggest a fix v1p2
echo Checking if scrcpy connected...
adb devices | findstr /I "%PHONE_IP%" >nul
if errorlevel 1 (
echo.
echo scrcpy did NOT connect.
echo.
echo Meaning:
echo The phone did not accept TCPIP connection.
echo adbd is asleep or Wireless Debugging is asleep.
echo.
echo Fix:
echo On the phone, toggle Wireless debugging OFF then ON.
echo Or reboot the phone to restart Wireless Debugging.
echo.
echo After waking TLS, re-run adbconnecttls.bat.
echo.
) else (
echo scrcpy connected successfully.
echo.
echo scrcpy is running over TCP/IP.
echo Connection successful.
echo.
goto :EOF
)
echo.
echo Done.
echo.
endlocal
exit /b
:: end of adbconnecttls.bat
--
For some people, Usenet is amusement, but for me, it's for adding value.
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.mobile.android
csiph-web