UPDATE:

You _never_ need USB cable ever again!

This is a PSA update to this thread which was solved a while ago,
but where I've been using it daily and have a couple of improvements.
<https://i.postimg.cc/k5gv0yw8/vysor34.jpg> Apple iOS & Android mirroring

The first improvement is huge, which is that Android 12 (maybe Android 11?)
has the hidden Developer option for "Wireless debugging" which eliminates
completely the need for a USB cable to connect to Windows.
<https://i.postimg.cc/SRRXtvKh/adb16.jpg> Android 12 Wireless Debugging

You can keep the phone in your pocket or on your desk, or better yet,
on your wired or wireless charger, and you'll _never_ need that USB
cable ever again to interface with Windows in any way you'd like to.
<https://i.postimg.cc/wvsbcNBz/scrcpy05.jpg> Drag APK from Windows

That is, without ever needing USB...
1. You can mirror Android/iOS over the random-assigned port
<https://i.postimg.cc/TYvqdxCT/vysor35.jpg> iOS & Android PC mirroring
2. And you can mount the Android phone as a drive letter
<https://i.postimg.cc/BvJdKWzt/webdav06.jpg> Android as a drive letter
3. WITHOUT needing to run any adb-pairing steps
<https://i.postimg.cc/SRRXtvKh/adb16.jpg> Android 12 Wireless Pairing

The tools I've been using for a few months to mirror over Wi-Fi are:
a. Vysor (I use this daily, as scrcpy is flakier than is Vysor for me)
b. Scrcpy (I use this when I need better resolution than Vysor gives me)
<https://i.postimg.cc/rmBHmvtV/adb18.jpg> Windows adb vysor & scrcpy

