From Newsgroup: comp.mobile.android
On Wed, 5/13/2026 5:23 PM, Lawrence DrCOOliveiro wrote:
On Wed, 13 May 2026 05:08:35 -0400, Paul wrote:
On Wed, 5/13/2026 12:37 AM, Lawrence DrCOOliveiro 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.
DoesnrCOt 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 AndroidrC>-->rC>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** -rC> 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 | UserrCamode **ADB transport**
( adb.exe , adb.exe --> adb.dll --> WinUSB API) | Android **ADB function** ( function_adb.c ) that implements |
the vendorrCaspecific 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 vendorrCaspecific 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 (portrC>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-Specific)** | **0x42** | **0x1** | Debug bridge |
The ADB interface is the only one that matters for adb.exe . It uses:
* **Two bulk endpoints** - EPrC>IN (device --> host) and EPrC>OUT (host --> device).
*Typical endpoint numbers*: 0x01 (OUT), 0x81 (IN).
* **MaxPacketSize**: 512rC>bytes for fullrCaspeed, 1024rC>bytes for highrCaspeed.
Because the class is 0xFF , Windows does **not** have a builtrCain driver that will bind automatically.
Instead the Android SDK ships an INF file ( android_winusb.inf ) that tells Windows to associate
this interface with the generic **WinUSB** client driver.
### 2.2 Driver binding on Windows
1. **INF file** - android_winusb.inf (installed by the "Google USB Driver" package).
%SingleAdbInterface% = WINUSB, USB\VID_18D1&PID_4EE7&MI_01
The INF matches on the vendor ID ( 0x18D1 for GooglerCaowned devices; OEMs use their own VID) and the interface number (MI_XX).
2. **Client driver** - winusb.sys .
WinUSB is a generic "function-client" driver that exposes the bulk endpoints to user mode
through the **WinUSB API** ( WinUsb_* functions).
3. **Device stack after binding**
+---------------------------+
| User-mode ADB client |
| (adb.exe --> adb.dll) |
+------------+--------------+
|
v
+---------------------------+
| WinUSB client driver |
| winusb.sys |
+------------+--------------+
|
v
+---------------------------+
| USB bus driver stack |
| usbhub.sys, usbport.sys |
+------------+--------------+
|
v
+---------------------------+
| Host-controller mini-port|
| (ehci/uhci/xhci) |
+---------------------------+
When the INF is installed, Windows creates a **device interface** of
class GUID {88BAE032-5A81-49F0-BC3D-A4FF138216D6} (the WinUSB "Device Interface").
adb.exe opens this interface with CreateFile("\\\\.\\usb#vid_18d1&pid_4ee7#...")
and then calls WinUsb_Initialize , WinUsb_ReadPipe , WinUsb_WritePipe .
### 2.3 Optional "CompositerCadriver" (for MTP/PTP)
If you also want Windows Explorer to see the phone as a media device, the same composite device contains an **MTP** interface whose class/subclass/protocol are recognized
by the built-in **Windows Portable Devices (WPD)** driver ( wpdusb.sys ). That driver binds
in parallel with WinUSB; both drivers share the same physical USB device but own different interfaces.
---
## (3) UserrCamode ADB Transport on Windows
| Component | File / Library | What it does |
|-----------------------------|------------------------------------|---------------------------------------------------------------|
| adb.exe (client) | Part of Android SDK platform-tools | Parses command line, opens a **transport** to the device. |
| adb.dll (or built-in code) | Linked into adb.exe | Implements the *ADB protocol* on top of the WinUSB I/O calls. |
| WinUsb_* API | winusb.sys + setupapi.dll | Sends/receives raw USB bulk packets. |
**Protocol flow**
1. **Connect** - adb.exe opens the WinUSB handle, then sends an *ADB "host-connect"* packet (0x4e 0x58 ...) on the OUT bulk pipe.
2. **Handshake** - The device replies with a *"device-online"* banner ( "OKAY" + version).
3. **Command packets** - Each ADB command is framed as: <len(4)> <command> .
The payload (e.g., shell:logcat ) travels over the bulk pipes in both directions.
4. **Multiplexing** - When multiple devices are attached, each gets its own WinUSB handle;
adb.exe enumerates them via the device interface GUID.
If you run adb devices , the client asks the WinUSB driver for the list of opened interfaces and prints their serial numbers (which the phone provides through the *ADB function*).
---
## AndroidrCaside Stack - How the Phone Presents that Interface
| Layer | Kernel component | What it does |
|--------------------------------|------------------------------------------|-----------------------------------------------------|
| **a. USB Gadget controller** | dwc2 or dwc3 driver (e.g., dwc3.0 ) | Exposes a *USB device* on the physical connector;
registers as usb_gadget . |
| **b. Composite framework** | configfs
( /sys/kernel/config/usb_gadget/... )
+ android_usb.c | Builds a **composite gadget** with several functions
(MTP, RNDIS, ADB). Each function is represented by a
directory under /config/ and gets its own
interface number. |
| **c. ADB function** | function_adb.c ( adb.c ) | Registers a **vendorrCaspecific USB function**:
classrC>0xFF, subclassrC>0x42, protocolrC>0x01;
creates two bulk endpoints (maxpacket 512/1024).
It implements the *USB endpoint callbacks* that copy
data between the hostrCOs bulk pipe and an
internal kernel FIFO. |
| **d. Userspace daemon** | adbd (in /system/bin/adbd ) | Listens on a kernel socket ( /dev/android_adb )
created by the ADB function; when WinUSB writes data,
the function driver pushes it into this socket, where
adbd reads it, parses the ADB protocol, and spawns
services (shell, logcat, sync, etc.) |
| **e. Optional mode switching** | "PTP", "MTP", "RNDIS", "Charging only" | The Android UI ( Settings --> Developer options
--> USB configuration ) writes to
/sys/class/android_usb/android0/functions to change
the list of active functions. When you select
*"ADB only"* the composite contains just the
ADB function; when you select *"MTP + ADB"* both
interfaces are present, etc. |
### How the modes appear on Windows
| Android UI selection | Interfaces exported |
|----------------------|---------------------------------------------------------------------------------------|
| **Charging only** | No USB functions --> Windows sees a simple USB Device (unknown); no driver installed. |
| **MTP** | Imaging interface (classrC>0x06). Windows loads wpdusb.sys . |
| **PTP** | Same as MTP, different subclass/protocol. |
| **RNDIS** | Miscellaneous class; Windows loads the RNDIS driver ( rndismp.sys ). |
| **ADB only** | Single vendor-specific interface --> WinUSB via android_winusb.inf . |
| **MTP + ADB**,
**RNDIS + ADB**,
etc. | Composite: multiple interfaces, each bound to
its appropriate client driver (WPD, RNDIS, WinUSB). |
When the function list changes, the kernel's USB gadget core sends a *"configuration change"* event down
to the host; Windows re-enumerates the device and may load/unload drivers accordingly. This is why you
sometimes see "Device disconnecting..." in Device Manager when you switch the phone's USB mode.
---
## TL;DR rCo The complete driver stack (Windows side)
+----------------------------------------------------------------+
| User-mode ADB client (adb.exe) |
| rooroC WinUSB API (WinUsb_*) --> winusb.sys | +-------------------+--------------------------------------------+
|
v +----------------------------------------------------------------+
| USB Bus Driver Stack |
| usbhub.sys <-- usbport.sys (EHCI/UHCI/XHCI mini-port driver) | +-------------------+--------------------------------------------+
|
v +----------------------------------------------------------------+
| Host Controller hardware (PCIe EHCI / XHCI) | +----------------------------------------------------------------+
Device object created by the bus driver:
USB\VID_18D1&PID_4EE7&MI_01 <-- matches android_winusb.inf --> binds to winusb.sys
And on the phone:
dwc3 (USB gadget controller)
rooroC configfs composite framework
roLroC function_adb (class 0xFF, subclass 0x42, protocol 0x01)
roe rooroC bulk EP IN/OUT --> kernel FIFO --> /dev/android_adb socket
roLroC function_mtp ...
rooroC function_rndis ...
adbd daemon <-- reads/writes from /dev/android_adb and implements the ADB protocol
That is the precise technical picture of how an Android phone presents
an **ADB** interface to a Windows PC, what drivers are loaded on each
side, and how the different USB "modes" are realised by adding or
removing functions in the composite gadget.
******* END: OpenAI answer (some 58GB or so model) *******
Runtime, about four minutes or so. Indicator at the bottom
of the window said "Low reasoning", which might be why the
answer came back quickly. The machine might not be big enough
for any other flavor or reasoning :-)
Paul
--- Synchronet 3.22a-Linux NewsLink 1.2
