Subject: Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi
On Wed, 5/13/2026 5:23 PM, Lawrence D?Oliveiro wrote:
On Wed, 13 May 2026 05:08:35 -0400, Paul wrote:
On Wed, 5/13/2026 12:37 AM, Lawrence D?Oliveiro wrote:
On Tue, 12 May 2026 13:00:47 +0100, Kerr-Mudd, John wrote:
a.1. find the USB driver. discover it needs a newer os than you have.
cry.
Doesn?t your OS have a proper USB stack built-in?
Does every USB device follow standards ? The answer is NO. There is
at least one device family that "just did what it felt like".
Still, we are talking about Android phones. When I was first learning
about Android development over a decade ago, I discovered that
Microsoft Windows needs a special USB driver to connect the developer
tools to an Android phone, while Linux does not.
It appears that is still true today.
In the WinXP era, the MTP driver "arrived" with a certain version
of Windows Media Player. You could only get the WMP 12 or whatever
it was, by running a "Genuine Check" before the download would start.
Since, even today, I still don't have any MTP hardware here,
I am not able to check any of these details. My digital camera
is USB Mass Storage, and switches to dumb mode during a file dump.
Today, they don't do that. WMP is called WMP Legacy now, and if I
have a Midi file to play, WMP Legacy plays it. And as far as I know,
no modern downloads are gated by a "Genuine Check" any more.
We would need to find an article about how the stack is constructed
for such things. Notice that the enthusiast sites, the staff writers
just aren't the same as they used to be.
You'd be better off using an AI to hunt for the details, if you
were actually interested in the answer. The feedback I get most
of the time, is people don't like me pasting in AI material
(as if it would bite them or something).
*******
Here is the answer, generated on the Big Machine (CPU, no GPU for inference). This is the first real query, not done on CoPilot. Machine is air-gapped
during run, answer comes over on a USB stick.
The "Too Long" "Didn't Read" is this. The phone declares itself
as Class 0xFF, and only the (custom) Android SDK and adb bus driver
can solve the 0xFF layer. Microsoft is under no requirement to be including
a "convenience function" for ANYONES custom USB hardware. Once you go custom, you ship a driver for each and every OS you hope to support. The rest of it seems for the most part to be Class drivers. And/Or, that WinUSB framework thing. Which might well be in-box by now, but in a WinXP era would
have to be shipped by the phone maker (the license would allow them
to ship the framework driver, on their dime in terms of downloads).
And in the WinXP era, that's different than the MTP driver.
The MTP driver (which is not an MTPfs and does not offer a drive
letter in File Explorer) would now be a Class driver.
******* OpenAI answer (some 58GB or so model) *******
Below is a "from-the-ground-up" description of the whole Windows side of an Android?-->?PC ADB connection, together with the matching pieces that live on the phone.
I break it into three layers:
| Layer | What you see on the PC (Windows) | What lives on the Android device |
|-------|--------------------------------------------------------------------------|------------------------------------------------------------------|
| 1 | USB **host controller** driver (EHCI/UHCI/XHCI) + generic USB hub driver | USB **gadget controller** (dwc2, DWC3, etc.) in the kernel |
| 2 | Windows **USB bus driver stack** -? usbport.sys , usbhub.sys ,
and the **function-specific client driver** ( winusb.sys ) | Android **USB composite framework** ( configfs / android_usb.c ) |
that builds a *composite* USB device made of several functions
(MTP, RNDIS, ADB, ...) |
| 3 | User?mode **ADB transport**
( adb.exe , adb.exe --> adb.dll --> WinUSB API) | Android **ADB function** ( function_adb.c ) that implements |
the vendor?specific USB interface and forwards packets
to the adbd daemon |
Below is a step-by-step walk-through of each layer, the exact descriptors that are exchanged, and the driver files that Windows loads.
## (1) USB Host Controller & Hub (Windows kernel)
| Component | File / Driver | Role |
|-----------------------------------------------|----------------------------------------------------------------|---------------------------------------------------|
| **Host controller** (EHCI/UHCI/XHCI) | usbport.sys (generic), plus vendor?specific mini-port driver
( ehci.sys , uhci.sys , xusb.sys ) | Implements the PCI/PCIe host-controller interface |
and talks to the physical USB port. |
| **Root hub** | Part of the same mini-port driver | Exposes a virtual hub (port?0) that
Windows enumerates as "USB Root Hub". |
| **External hubs** (if you plug through a hub) | usbhub.sys | Manages downstream ports,
forwards enumeration requests. |
When you connect the phone, the host controller detects a new device on one of its ports and notifies
the USB bus driver ( usbport.sys ). The bus driver creates a **device object** for the phone
(e.g., USB\VID_18D1&PID_4EE7 ) and starts the enumeration process.
---
## (2) Windows USB Bus Driver Stack + Function-Specific Client
### 2.1 Enumeration - Descriptors that Android presents
Android phones expose a **composite** device. The first configuration descriptor contains several interfaces;
each interface has its own class/subclass/protocol fields.
Typical descriptors for a phone that supports *MTP* and *ADB* (the exact numbers vary by OEM, but
the pattern is the same):
| Interface | bInterfaceClass | bInterfaceSubClass | bInterfaceProtocol | Typical Usage |
|------------------|----------------------------|----------------------------|--------------------|------------------------------------|
| MTP / PTP | 0x06 (Imaging) | 0x01 (Still Image Capture) | 0x01 (PTP) | File transfer via Windows Explorer |
| RNDIS (optional) | 0xEF (Miscellaneous) | 0x02 (Common Class) | 0x01 (RNDIS) | Ethernet-over-USB |
| **ADB** | **0xFF (Vendor-Speci