A friendly user from the tabletrepublic forum pointed out that I was using the wrong version of the google accessory API: the com.android.future.usb.accessory API is only used on pre-gingerbread versions of the OS. Anyone else should use android.hardware.usb instead.
With that fixed, the app can be loaded onto the tablet. The device correctly switches to accessory mode, and usbManager even logs that as an event in logcat. But as in my host mode attempts, mUsbManager.getAccessoryList() always returns an empty list. The intent I registered is never called either.
Still not there.
Watching logcat while the tablet is running is quite scary, btw: so many exceptions thrown and signals not caught...
Showing posts with label accessory. Show all posts
Showing posts with label accessory. Show all posts
Sunday, 4 March 2012
Saturday, 3 March 2012
Time for plan C?
Plan B was to run the tablet in client mode, using the Android Accessory API. As it turns out, that API is also not supported by Ainol. There is a /dev/usb_accessory, which might imply that kernel support is present. But library support isn't, when I upload some test code, I get I get requires unavailable shared library com.android.future.usb.accessory.
It also turns out that using one of the USB host shields with the Jeenode wouldn't be ideal. The reason is that the shields communicate with the host using SPI. There is a hardware SPI bus on the Jeenode, but it's already used by the radio module, and sharing is tricky. It's possible to implement SPI on some of the general purpose pins in software, but I'd rather not go that route.
So, time to rethink. What's plan C? Replace the tablet? My chances would be slightly better with an ARM based device, but it's difficult to know what APIs are implemented without testing. As it is, the Ainol Paladin is pretty awful for this purpose.
It also turns out that using one of the USB host shields with the Jeenode wouldn't be ideal. The reason is that the shields communicate with the host using SPI. There is a hardware SPI bus on the Jeenode, but it's already used by the radio module, and sharing is tricky. It's possible to implement SPI on some of the general purpose pins in software, but I'd rather not go that route.
So, time to rethink. What's plan C? Replace the tablet? My chances would be slightly better with an ARM based device, but it's difficult to know what APIs are implemented without testing. As it is, the Ainol Paladin is pretty awful for this purpose.
Subscribe to:
Posts (Atom)