> On Sep 16, 2019, at 3:43 AM, Björn S <[email protected]> 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_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
