Gsoc idea: Android downloader

Anton Lundin glance at acc.umu.se
Mon Mar 3 06:24:07 PST 2014


On 03 March, 2014 - Jef Driesen wrote:

> 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

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! =)

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

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

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

//Anton

-- 
Anton Lundin	+46702-161604


More information about the subsurface mailing list