Android and libusb

Dirk Hohndel dirk at hohndel.org
Mon Sep 30 18:49:21 PDT 2019


> On Sep 30, 2019, at 11:55 AM, Anton Lundin <glance at acc.umu.se> wrote:
>>> Yea, its a quite complex call chain, but I thin it can be simplified to
>>> filling out struct libusb_device and calling usbi_connect_device on
>>> those.
>>> 
>>> UsbManager.getDeviceList() gives us enough to fill in the libusb_device
>>> structs.
>> 
>> Hmm - I hadn't planned to go that route. We already have the intent handling
>> that talks to us when a device is connected. And that gives us the one USB
>> device that we need to talk to - so why even get that list?
>> 
> 
> Its probably easier to just generate the whole list, rather than keep
> some intent data around. The use might not even care about the intent,
> and dismisses it, and then later starts subsurface manually, and expect
> to be able to download.

You are absolutely correct. Simply in the regular debugging cycle it becomes 
obvious that this is needed: 
connect dive computer, Subsurface-mobile pops up
try things out, fail
edit sources, rebuild, use adb over wifi to upload new version
if you now want to try things out in my model you'd have to unplug/replug the DC.

So yeah, I decided to go your suggested route. And it turned out to be
surprisingly simple once I had wrapped  my mind around the machinations it
takes to unpack the java data structures.

> If you look at the UsbDevice class and the struct libusb_device, they're
> quite similar, so just lift over the values.
> 
> I haven't dug down into it, but I'm guessing its actually libusb on the
> other side of that UsbDevice class.

There are quite a few similarities, but as I had pointed out, there are also a
fair number of things that are different / appear to be missing on the JNI side.

My current NO WORKING code is in https://github.com/Subsurface-divelog/subsurface/pull/2309 <https://github.com/Subsurface-divelog/subsurface/pull/2309>

It's based on your two patches to libusb - those didn't even compile, but
they were a great starting point and I added the parts that actually allows 
us to assemble the devices array from android.cpp - and I added the JNI
code there to do just that.

This gets pretty far. I can see my OSTC, and when I try to open it from 
serial_ftdi.c we get pretty far and we don't fail with permission errors based 
on file system access but instead there's an issue reading the configuration. 

I even think I have an idea why that is - I'm guessing that I need to populate 
more of the endpoint information somehow.

I'll be traveling the next two days and while I'll take the little dive computer
with me I am not convinced that I'll really have any time to work on this. So
if anyone else wants to poke at it, feel free to give it a go.

/D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20190930/5a86c308/attachment.html>


More information about the subsurface mailing list