Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #82796 > unrolled thread

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

Back to article view | Back to alt.os.linux

Contents

  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 Give It A Try <try.it@invalid.invalid> - 2026-06-12 23:20 +0100
          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 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

Page 2 of 2 — ← Prev page 1 [2]

#82823

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]

#82825

On 2026-06-16 19:07, Maria Sophia wrote:
> Carlos E. R. wrote:
>>> C'mon. You're actually complaining that I provided fully working Windows
>>> scripts, and that I improved them, and that I ported them to Linux for you?
>>
>> You do not understand the criticism.
> 
> If Chris had even once in his entire life ever invested the time and energy
> to post a working tutorial or PSA or working code that he labored on to
> help himself and others, I'd understand better his complaint that he can't.

Accusing others doesn't change facts.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

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

#82826

Carlos E. R. wrote:
> On 2026-06-16 19:07, Maria Sophia wrote:
>> Carlos E. R. wrote:
>>>> C'mon. You're actually complaining that I provided fully working Windows
>>>> scripts, and that I improved them, and that I ported them to Linux for you?
>>>
>>> You do not understand the criticism.
>> 
>> If Chris had even once in his entire life ever invested the time and energy
>> to post a working tutorial or PSA or working code that he labored on to
>> help himself and others, I'd understand better his complaint that he can't.
> 
> Accusing others doesn't change facts.

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

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

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

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

 README: adbconnect.bat
 Automate Android-to-desktop Wi-Fi adb and scrcpy connections
 
 1. Purpose
    A. This script automates connecting a desktop to an Android phone over
       Wi-Fi using adb and scrcpy on your local LAN (in a single step).
    B. It removes unnecessary pairing steps normally required by adb/scrcpy
    C. It launches scrcpy without leaving a console window visible.
 
 2. What the script solves
    A. Eliminates repeated manual pairing steps for Wi-Fi adb.
    B. Avoids the scrcpy console window by generating a temporary VBS
       launcher that runs scrcpy in a hidden window.
    C. Handles device discovery, retries, and fallback logic so the
       connection works even after reboots.
 
 3. How it works
    A. Finds adb automatically on the system path.
    B. Checks whether the phone is already connected.
    C. If not connected, it asks for:
       a. Phone IP address
       b. Pairing port
       c. Pairing code
       d. Debug port
    D. Performs adb pair with retry logic.
    E. Performs adb connect with retry logic.
    F. Detects the actual device id reported by adb, including ephemeral
       ports.
    G. Switches the device to tcpip mode on port 5555.
    H. Connects again on port 5555 for the final stable link.
    I. Builds a temporary VBS file that launches scrcpy silently.
    J. Runs the VBS file, then deletes it.
 
 4. Version history summary
    A. v1p7
       a. Removes dependency on the external no-console VBS file.
       b. Generates a temporary VBS launcher instead.
    B. v1p6
       a. Used the official scrcpy-noconsole.vbs when available.
    C. v1p5
       a. Added prompt for phone LAN IP.
    D. v1p4
       a. Minimized scrcpy console but could not hide it fully.
    E. v1p3
       a. Improved device lookup reliability.
    F. v1p2
       a. Added separate retry counters, fail-fast behavior,
          and added a much more robust device-id parsing.
    G. v1p1
       a. Improved device lookup and retry logic.
    H. v1p0
       a. First batch version replacing the older VBS script.
 
 5. Requirements (root is not required)
    A. Android phone with Wireless debugging enabled.
    B. Desktop with adb and scrcpy installed.
    C. Phone reachable on LAN over Wi-Fi via its IP address.
 
 6. Typical workflow
    A. Run the script.
    B. If already connected, it switches to tcpip mode & launches scrcpy.
    C. If not connected, it asks for pairing info and completes the
       connection automatically.
    D. scrcpy Android mirroring appears without any console window.
 
 7. Notes
    A. The script uses only temporary files and cleans them up.
    B. It avoids all non-essential console output.
    C. It is designed to be safe to run repeatedly.
    D. A Linux port has been provided, but is as yet untested.
-- 
There are people who spend inordinate energy always helping others.

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

#82827

On 2026-06-16 21:40, Maria Sophia wrote:
> Carlos E. R. wrote:
>> On 2026-06-16 19:07, Maria Sophia wrote:
>>> Carlos E. R. wrote:
>>>>> C'mon. You're actually complaining that I provided fully working Windows
>>>>> scripts, and that I improved them, and that I ported them to Linux for you?
>>>>
>>>> You do not understand the criticism.
>>>
>>> If Chris had even once in his entire life ever invested the time and energy
>>> to post a working tutorial or PSA or working code that he labored on to
>>> help himself and others, I'd understand better his complaint that he can't.
>>
>> Accusing others doesn't change facts.
> 
> Well, I'm going to ask *you* to provide something that is worth value.
> 
> Given I've posted, oh, I don't know, hundreds of useful scripts...
> Q: What specific web site do you suggest I post the final script to?

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

