How to filter ADK device with FSL USB stack?

[kai_liu]

After implementing ADB on Android, I am evaluating ADK on FSL (MKL26Z with I2S interface).

According to USBHOSTUG.pdf from Freescale, the stack defines driver_info_table for supported devices, including PID/VID/class/subclass of the USB devices.

Only if desired USB devices is matched, then host stack starts communication between EPs.

The procedure is perfect for most devices. It is not good for Android devices.

First of all, most Android devices have custom PID/VID, which doesn't make sense at all. And most of them have following combinations:

bDeviceClass:         0x00

bDeviceSubClass:      0x00

bDeviceProtocol:      0x00

So the driver_info_table used in enumeration will fail anyway.

Only if Android device re-enumerating itself as Google VID/PID/class/subclass, the driver info table can work well.

The solution is obviously, send CONTROL request to connected device to enable ADK anyway, then using driver_info_table.

The issue is: I have no idea how to send CONTROL request to toggle ADK mode on Android phone without driver_info_table. How?

==================

The following chapter comes from Android developer page:

Determine the connected device's accessory mode support

When a device is connected to the ADK board, it can already be in accessory mode, support accessory mode and is not in that mode, or does not support accessory mode. The AndroidAccessory::isConnected() method checks for these cases and responds accordingly when the loop() function calls it. This function first checks to see if the device that is connected hasn't already been handled. If not, it gets the connected device's device descriptor to figure out if the device is already in accessory mode by calling AndroidAccessory::isAccessoryDevice(). This method checks the vendor and product ID of the device descriptor. A device in accessory mode has a vendor ID of 0x18D1 and a product ID of 0x2D00 or 0x2D01. If the device is in accessory mode, then the ADK board can establish communication with the device. If not, the board attempts to start the device in accessory mode.

Attempt to start the device in accessory mode

If the device is not already in accessory mode, then the ADK board must determine whether or not it supports it by sending control request 51 to check the version of the USB accessory protocol that the device supports (see AndroidAccessory::getProtocol()). Protocol version 1 is supported by Android 2.3.4 (API Level 10) and higher. Protocol version 2 is supported by Android 4.1 (API Level 16) and higher. Versions greater than 2 may supported in the future. If the appropriate protocol version is returned, the board sends control request 52 (one for each string with AndroidAcessory:sendString()) to send it's identifying information, and tries to start the device in accessory mode with control request 53.

If this method returns false, the board waits until a new device is connected. If it is successful, the device displays itself on the USB bus as being in accessory mode when the ADK board re-enumerates the bus. When the device is in accessory mode, the accessory then establishes communication with the device.

[kai_liu]

Any update or upgrade for USB stack can solve multiple driver registration?

[kai_liu]

I found a fact that there are already two devices have been added to driver table, one is custom class,the other is hub. So I can add mobile and google salsa into that driver table.