On 16 September, 2019 - Dirk Hohndel wrote: > > > 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 :-)
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 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
