Gsoc idea: Android downloader

Jef Driesen jef at libdivecomputer.org
Mon Mar 3 05:56:04 PST 2014


On 2014-02-26 09:45, Anton Lundin wrote:
> One idea i bin playing with is how to make the Android port capable of
> downloading data from divecomputers.

A port of libdivecomputer to Android is also something I'm interested 
in. Bringing your smartphone or tablet near the dive site is far more 
convenient than a laptop :-)

> Android doesn't contain a serial api, and it doesn't include the usual
> usb-serial drivers that comes along in the Linux source tree.
> 
> It provides enough attachment points as far as i can understand that we
> would be capable to run a usb-serial driver in userspace.
> 
> The current Android builds contains libdivecomputer and libusb. To make
> this possible we would need to extend libdivecomputer to talk to usb
> devices in other ways on android. There are a bunch of libraries to 
> talk
> to the most common usb-serial chips available.[1,2,3]
> 
> 1. https://code.google.com/p/android-serialport-api/
> 2. https://github.com/mik3y/usb-serial-for-android
> 3. http://www.intra2net.com/en/developer/libftdi/

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

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).

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.

> 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.

Jef


More information about the subsurface mailing list