Problem to transfer from Suunto Vyper to Samsung S9

[Dirk Hohndel]

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

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