After trying the USB Host API mode yesterday, I now decided to see if the accessory mode (which has the tablet in client mode) works. But, it looks like that's not supported either. When uploading a test app, I get requires unavailable shared library com.android.future.usb.accessory. There is a /dev/usb_accessory, so maybe the kernel at least has the required elements, but at least the support from the java side is missing. This post suggest it's a question of missing com.android.future.usb.accessory.jar, but I guess that has native code in it, so I'd need a MIPS version of that library...
Any suggestions? If neither host nor client modes work, I'll have to sell this tablet and look for something with better OS implementation (or hope for a cyanogen rom...)
uh oh , i think i'm the one gonna need your help ) i do have the device that arduino compatible, and the usbManager still returns NULL on getAccessoryList(). My question is: when are they switched to accessory mode? on which line of code (and which file/class)?
What I notice is that the device PID initially is 0xdddd (through lsusb in linux). When I connect in accessory mode, it switches to either 0x2D00 or 0x2D01 (still need to find out why there are two options).
When I initialize a connect from linux, I can see in logcat messages from UsbManager. Unfortunately even if I run adb through wireless (in order to free up the usb port) adb disconnects the moment I connect as accessory mode, so I can only see logcat on the device (and can't cut and paste here). With a bit more time, I can save the log file and get the relevant messages, maybe tomorrow evening.
I have an Advanced II (with the stock 4.0.3) and I do also have an Arduino board.
First off, to explain the two different PIDs:
The first is used when USB Debugging is off, the second when it is on. With USB Debugging on, it will report two Interfaces (the Accessory Mode and ADB).
You said you use a custom ROM. May I ask which one you're using?
What happens internally is pretty straight-forward:
The host checks the VID and PID. If its not an Android Accessory enabled device (i.e. Google's VID and either 0x2D00 or 0x2D01 as PID), it sends three custom USB control requests:
six cases of ACCESSORY_SEND_STRING
These are important, because Android uses these to find the App to handle this specific accessory.
If the device does not support Android Accessory mode at all, it will return a STALL (0x05) to any of these commands. Otherwise it will, after receiving the ACCESSORY_START command, disconnect from the bus and reconnect with the new VID/PID combination. It will then have two mass transfer endpoints for communication.
Now, I have this problem with the stock ROM:
It starts off with PID 0x0001 and after the hosts sends the above command sequence, it does switch, but the new PID is 0x0004 (or 0x0002 and 0x0005 if USB Debugging is on) and Android does not even ask to open the DemoKit app.
Even if I program my firmware to treat 0x0004 as an Android Accessory enabled device, the communication does not work. Like I mentioned, Android does not react to the switch like it should.
So, if your ROM does in fact switch to 0x2D00 or 0x2D01, that would certainly be an improvement for me.