And the tools I use for mounting Android as a drive letter are:
a. WebDAV (I use this daily to mount the _entire_ phone as two drives
b. FTPUse (I don't use it though as it's flakier than WebDAV for me)
<https://www.ferrobackup.com/map-ftp-as-disk.html>

Notice a few details which take time to figure out:
A. Android 12 has a secret hidden Wireless debugging pulldown tile
<https://i.postimg.cc/qRhkhTwV/adb21.jpg> Hidden Wireless-debugging tile
B. Using that tile, Vysor will AUTOMATICALLY figure out the random port!
(Phone) Turn on Wi-Fi
(Phone) Connect to a Wi-Fi AP
(Phone) Turn 'Developer options' 'Wireless debugging = on'
(Phone) Tap "Allow" if it asks to
"Allow wireless debugging on this network?"
Which will be for a specific SSID & (usually random) BSSID.
(PC) C:\> vysor.exe (and then press on the red arrow)
That connects you to adb over the random port on Wi-Fi
without needing to run the new Android 12 adb pairing commands!
<https://i.postimg.cc/ZK9B82gP/adb15.jpg> adb pair [IP][Port] [code]
C. This Windows command tells you which random port adb is using:
C:\> netstat -ano -p tcp | findstr "192.168.0.2"
D. That random port is IMPORTANT to put in the scrcpy batch file
that Herbert kindly wrote which enables the console to be killed.
(see batch file in the sig)
E. Of course, you can get that random port from the phone itself
(but Vysor automatically figures it out - but scrcpy does not
figure out that randomly assigned port, as far as I know).
F: Vysor will also automatically install Vysor on Android temporarily!
<https://i.postimg.cc/Njg6Xx3V/vysor33.jpg> Preparing Vysor on device
G: If the adb connection gets confused (it sometimes happens):
(PC) C:\> adb kill-server
(PC) C:\> vysor.exe (and then press on the red arrow after about 30 seconds)
Note Vysor is magical in figuring out what port adb is using!
H. The free vysor.exe is lower resolution than the free scrcpy.exe
<https://i.postimg.cc/CLyK8z9v/adb20.jpg> Both vysor & scrcpy use adb
I. You need _two_ WebDAV servers to mount the internal & external sdcards
<https://i.postimg.cc/BvJdKWzt/webdav06.jpg> Android as a drive letter
sdcard0 (Using "WebDav Server" as the free WebDAV server on Android)
C:\> net use Y: \\192.168.0.2@8080\DavWWWRoot /USER:foo bar
*WebDAV Server - BestDAV" by ZQ Software
Free, no ads, no GSF, rated 3.4, 100+ reviews, 10K+ downloads
<https://play.google.com/store/apps/details?id=com.zq.webdav.app_free>
Pro: Works well, no ads, no gsf, autostarts upon reboot
Con: Slightly harder to set up as it requires full paths

sdcard1 (Using "Olive Tree" as the free WebDAV server on Android)
C:\> net use Z: \\192.168.0.2@8081\DavWWWRoot /USER:foo bar
*WebDAV Server* by The Olive Tree
Free, has ads, requires GSF, rated 3.5, 800+ reviews, 100K+ downloads
<https://play.google.com/store/apps/details?id=com.theolivetree.webdavserver>
Pro: Works well, slightly easier to set up
Con: ads, gsf, and won't autostart on reboot

In summary, above are some hints as a kind-hearted PSA to help all
of those who helped everyone write the batch code in this thread!

I always strive to pay back for all the help that I received from you!
--
@echo off

cd /d "c:\app\editor\android\scrcpy"
certutil -f -decode %~f0 showwin.exe>nul
REM Port 5555 was needed when you established adb connections over USB
REM And then you disconnected the USB cable to subsequently work on Wi-Fi
REM But as of Android 11 or 12, you can establish the connection over Wi-Fi
REM But that "Developer option" "Wireless debugging" port is random!
REM So you have to get it on Android or on Windows to know what it is

REM You can get the current assigned port from the following command
REM c:\> netstat -ano -p tcp | findstr "192.168.1.10"

REM adb connect 192.168.1.10:5555
adb connect 192.168.1.10:45299

:: now we hide console window
showwin.exe 0

REM scrcpy --always-on-top --tcpip=192.168.1.10:5555
scrcpy --always-on-top --tcpip=192.168.1.10:45299

:: after scrcpy is closed we show console window again
showwin.exe 5

del showwin.exe
goto :eof

-----BEGIN CERTIFICATE-----
TVpgAQEAAAAEAAAA//8AAGABAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAoAAAAA4fug4AtAnNIbgBTM0hTmljZSB0byBtZWV0IHNvbWVi
b2R5IHdobyBpcyBzdGlsbCB1c2luZyBET1MsDQpidXQgdGhpcyBwcm9ncmFtIHJl
cXVpcmVzIFdpbjMyLg0KJFBFAABMAQEAUHmlNgAAAAAAAAAA4AAPAQsBBQwAAgAA
AAAAAAAAAADIEAAAABAAAAAgAAAAAEAAABAAAAACAAAFAAAAAAAAAAQAAAAAAAAA
ACAAAAACAAAAAAAAAwAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA
GBAAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAYAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAAAmAQAAABAAAAACAAAAAgAA
AAAAAAAAAAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoEAAAAAAAAJQQAACmEAAA
uhAAAAAAAABgEAAAAAAAAAAAAABUEAAAABAAAIQQAAAAAAAAAAAAAHYQAAAIEAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABVU0VSMzIuZGxsAABoEAAAAAAAAAAAU2hvd1dp
bmRvdwAAS0VSTkVMMzIuZGxsAACUEAAAphAAALoQAAAAAAAAAABHZXRDb21tYW5k
TGluZUEAAABHZXRDb25zb2xlV2luZG93AAAAAEV4aXRQcm9jZXNzAP8VCBBAADHS
SECAOAB0EYA4InUC99IJ0nXvgDggdepAMfa9BQAAAA+2EEAI0nQTgOowcvOA+gl3
7mv2CgHWMe3r5QntdAKJ7v8VDBBAAFZQ/xUAEEAAagD/FRAQQAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA==
-----END CERTIFICATE-----

In article <tb0osl$1tl1$1@gioia.aioe.org>,
Andy Burnelli <spam@nospam.com> wrote:
>UPDATE:
>
>You _never_ need USB cable ever again!

I fail to see how the Subject line:

Is there a way to put a command window in the background like Linux
does (so that you can kill it)?

has anything whatsoever to do with USB cables.

--
http://www.rollingstone.com/politics/news/the-10-dumbest-things-ever-said-about-global-warming-20130619

Kenny McCormack wrote:

> I fail to see how the Subject line:
>
> Is there a way to put a command window in the background like Linux
> does (so that you can kill it)?
>
> has anything whatsoever to do with USB cables.

I'll answer your question, in detail, with an easily understood real-life
example that highlights why, at the beginning of a quest, you can't always
foresee the solution well enough to ask specifically, at the beginning, for
the exact solution you'll choose as the best solution to the problem set.

I live in mountains where they don't want people to live, so they have
40-acre zoning (meaning you can only put up one house on 79 acres), and we
don't even have Internet on the power poles (everything is WISP), nor any
public utilities other than power & phone (which few people use nowadays).

As a result of living in the boonies, I ensure my cellphone has the
necessary tools to do what I need it to do, without the Internet.

One example of a set of tools that must work without the Internet are the
common backcountry tools that you probably are familiar with for hiking.

Yet the problem for me is a bit different than for most people since most
people stay on the trails, yet I eschew trails like I eschew Google/Apple.

The fact is I hike.
Off trail.
A lot.

Alone.

In the mountains.
Rough mountains.
And I do it by point-to-point topographical "dead reckoning" orienteering.

OK. So now you know the problem set, where my quest, let's say, is to find
a suitable set of free ad free gsf free tools that enable efficient hiking.

What's my question?
Well, for one, there are tools you can easily _predict_ you'll need, right?

Did you ever use the tools you had on your phone to get to a point in the
mountains that is only, oh, say, a short distance as the crow flies & you
have a pretty good idea of what tools you'll need to get there....such as:
a. A compass & location reader (that doesn't rely in the Internet)
b. An altimeter (that doesn't rely in the Internet)
c. A wayfinder (that doesn't rely in the Internet)
d. A track logger with photos (that doesn't rely in the Internet)
e. A custom topographical geoPDF (that doesn't rely in the Internet)
f. An app that handles any custom topographical geoPDF (no Internet)

For example, below are _excellent_ free ad free tools for each of those
tasks where _none_ of that freeware reports your privacy or uses cellular.
a. <https://gitlab.com/mvglasow/satstat>
b. <https://play.google.com/store/apps/details?id=com.mirkix.barometer>
c. <https://play.google.com/store/apps/details?id=com.keuwl.gpswaypoints>
d. <https://f-droid.org/en/packages/de.dennisguse.opentracks/>
e. <https://www.usgs.gov/programs/national-geospatial-program/topographic-maps>
f. <https://play.google.com/store/apps/details?id=com.Avenza>

But wait.... while on the hike, you realized those plans didn't survive
contact in that you didn't realize you also may need more tools than that.
g. A custom geopdf application that handles more than 3 USGS quadrangles
h. A quick tap-to-save getback application when exploring around obstacles
i. An emergency sms location reporter (in case you break a leg on a cliff)
j. A cellular signal strength monitor (to test for emergency communication)

Needing more solutions, you ask on the Usenet for a cellular signal
strength monitor and, at first, you get the answer to use Cellular-Z.

But wait, you asked on Usenet for a cellular signal monitor but what you
asked for was the wrong thing because you don't have the luxury of looking
at a screen constantly, so what you really should have asked for, which
comes out in the thread, is for a signal strength "pinger" that gives an
audible alarm when you lose cellular signal (it works without looking).
k. A cellular-signal pinger that pings while the phone is in your pocket

But when you try that pinger, you realize it doesn't tell you anything
about cellular _data_ signal, which is a _different_ tool altogether:
l. A cellular _data_ connection notification app

The point is that you don't know what tools you'll need at the _start_ of
the quest... where solutions you'll need may morph over time to add...
g. <https://play.google.com/store/apps/details?id=ca.abbro.androidmap>
h. <https://github.com/ruleant/getback_gps>
i. <https://play.google.com/store/apps/details?id=ru.perm.trubnikov.gps2sms>
j. <https://play.google.com/store/apps/details?id=make.more.r2d2.cellular_z>
k. <https://play.google.com/store/apps/details?id=com.simple.axanor.simpleconnectivitymonitor>
l. <https://play.google.com/store/apps/details?id=com.gordienoye.cellulardatanotifier>

Notice at the start you didn't even realize what you really needed wasn't a
graphical cellular signal strength monitor per se, but audible apps to let
you know while the phone is in your pocket when you had no signal strength
for phone calls and/or for SMS/MMS texts.

What you are attempting to do is hold me to that longer list, based solely
on experience, when I planned ahead as best I could but I didn't know then
what I know now as to the final set of solutions which solve the problem.

For example, I know I want to _draw_ a GPX track by hand, but I don't know
of _any_ smartphone freeware that does that, so I resort to online freeware
such as Caltopo online mapping tools which allow you to draw a track on an
accurate topographic map and then export that track to use on your phone.
<https://caltopo.com/map.html#ll=38.80547,-98.39355&z=5&b=mbt>

But then I might find out that I don't have a program on the smartphone
that will give _directions_ based on that imported GPX track (e.g., it
might alert you "Go west for 100 feet to get back onto the desired track").

What you ask for in a Usenet thread is based only on what you can plan for.

Even after all that planning and adjusting and improving the solution, you
may find that you also need a fake gps spoofer, perhaps in order to more
easily tell specific apps any desired given location without having to
laboriously _type_ latitude/longitude coordinates in, such as this app:
<https://play.google.com/store/apps/details?id=com.lexa.fakegps>

But then you find out that you need to set Android Developer options
"Mock location app" to that app, which entails deeper knowledge of the
inner workings of Android to get the app to work within your hiking plan.
<https://www.virtuallocation.com/fake-location/allow-mock-locations.html>

In summary, when you are solving problems that nobody else has ever solved
(which we did in this thread), you don't know at the start of the quest
what tools you will end up as your final efficient working solution.

When you _do_ find the tools though, it's basic Internet courtesy to give
back to the team added value by way of what solution worked best for you.
--
This response is a well-researched answer to Kenny McCormack's question,
because Kenny seems to think we should always know the solution we are
going to end up with _before_ we ask the question on this Usenet group.

On Mon, 18 Jul 2022 06:46:43 +0100
Andy Burnelli <spam@nospam.com> wrote:

> Kenny McCormack wrote:
>
> > I fail to see how the Subject line:
> >
> > Is there a way to put a command window in the background like Linux
> > does (so that you can kill it)?
> >
> > has anything whatsoever to do with USB cables.
>
> I'll answer your question, in detail, with an easily understood real-life

[Massive snipping]

> In summary, when you are solving problems that nobody else has ever solved
> (which we did in this thread), you don't know at the start of the quest
> what tools you will end up as your final efficient working solution.
>
> When you _do_ find the tools though, it's basic Internet courtesy to give
> back to the team added value by way of what solution worked best for you.
> --
> This response is a well-researched answer to Kenny McCormack's question,
> because Kenny seems to think we should always know the solution we are
> going to end up with _before_ we ask the question on this Usenet group.

That's a lot of words. I guess the actual answer is that it doesn't have
anything to do with the actual wording of the Original Question, and is
now well off-topic for amb (and pretty much so for windows too, as it seems
the topic is now "how do I access (some poweruser mode) in Android"

Glad you got to where you wanted to, though.

--
Bah, and indeed Humbug.

Kerr-Mudd, John wrote:

> Glad you got to where you wanted to, though.

Sigh. The effort spent on providing an analogy failed. :(
So I'll have to simply spell out what is obvious to all who understood.

This is what happened...

1. *I asked to put a process in the background so I could kill it.*
2. *The team came up with a Windows batch method that killed the console.*
3. *That method worked fine with USB cables as the port was fixed at 5555.*

However...
4. *Unfortunately, the Wi-Fi method _requires_ prior knowledge of the*
*constantly changing Android Wireless debugging port assignment.*

OK... now _this_ is the important point for Windows batch processing!
a. *So, for USB, the batch file works fine (as the port is static!).*
b. *But for Wi-Fi, the batch file random port has to be changed daily.*

Do the basic details of the problem set sink in yet?

Clearly, my recent update gave _how_ to obtain that IP address and port
information (whether or not Curmudgeon or McCormick understood that fact).

What _both_ of those trolls clearly didn't do was _read_ the thread.
Of, if they did, they didn't comprehend a word that was said in the thread.

They both posted without even thinking about what the thread was about.
Even as they complained that they didn't understand what it was about.

It's not my fault they don't understand the progress we made in this
thread, nor is it my fault that they don't understand that the port is
static for USB but dynamic for Wi-Fi (which is a big deal in a script!).

Nonetheless, that's water under the bridge now that I've EXPLAINED to both
of them what they failed to grasp (first in analogy, second in actuality).

Moving forward...

BTW, what I'm working on now, to _improve_ that process, is determining
_how_ Vysor.exe figures out the Android port but why Scrcpy.exe does not.

That's critical to put in the batch script:
_Q: How does Vysor know the adb port but scrcpy does not know it?_

If I can figure _that_ out, then there is no longer a need to add the
explicit IP address and port to the Wi-Fi version of the scrcpy batch file
originally written by Herbert (note that the USB version doesn't have that
problem because the USB version of Herbert's scrcpy batch script only needs
the port 5555 in all cases - but the Wi-Fi version uses random ports!).

If the analogy failed, did the direct 4-step explanation sink in yet?
--
HINT: See the actual resulting batch file added in the prior sig,
which was posted to be provide in comments why daily modification is needed
when on Wi-Fi even as Herbert's batch file worked fine being static on USB.

Kerr-Mudd, John wrote:

> That's a lot of words. I guess the actual answer is that it doesn't have
> anything to do with the actual wording of the Original Question, and is
> now well off-topic for amb (and pretty much so for windows too, as it seems
> the topic is now "how do I access (some poweruser mode) in Android"

Woo hoo!

*IMPORTANT UPDATE* to work around the total absence of 'Ctrl-Z,bg'!
<https://i.postimg.cc/zfLp8b2v/adb22.jpg> New 'Ctrl+Z,bg' workaround

It took me days (elapsed time) to figure out this latest workaround
to the complete and utter total lack of 'Ctrl+Z,bg' in Windows.

IMHO, *it's a crime that Windows totally lacks 'Ctrl+Z,bg' functionality.*
All this effort would NOT be needed if Windows simply had 'Ctrl+Z,bg'.

Yet, the final 'Ctrl+Z,bg' solution turns out to be incredibly simple.
If you know a few of the tricks, that is, to replace 'Ctrl+Z,bg'.

This lack of 'Ctrl+Z,bg' is a horrible deficiency of Windows indeed.
1. Luckily, with your help, we created a USB 'Ctrl+Z,bg' workaround.
2. And, after testing for days, *we have a Wi-Fi 'Ctrl+Z,bg' workaround.*

This new 'Ctrl+Z,bg' workaround can now be added to the existing
'Ctrl+Z,bg' workaround batch script kindly authored by Herbert.

The USB 'Ctrl+Z,bg' workaround, which expects a static port, only need to
have added a new 'Ctrl+Z,bg' variable, e.g., %GET-RANDOM-PORT-ASSIGNMENT%

Andy Burnelli wrote:

> Woo hoo!
>
> *IMPORTANT UPDATE* to work around the total absence of 'Ctrl-Z,bg'!
> <https://i.postimg.cc/zfLp8b2v/adb22.jpg> New 'Ctrl+Z,bg' workaround
>
> It took me days (elapsed time) to figure out this latest workaround
> to the complete and utter total lack of 'Ctrl+Z,bg' in Windows.
>
> IMHO, *it's a crime that Windows totally lacks 'Ctrl+Z,bg' functionality.*
> All this effort would NOT be needed if Windows simply had 'Ctrl+Z,bg'.
>
> Yet, the final 'Ctrl+Z,bg' solution turns out to be incredibly simple.
> If you know a few of the tricks, that is, to replace 'Ctrl+Z,bg'.
>
> This lack of 'Ctrl+Z,bg' is a horrible deficiency of Windows indeed.
> 1. Luckily, with your help, we created a USB 'Ctrl+Z,bg' workaround.
> 2. And, after testing for days, *we have a Wi-Fi 'Ctrl+Z,bg' workaround.*
>
> This new 'Ctrl+Z,bg' workaround can now be added to the existing
> 'Ctrl+Z,bg' workaround batch script kindly authored by Herbert.
>
> The USB 'Ctrl+Z,bg' workaround, which expects a static port, only need to
> have added a new 'Ctrl+Z,bg' variable, e.g., %GET-RANDOM-PORT-ASSIGNMENT%

This quest started solely because there is no "control+Z" in Windows.

However, the result is we have a finely tuned working system without it!
a. I always give back to the team for helping me solve all the problems,
b. So here are minor updates based on daily use of Herbert's showwin.bat

*UPDATE #1:*

There is a workaround to the fact the random port address must be known:
<https://i.postimg.cc/tgvzsMRm/scrcpy25.jpg> Connect over Wi-Fi sans USB

While scrcpy.exe doesn't need any specifics once a connection is
established, there are times when you have _multiple_ devices connected.
<https://i.postimg.cc/zDCTY9NS/adb28.jpg> multiple adb connections
More so, there are two different ways to pair in the first place!
<https://i.postimg.cc/R0BXTMCy/adb29.jpg> multiple pairing connections

Then you _must_ specify _which_ device (even if they're all the same!)

It turns out scrcpy can use the "-s 192.168.0.2" or "-s SERIAL.tcp"
or "-s SERIAL" or even "--tcpip=[IP]:[PORT]" each of which makes it
easier to connect over Wi-Fi (sans USB cable) from Windows using
Herbert's excellent showwin.bat script (once you've established pairing).
<https://i.postimg.cc/SRRXtvKh/adb16.jpg> Android 12 Wireless Pairing

The scrcpy.exe can sometimes use the short form of the Android serial.
<https://i.postimg.cc/9MSg3sjj/adb33.jpg> Long and short serial formats

And scrcpy.exe can sometimes use the IP address & random port of course:
C:\> scrcpy.exe --tcpip=192.168.0.2:41269
<https://i.postimg.cc/L4bDbk6z/adb27.jpg> scrcpy --tcpip=[IP]:[PORT]

*UPDATE #2:*
There is no workaround yet to the original need for the random port
(whether you connect via "connect" or the encrypted "pair" command).

Once you've connected, scrcpy.exe does not need to know the IP address
or port or serial number or tcp address & port _if_ there one device.
<https://i.postimg.cc/Y00vx4yp/scrcpy04.jpg> Extraneous cmd window (&)

But most of the time you have multiple devices connected via adb.
And then the scrcpy.exe inside Herbert's script needs to know which one.
<https://i.postimg.cc/tgvzsMRm/scrcpy25.jpg> Connect over Wi-Fi sans USB

*UPDATE #3:*
Also note that scrcpy has _better PC resolution_ than does free vysor
<https://i.postimg.cc/xdSMtBkn/vysor36.jpg> scrcpy vs Vysor resolution

*UPDATE #4:*
Note that Vysor works with my iOS devices (but with less functionality)
<https://i.postimg.cc/TYvqdxCT/vysor35.jpg> iOS & Android PC mirroring

*UPDATE #5:*
Android 12 has mac randomization per connection - which is working fine!
<https://i.postimg.cc/nchSVcmS/vysor30.jpg> Static/Reserved IP address

*UPDATE #6:*
For weeks (elapsed time) I've tried various methods to get around pairing,
but so far, none of them works as well as _looking_ at the random port.
<https://i.postimg.cc/SRRXtvKh/adb16.jpg> Android 12 Wireless Pairing

*UPDATE #7:*
All Windows debugging commands work only _after_ you've already paired!
<https://i.postimg.cc/DZV4tcYM/adb30.jpg> Windows pairing debuggers

*UPDATE #8:*
The separate issue of accessing all of Android as a Windows drive has
been working flawlessly with the simple "net use" commands outside of adb.
<https://i.postimg.cc/9FJMKYch/scrcpy21.jpg> Windows Drive: === Android

C:\> net use Z: \\192.168.0.2@8080\DavWWWRoot /USER:foo bar
&& net use Y: \\192.168.0.2@8081DavWWWRoot /USER:foo bar
&& echo "Your Android phone is now mounted as Windows drive letters"
<https://i.postimg.cc/BvJdKWzt/webdav06.jpg> Both sdcards mounted
--
Posted to give back to the team as a good Usenet citizen who asks hard
questions which have never been asked before, and who attempts _every_
viable suggestion, and then who gives back to the team not only with the
solution but also with meticulously detailed screenshots so others benefit
from the information found in the permanent record for users to search and
find now
and far into the future.