Gsoc idea: Android downloader

[Dirk Hohndel]

On Mon, 2014-03-03 at 15:24 +0100, Anton Lundin wrote:
> > The serial api may not be exposed to the java world, but it is certainly
> > usable from native code. As far as I know, you only needed a few minor
> > tweaks to compile libdivecomputer for Android [1]. Once we have that, an
> > Android application can simply use libdivecomputer, and there is no longer a
> > need to have access to the serial api directly. For a java applications a
> > JNI wrapper will of course be necessary.
>   
> > [1] https://github.com/glance-/libdivecomputer/commit/0f7ef245a9d0c8be533e5045b475e51acacec520
> 
> Yepp, i wrote that code =)
> 
> But its good to reference it form there, for the rest of the world and
> for the archives.
> 
> For subsurface we don't need no stinking jni wrappers, we run real code! =)

Correct. As native app we can call native code directly.

> > The main problem are indeed the kernel drivers. It's a pity enabling the
> > usb-serial kernel modules on an Android phone is non trivial (compared to
> > installing an application). Because that would be the least amount of work:
> > the kernel divers already exist and just needs to be enabled. Re-writing the
> > usb-serial drivers in userspace, will require a different driver for every
> > type of chip, and there are at least 4 of them (ftdi, prolific, silabs,
> > cdc-acm).
> 
> Kernel drivers is a no-go if you would like to support anything but
> hand-built roms. Not even CM ships any kernel-modules.
> 
> I've seen libusb based drivers for at least ftdi and acm based things,
> and ftdi is what my dc's use so I'm happy with atleast that =)

ftdi is one of the most common ones. But there are a few more. And of
course there are a few divecomputers that use different protocols. Let's
forget for a moment about the iRDA ones... but there's Bluetooth
(shouldn't be too hard - Android does have a Bluetooth stack... all we
need is to use that directly instead of the serial emulation that
current libdivecomputer still uses), some use full USB - with libusb
available, that should be possible, too. And then of course there is the
UEMIS that simulates a FAT filesystem. That should be reasonably
straight forward as well.
 
> > Assume we manage to implement the necessary userspace driver, how do we
> > integrate this nicely into libdivecomputer? This a question for which I have
> > no good answer at the moment. Right now, an application simply passes the
> > device node (e.g. /dev/ttyXXX), and libdivecomputer takes care of opening
> > the serial port. This works well because there is just one driver for each
> > platform. But once we have multiple serial drivers, we'll also need some
> > mechanism to select the right driver.
> 
> From what I've understod about usb-devices on android is that you need
> to call a user consent dialog from your app (java thingie, but you can
> call into java from c++ so thats not a problem), and then the system
> chown/setfacl the device so your app have rights to access it.
> 
> My guess would be to have a way to map all the serial calls in
> libdivecomputer to external functions that can be implemented outside
> libdivecomputer, for ex in the app that interfaces with the rest of the
> world.
> 
> From the top of my head that would be building libdivecomputer without
> any serial_*.c or maybe a serial_external.c that implements all the
> things that libdivecomputer needs, that can be enabled compile time.

That sounds like the right approach.

> > >I don't know now the Gsoc ideas list work, but his might be a interesting
> > >task to put on that list. A good scope would probably be to create a
> > >downloader-only port of subsurface for the time being.
> > 
> > I think this is a very interesting and challenging idea indeed.
> 
> I hope that someone bites the bullet and starts hacking on this one =)

You and me both. As I said before - this is the GSoC idea that I am most
interested in seeing implemented.

/D