I have never done this, so I can not advise

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

>     a. It needs to have no requirement for a login/account
>     b. It needs to be free
>     c. It needs to be easy to post to (and to update, if necessary)?
> A: ???
> 
> To help you add value (instead of just complaining I add too much value),
> all I ask you to do is answer the question above so that I can post it.
> 
> Here's a README description of how it simplifies Wi-Fi adb/scrcpy usage
> which should help you find the location you claim I should post it to.
> 

No, this is not relevant to the question.


-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

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

#82828

Carlos E. R. wrote:
>> Given I've posted, oh, I don't know, hundreds of useful scripts...
>> Q: What specific web site do you suggest I post the final script to?
> 
> Up to you, and it wasn't my idea, anyway :-)
> 
> I have never done this, so I can not advise
> 
> You could use github, or hire a server of your own somewhere. Or set up 
> a server at home. Sourceforge, perhaps (this one I have used).

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

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

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

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

#82836

On 2026-06-16 22:51, Maria Sophia wrote:
> Carlos E. R. wrote:
>>> Given I've posted, oh, I don't know, hundreds of useful scripts...
>>> Q: What specific web site do you suggest I post the final script to?
>>
>> Up to you, and it wasn't my idea, anyway :-)
>>
>> I have never done this, so I can not advise
>>
>> You could use github, or hire a server of your own somewhere. Or set up
>> a server at home. Sourceforge, perhaps (this one I have used).
> 
> The point of the rhetorical question is that it likely doesn't exist.

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

> 
> Only Usenet will allow me to post the code sans creating a login/account.
> 
> So Chris is asking me to do that which nobody can do, as far as we know.

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

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

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

#82837

Carlos E. R. wrote on 6/17/2026 5:45 PM:
> On 2026-06-16 22:51, Maria Sophia wrote:
>> Carlos E. R. wrote:
>>>> Given I've posted, oh, I don't know, hundreds of useful scripts...
>>>> Q: What specific web site do you suggest I post the final script to?
>>>
>>> Up to you, and it wasn't my idea, anyway :-)
>>>
>>> I have never done this, so I can not advise
>>>
>>> You could use github, or hire a server of your own somewhere. Or set up
>>> a server at home. Sourceforge, perhaps (this one I have used).
>>
>> The point of the rhetorical question is that it likely doesn't exist.
> 
> Oh, yes, they do exist. Many. But you will not like any of them, as they 
> serve to find you.
> 
>>
>> Only Usenet will allow me to post the code sans creating a login/account.
>>
>> So Chris is asking me to do that which nobody can do, as far as we know.
> 
> Anybody can do it, and we do. YOU, only you, can not. :-P
> 

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

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

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

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

#82829

On 06/16/2026 3:40 PM, Maria Sophia wrote:
> Carlos E. R. wrote:
>> On 2026-06-16 19:07, Maria Sophia wrote:
>>> Carlos E. R. wrote:
>>>>> C'mon. You're actually complaining that I provided fully working Windows
>>>>> scripts, and that I improved them, and that I ported them to Linux for you?
>>>>
>>>> You do not understand the criticism.
>>>
>>> If Chris had even once in his entire life ever invested the time and energy
>>> to post a working tutorial or PSA or working code that he labored on to
>>> help himself and others, I'd understand better his complaint that he can't.
>>
>> Accusing others doesn't change facts.
> 
> Well, I'm going to ask *you* to provide something that is worth value.
> 

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

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


-- 
...w¡ñ§±¤ñ

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

#82832

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

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

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

But I don't know how to do that... 

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

#82821

Maria Sophia <mariasophia@comprehension.com> wrote:
> Chris wrote:
>> I agree that pointing to a stable online resource designed for code is so
>> much better than this particular poster's constant tweaking of their
>> personal scripts on usenet.
> 
> Hi Chris,
> 
> C'mon. You're actually complaining that I provided fully working Windows
> scripts, and that I improved them, and that I ported them to Linux for you?

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

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

#82824

Chris wrote:
>>> I agree that pointing to a stable online resource designed for code is so
>>> much better than this particular poster's constant tweaking of their
>>> personal scripts on usenet.
>> 
>> Hi Chris,
>> 
>> C'mon. You're actually complaining that I provided fully working Windows
>> scripts, and that I improved them, and that I ported them to Linux for you?
> 
> Nope. Try comprehending what I actually wrote rather than responding to
> something I didn't.


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

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

#82858

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]

#82841

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]

#82842

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]

#82843

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]

#82865

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]

#82866

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]

#82868

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]

#82871

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] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | alt.os.linux

csiph-web