Problem to transfer from Suunto Vyper to Samsung S9

Mon Sep 23 07:45:44 PDT 2019

On 16 September, 2019 - Dirk Hohndel wrote:

> 
> > On Sep 16, 2019, at 3:43 AM, Björn S <bjorn.spets at gmail.com> wrote:
> > The Samsung S9 is part of the long list of Android devices that prevent the way Subsurface-mobile tries to access FTDI devices.
> > Right now there is no workaround - really nothing you can do, it simply doesn't work.
> > And yes, I realize this works with other apps on Android. This is an issue that is caused by the way we try to access the USB device. But so far we haven't found a developer with the time / knowledge to fix this problem.
> > 
> > The error message is clearly misleading and a bug - I need to figure out why that happens.
> > 
> > Is there any way I can help in this? 
> > 
> > I have the hardware (Samsung S9 and Suunto Vyper) and some basic knowledge in testing aided by Android Studio.
> > I have the latest SubSurface apk setup in Android Studio and Android Debugging Bridge functional.  
> > I can see same message in Android Studio Logcat when hitting "Download" in SubSurface as shown in application log of SubSurface app (but now obviously with no dive computer connected since USB-C connector is used to connect to Android Studio). 
> 
> Side note - I haven't tried this with AndroidStudio, but at least with adb you can have the debug connection over wifi instead of USB C and then can even look at the adb logcat while a dive computer is connected to the USB connector.
> 
> > There is a line that might have impact on this issue, or maybe due to my very basic knowledge about this it has nothing to do with the issue at all. 
> > "subj=u:r:untrusted_app_27:s0:c512,c768" 
> > Is there any way to make SubSurface to a "trusted app"?? Perhaps by https://github.com/minhng99/android_vendor_samsung_common_sepolicy/blob/master/untrusted_app.te <https://github.com/minhng99/android_vendor_samsung_common_sepolicy/blob/master/untrusted_app.te>
> I don't know what this means - our app is signed with a Google Play key and should be "trusted". Not sure if Samsung does anything else beyond that.
> 
> > A snippet from logcat showing this information in context:
> > 
> > 2019-09-16 11:54:39.571 25871-25886/? D//android/subsurface/qt-models/messagehandlermodel.cpp: INFO: "8097.377: DCDownloadThread started for Suunto Vyper on FTDI downloading only new dives"
> > 2019-09-16 11:54:39.579 25871-25737/? D//android/subsurface/qt-models/messagehandlermodel.cpp: INFO: Starting download from  ftdi
> > 2019-09-16 11:54:39.580 25871-25737/? D//android/subsurface/qt-models/messagehandlermodel.cpp: INFO: downloading only new dives
> > 2019-09-16 11:54:39.580 25871-25737/? D//android/subsurface/core/serial_ftdi.c: INFO: in ftdi_open
> > 2019-09-16 11:54:39.581 25871-25737/? D//android/subsurface/core/serial_ftdi.c: INFO: serial_ftdi_open called
> > 2019-09-16 11:54:39.581 25871-25737/? D//android/subsurface/core/serial_ftdi.c: INFO: setting up ftdi_ctx
> > 2019-09-16 11:54:39.581 25871-25737/? D//android/subsurface/core/serial_ftdi.c: INFO: failed ftdi_new()
> 
> This is where everything falls apart. libusb which Subsurface uses to connect to USB devices tries to access the USB port through a filesystem based enumeration that on most current Android systems is no longer accessible to native code and therefore fails.
> 
> > 2019-09-16 11:54:39.581 25871-25737/? D//android/subsurface/core/serial_ftdi.c: INFO: serial_ftdi_open() failed
> > 2019-09-16 11:54:39.582 6273-6273/? E/audit: type=1400 audit(1568627679.574:5837): avc:  denied  { read } for  pid=25871 comm="DownloadThread" name="devices" dev="sysfs" ino=21222 scontext=u:r:untrusted_app_27:s0:c512,c768 tcontext=u:object_r:sysfs:s0 tclass=dir permissive=0 SEPF_SM-G960F_9_0007 audit_filtered
> 
> Here's the audit message that you point out above about this very error. sysfs/devices isn't accessible to us.
> 
> > 2019-09-16 11:54:39.582 6273-6273/? E/audit: type=1300 audit(1568627679.574:5837): arch=c00000b7 syscall=56 success=no exit=-13 a0=ffffff9c a1=712ada554c a2=84000 a3=0 items=0 ppid=6281 pid=25871 auid=4294967295 uid=10347 gid=10347 euid=10347 suid=10347 fsuid=10347 egid=10347 sgid=10347 fsgid=10347 tty=(none) ses=4294967295 comm="DownloadThread" exe="/system/bin/app_process64" subj=u:r:untrusted_app_27:s0:c512,c768 key=(null)
> > 2019-09-16 11:54:39.582 6273-6273/? E/audit: type=1327 audit(1568627679.574:5837): proctitle="org.subsurfacedivelog.mobile"
> 
> As I mentioned several times before - Anton has a pretty good idea how this could be fixed, but he doesn't have the time. Maybe he can send you a summary and you would have the time to work on this?
> 
> We should move this to the developer mailing list :-)

I've planned to write a nice answer for this for quite some time, but
never gotten around to it, so here comes the brain-dump version.
It might not be all that coherent, but its probably better than no
answer at all.

First of all, I'd just try to run our current code on a libusb
containing:
https://github.com/libusb/libusb/commit/2f3bc98b0d0f4766496df53c855685a5f0e5e7cf

That will most probably fix our issue with ftdi_init/libusb_init
failing, but because that disables all scanning after devices, it will
just turn our current failure into we not finding any devices.

My preferred solution here would be to patch linux_scan_devices to have
a callback into subsurface which could do the scanning against java code
here, and fill up the libusb data structures. I have some unfinished
code working on this path, and its basically the same approach as in our
"open" patch. The upside with this is that it keeps all our non ftdi
libusb using backends in libdivecomputer still working.

Another way would be to e move serial_ftdi_open_device from its
current searching by vid/pid to having the upper layers do the searching
for the right device from java code, and just passing down the right
bits needed to serial_ftdi_open_device. Subsurface jni's into "android"
discovering all ftdi devices, user picks one, and we pass that
information/fd into serial_ftdi_open_device, which calls
libusb_wrap_sys_device , and then wrapps that with ftdi_usb_open_dev.
The upside is that we don't need a patched libusb any more, the downside
is that we drop support for the usb based libdivecomputer backends.

Third option, "The nuclear option" is to drop the whole libftdi based
custom serial backend serial_ftdi.c and write a custom_serial backend
which jni's into something like
https://github.com/mik3y/usb-serial-for-android instead.
The upside for this is that we can start supporting Prolific and Silabs
devices to, but the downside is that its hard to test on a "regular"
linux machine, and probably quite a bit of work.

This is really a "choose your own adventure" kind of deal.

//Anton

-- 
Anton Lundin	+46702-161604