Andy Burnelli wrote:

> Tutorial: Working examples using Android/Windows adb over Wi-Fi
> The documentation below is designed to be as cut-&-paste as possible.
>
> This tutorial assumes you already installed adb & enabled USB debugging.
> <https://source.android.com/setup/build/adb>
> Note this was tested WITHOUT the Android SDK; it just needs "adb.exe".
>
> Android 11 and up allows adb connections purely over Wi-Fi (with no
> initial or continued need for USB cables) which allows mirroring
> over Wi-Fi using any of a variety of free & FOSS tools such as:
> a. Vysor
> b. Scrcpy
> c. Microsoft Phone Link plus Microsoft/Samsung Link to Windows
>
> Those local/remote mirror tools are described in gory detail here:
> *What free software do you use to locally mirror Android over Windows*
> <https://groups.google.com/g/alt.comp.microsoft.windows/c/eMYBmpq2H50>
>
> *What free software do you use to remotely control Android over Windows*
> <https://groups.google.com/g/comp.mobile.android/c/7toIA9mxX4o/m/DAmq_Z4PAgAJ>
>
> While screen mirroring is fantastic, what this tutorial focuses on is
> using the Android Debug Bridge (adb) commands over Wi-Fi from Windows.
>
> Prior to Android 11, if the user wished to use adb with Android over Wi-Fi,
> the adb connection had to be initially _established_ over a USB cable.
>
> There is much information about that problem set, only summarized below.
> 1. C:\> adb kill-server (optional, but it helps for a starting point)
> 2. Connect the Android phone to USB (mandatory on Android 10 & below).
> 3. Connect to the Android phone over USB.
> C:\> adb connect
> Or
> C:\> adb reconnect
> You should see an output of something like:
> * daemon not running; starting now at tcp:5037
> * daemon started successfully
> reconnecting ABCDEFGHIJK [device]
> 4. C:\> adb tcpip 5555
> You want one of these two show up:
> restarting in TCP mode port: 5555
> Or...
> * daemon not running; starting now at tcp:5037
> * daemon started successfully
> restarting in TCP mode port: 5555
> Not this:
> * daemon not running; starting now at tcp:5037
> * daemon started successfully
> error: no devices/emulators found
> But you might get this if you started from scratch
> * daemon not running; starting now at tcp:5037
> * daemon started successfully
> error: device unauthorized.
> This adb server's $ADB_VENDOR_KEYS is not set
> Try 'adb kill-server' if that seems wrong.
> Otherwise check for a confirmation dialog on your device.
> If you do, just press "Allow" & "Remember" on the phone when it asks.
> 5. At this point you can disconnect the USB cable (or leave it connected).
> 6. To connect over Wi-Fi, this always works at this stage in the process.
> C:\> adb connect 192.168.0.2
> Or, if you're a stickler for details, specifying the port works too.
> C:\> adb connect 192.168.0.2:5555
> In either case, you want to see this:
> connected to 192.168.0.2:5555
> 7. At this point you are completely connected:
> C:\> adb devices
> That should output either this (if you left the USB connected).
> List of devices attached
> ABCDEFGHIJ device
> 192.168.0.2:5555 device
> Or this (if you disconnected the USB already).
> List of devices attached
> 192.168.0.2:5555 device
>
> However, as of Android 11 and up, it's now possible to pair your Android
> phone to your over Wi-Fi Windows computer without ever needing a USB cable.
>
> That instantly negates the need for the workaround above, detailed below.
> *Android Studio wireless ADB error (10061)*
> <https://stackoverflow.com/questions/37267335/android-studio-wireless-adb-error-10061>
> That 5-year old wireless/usb workaround was updated on Oct 4, 2021.
>
> Here's a description of the new adb Wi-Fi capabilities in Android 11+
> <https://www.makeuseof.com/tag/new-adb-make-process-simple-easy/>
> "If you're on Android 11 (with SDK platform tool version 30 or greater)
> and above, you can use wireless debugging to pair your device with the
> computer. This Wi-Fi pairing method uses a new adb command called 'pair'
> which works similar to how Bluetooth pairing works."
>
> The _new_ command sequence to pair Windows adb to Android over Wi-Fi is:
> A. Optionally, start at a known default starting point on Windows.
> C:\> adb kill-server
> B. Optionally, start at a known default starting point on Android.
> Settings > Developer options > Revoke USB debugging authorizations
> C. Make sure these Android 11+ settings are turned on.
> Settings > Developer options > USB debugging = On
> Settings > Developer options > Wireless debugging = On
> Optionally:
> Settings > Developer options > Disable adb authorization timeout = On
>
> Then, to connect Windows adb to your Android 11+ phone over Wi-Fi:
> <https://developer.android.com/studio/command-line/adb#connect-to-a-device-over-wi-fi-android-11+>
> 1. Long press on Android "Developer options > Wireless debugging" settings.
> 2. Press the "Pair device with pairing code" option item.
> This will report something like the following information:
> Pair with device: Wi-Fi six-digit pairing code: 123456
> IP address & Port: 192.168.0.2:54321
> 3. C:\> adb pair 192.168.0.2:54321 123456
> You should see something like this on the phone:
> Successfully paired to 192.168.0.2:54321 [guid=adb-{serial number}]
> 4. C:\> adb connect 192.168.0.2:54321
>
> Now you can issue adb commands from Windows over Wi-Fi to an Android phone.
> C:\> adb devices
> That should report the devices that adb is connected to, for example:
> List of devices attached
> 192.168.0.2:54321 device
>
> C:\> adb shell netstat
> That should list the phone's TCP/IP connectivity tables.
>
> C:\> adb shell service list
> That should list all the running services on the phone.
>
> C:\> adb shell ps
> That should list all the running processes on the phone.
>
> C:\> adb shell ifconfig
> That should provide your Android network interface information.
>
> C:\> adb shell "cd /sdcard/Download && ls"
> That should list files in your internal storage Download folder.
>
> C:\> adb shell "cd /sdcard && mkdir temp"
> That should create a "temp" directory in your internal
> storage sdcard on your Android phone.
>
> C:\> adb shell screencap -p /sdcard/temp/screenshot.png
> That should snap a screenshot of your android phone & store it
> in the newly created temp folder on the Android phone.
>
> C:\> adb shell screenrecord /sdcard/temp/screenrecord.mp4
> Do whatever on the Android phone & then press Ctrl+C to end.
> That should create an MP4 recording of your Android screen.
>
> C:\> adb install "C:\path-to\filename.apk"
> That should install the APK from Windows over Wi-Fi onto Android.
> (Note this is useful when you have hundreds of apps like I do!)
> <https://i.postimg.cc/bN875p8b/apk01.jpg> Windows APK archive
>
> C:\> adb push "C:\path-to\filename.apk" /sdcard/Download
> That should copy the named file from Windows to Android &
> (in this case) put it in your internal storage "Download" folder.
>
> Note that each phone OEM "can" use a different filespec for
> internal & external sdcards (e.g., /storage/emulated/0/Download).
>
> C:\> adb push C:\path\apk_archive\ /sdcard/Download/apks
> That should create a folder named "apks" in the Android phone's
> internal storage "Download" folder and then copy all the files
> from the Windows "apk_archive" folder into that new "apks" folder.
>
> C:\> adb shell
> $ /storage/emulated/0/DCIM
> $ ls
> $ exit
> That should allow you to interactively manage the Android
> filesystem from Windows over Wi-Fi. Note these are common:
> /mnt/sdcard/DCIM
> /sdcard/DCIM
> /sdcard/DCIM
>
> C:\> adb logcat
> Use this if you're a glutton for punishment as it will forever
> spit out a log of what's going on your phone (until you Ctrl+C).
>
> C:\> adb logcat *:E
> The values are:
> V: Verbose (lowest priority)
> D: Debug
> I: Info
> W: Warning
> E: Error
> F: Fatal
> S: Silent (highest priority. Nothing is printed)
> Note logcat has multiple options, e.g.,
> adb logcat Tag1:I *:S
> That will list output log messages with the tag "Tag1"
> and priority level Info or higher.
> The *:S at the end will exclude the log from other tags
> with any priority.
>
> C:\> adb shell getprop | FindStr /i "ro.build.version"
> Get properties off the phone & grep for the given keyword.
>
> C:\> adb shell getprop ro.build.version.security_patch
> This will report the property of the security patch level.
>
> C:\> adb shell getprop ro.build.fingerprint
> This will report basic hardware information about your phone.
>
> C:\> adb shell input swipe 500 1000 500 100
> This will instantly swipe from center to the top of the screen.
>
> You can add a time period, e.g., take 3 seconds to swipe that.
> C:\> adb shell input swipe 500 1000 500 100 3000
>
> C:\> adb shell input text "K-9\ Mail"
> This will enter into the phone's search GUI a search for that app.
>
> C:\> adb shell pm list packages
> That should list all the packages installed on your Android phone.
>
> C:\> adb shell pm list packages | findStr /i "facebook"
> That should list all the packages with that string in their name.
>
> C:\> adb shell pm path com.facebook.appmanager
> That should list the path to the named package, e.g.,
> package:/system/app/FBAppManager_NS/FBAppManager_NS.apk
>
> C:\> adb pull /system/app/FBAppManager_NS/FBAppManager_NS.apk
> That should copy the APK from Android over to Windows.
>
> C:\> adb shell dumpsys package com.facebook.appmanager
> This should list an app's components, activities & services, etc.
>
> C:\> adb shell pm list permissions | FindStr facebook
> This should list all permissions granted for that particular app.
>
> C:\> adb shell pm revoke com.facebook.appmanager android.permission.READ_EXTERNAL_STORAGE
> This should revoke the stated permissions from that app.
>
> C:\> adb shell pm grant com.facebook.appmanager android.permission.READ_EXTERNAL_STORAGE
> This should grant the stated permissions to that app.
>
> C:\> adb shell pm clear com.facebook.appmanager
> This should clear all the application data in that package.
>
> C:\> adb shell pm uninstall -k --user 0 com.facebook.appmanager
> That should uninstall the named package for the current user.
> (You don't need root to uninstall system apps for the current user.)
>
> Note this app will provide, by default, a list of all apps
> you've installed, in the reverse order that you installed them.
> *App Inspector* by UBQSoft
> Free, ad free, gsf free, rated 4.3, 100K+ installs
> <https://play.google.com/store/apps/details?id=com.ubqsoft.sec01>
>
> C:\> adb shell pm install-existing com.facebook.appmanager
> That should re-install that package that you had just uninstalled.
> (This works because it was only uninstalled for the current user.)
>
> C:\> adb shell pm disable-user --user 0 com.facebook.appmanager
> That should disable the named package.
>
> C:\> adb shell pm list packages -d | findStr /i "facebook"
> That should find the disabled apps & then grep for "facebook".
>
> C:\> adb shell pm enable com.facebook.appmanager
> That should enable the named package.
>
> C:\> adb shell pm uninstall com.facebook.appmanager
> If you omit the "-k --user 0" part, it uninstalls for all users.
>
> C:\> adb bugreport
> That should create a zip file of your current bug-report data.
>
> C:\> adb shell am start -n com.google.android.gms/.ads.settings.AdsSettingsActivity
> That should pop up an Android "Reset Advertising ID" settings page.
>
> C:\> adb shell input tap 500 400
> If run after the command above, that will tap the button to
> asking to "Opt out of Ads Personalization" in that Activity
> if that button is like mine, at the X=500 & Y=400 location.
>
> On my phone, this is the "Reset advertising ID" button location:
> adb shell input tap 500 200
> On my phone, this is the "OK" button on that GUI above.
> adb shell input tap 700 1000
>
> C:\> adb shell am force-stop com.google.android.gms
> If run after bringing up the advertising-id reset Activity,
> it will close the activity without doing anything else.
>
> C:\> adb shell input keyevent KEYCODE_HOME
> That should press the "Home" button.
> C:\> adb shell input keyevent KEYCODE_CAMERA
> That should press the "Camera" button.
> C:\> adb shell input keyevent KEYCODE_BACK
> That should press the "Back" button.
> C:\> adb shell input keyevent KEYCODE_HEADSETHOOK
> That should press the "Headset" button.
> A list of hardcoded buttons is located in Android documentation:
> <https://developer.android.com/reference/android/view/KeyEvent#constants_1>
>
> C:\> adb pull /system/etc/hosts .\hosts.txt
> [That should copy the hosts file over even if you're unrooted.]
>
> C:\> adb shell dumpsys battery set level 4
> That will _simulate_ (aka "spoof") a 4% battery level,
> which may instantly cause a cascade of actions on your phone
> as "if" your battery level really were low.
>
> C:\> adb shell dumpsys battery set ac 1
> That will _simulate_ (aka "spoof") that you just connected
> an AC power adapter to your phone, so, for example, the phone
> should show an icon and speak that you connected to AC power
> if you've set this app to do that for you.
> *Charging Indicator* by Jason A. Maderski
> Free, ad free, gsf free, rated 4.2, 50K+ installs
> <https://play.google.com/store/apps/details?id=maderski.chargingindicator>
>
> Note that with adding notifications, I use text-to-speech to
> clarify what the notification is telling me, instead of sounds.
>
> Two text-to-speech free apps I use for notifications are:
> *Tell Me - Text To Speech* by Simply Complex Apps
> Free, ad free, +inapp $, rated 4.1, 100K+ installs
> <https://play.google.com/store/apps/details?id=com.simplycomplexapps.ASTellme>
>
> *NTM* Convert Text To Audio File by MEPROWORLD
> Free, ad free, not rated, 10K+ installs
> <https://play.google.com/store/apps/details?id=com.meproworld.ntm>
>
> In the case of the battery indicators, I set notifications such as:
> "Your battery just reached 100% charging"
> "Your USB cable just disconnected"
> etc.
>
> C:\> adb shell dumpsys battery reset
> This will turn off the battery-level simulation (aka spoofing).
>
> C:\> adb shell dumpsys battery set ac 0
> That will _simulate_ (aka "spoof") that you just dis-connected
> an AC power adapter from your phone.
>
> C:\> adb shell dumpsys battery set usb 1
> That will _simulate_ (aka "spoof") that you just connected
> a USB cable to your phone.
> .
> C:\> adb shell dumpsys battery set usb 0
> That will _simulate_ (aka "spoof") that you just dis-connected
> a USB cable to your phone.
>
> C:\> adb shell pm list packages
> That should list all installed packages.
> C:\> adb shell pm list packages -s (list system packages only)
> C:\> adb shell pm list packages -3 (list 3rd-party package names)
> C:\> adb shell pm list packages -u (list uninstalled packages)
> C:\> adb shell dumpsys package packages (list package information)
> C:\> adb shell pm dump com.facebook.appmanager (info on one package)
> C:\> adb shell pm path com.facebook.appmanager (package apk filespec)
>
> C:\> adb shell pm list packages google | find /c /v ""
> That should tell you the number of packages you have on Android
> which have "google" in the package name.
>
> C:\> adb shell am start -n com.android.settings/.Settings\$PowerUsageSummaryActivity
> That should bring up a moving graph of your current battery usage.
>
> C:\> adb shell am start -n com.google.android.gms/.location.settings.LocationAccuracyActivity
> That should tell you if you have Google location spyware running.
>
> C:\> adb shell am start -n com.google.android.gms/co.g.Space
> That should allow you to clear your Google Play services storage.
>
> C:\> adb shell am start -n com.google.android.gms/.update.SystemUpdateActivity
> That should allow you to check for Android updates.
>
> C:\> adb shell am start -n com.google.android.gms/.nearby.exposurenotification.settings.SettingsActivity
> That will let you know your Covid exposure notification status.
>
> C:\> adb shell am start -n com.google.android.gms/.app.settings.GoogleSettingsLink
> That should bring up most of the Google privacy settings on Android.
>
> C:\> adb shell am start -n com.android.settings/.Settings\$NotificationAppListActivity
> That should bring up _all_ your extant notifications.
>
> C:\> adb shell am start -n com.android.settings/.Settings\$AppMemoryUsageActivity
> That should show you how much memory each app is using.
>
> C:\> adb shell am start -n com.android.settings/.network.telephony.MobileNetworkActivity
> That should tell you how much mobile data you've used up.
>
> C:\> adb shell am start -n com.android.settings/.applications.ManageApplications
> That should bring up the form to set your default Android apps.
>
> C:\> adb shell am start -n com.google.android.gms/.gcm.GcmDiagnostics
> That should scare the crap out of you when you see what it says!
> mtalk.google.com is obtaining your private location information?
>
> C:\> adb backup -all
> Supposedly this will back up your entire device & app data to an
> encrypted "backup.adb" file in your current Windows directory.
>
> C:\> adb restore "C:\path-to\backup.adb"
> Supposedly this will restore your backed up device & app data.
>
> Please note that I tested the commands above so that cut-&-paste works.
> Note, of course, that many (but not all!) of those commands can likely
> be found on the net scattered about (however, some don't exist to my
> knowledge on the net though, as they were found by trial and error).
>
> However _basic_ information on adb commands abound on the net, e.g.,
> *Android Debug Bridge (adb) cheat sheet*
> <https://www.automatetheplanet.com/adb-cheat-sheet/>
>
> In addition, below are untested possibilities... for future tutorials.
>
> Note the debilitating problem that, while you can install an SMB _server_
> on non-rooted Android, it's impossible (so far) to use an SMB _client_ on
> non-rooted Android to connect to a typical Windows SMB share over Wi-Fi.
>
> Non-rooted Android SMB client apps can't connect to Windows SMB shares
> simply because Windows SMB requires port 445 but non-root Android SMB
> clients, much to my chagrin, can't ever access ports lower than 1024.
>
> However, an enterprising experimenter "may" be able to work around
> this intractable problem perhaps by the use of "port forwarding"?
> C:\> adb forward tcp:local_port tcp:device_port
> C:\> adb reverse tcp:device_port tcp:local_port
>
> And be advised that adb can temporarily elevate permissions for a user
> where this example below is run completely on the Android device itself.
> Termux % adb pair localhost:54321 <add the 6-digit wi-fi pairing code>
> Termux % adb connect localhost:54321
> Termux % adb shell
> Termux # run-as com.termux
> Termux $ {permissions are now elevated while inside this prompt}
>
> It has been said you can run privileged commands, like look at the
> default protected contacts sqlite database on Android phones.
> <https://android.stackexchange.com/questions/41455/where-is-the-data-for-contacts-storage-located>
> Termux $ adb -s emulator-5554 shell
> Termux $ sqlite3
> /data/data/com.android.providers.contacts/databases/contacts2.db
> SQLite version 3.3.12
> Enter ".help" for instructions
> sqlite> select * from data;
> sqlite> delete from data;
> sqlite> delete from contacts;
> sqlite> delete from raw_contacts;
> <https://www.dev2qa.com/android-contacts-database-structure/#>
>
> If you have additional useful adb commands, please share so we all learn.
> <https://blog.testproject.io/2021/08/10/useful-adb-commands-for-android-testing/>
>
> *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,bg" 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.