Bit of a mess though. They somehow managed to make a fairly simple (but still a bit weird) library - libusb - into something less than the sum of it's parts (discordant vs syngergistic?). And then you add to that the complex life-cycle of an android app and things get pretty nasty.
Some pretty weird shit to deal with:
- If you don't set the app as the default handler for the device, then you get permission popups which mean you have to put the connect logic in the resume method otherwise nothing works.
- But if it is defaulted, ... then you don't get permission popups, and therefore resume is not called at the right time.
- If you tell a connected device to go into accessory mode, you get a device disconnected message, which sort of makes sense ...
- ... but you don't get a connected message for the accessory device.
- And if you subsequently list the devices connected to the system, a device is still listed with the same vendor id + device id (this is wrong, the device should have changed at this point) ...
- ... but that "device" isn't the same as the "device" you started with.
- And there seems to be no "reliable" way to determine if you have the accessory interface, or the MTP interface (on the machine i'm testing with). (well maybe testing using a no side-effect valid request which fails could be used here).
- If the device rotates it destroys the application ... leaving everything in an unknown state.
- Sometimes nothing works anyway, and the apps on both end need killing.
- The documentation is a bit shit, and amounts to "the [outdated] source is the documentation". And that relies on a USB library which doesn't fudge the device id.
But with all that I did manage to send strings both ways so now the challenge is to sort through the cruft i've ended up with and turn it into something robust and hopefully simple.
In other android news i finally restarted on the ffts-related work and will scale down the initial goals to get something out the door.