Android FTDI support not working with fresh app build

[Bill Perry]

On 09/14/2018 08:56 AM, Anton Lundin wrote:
> On 13 September, 2018 - Bill Perry wrote:
>
>> The android app downloaded from the Playstore behaves differently than the one I just built from current sources.
> How did you build the mobile app for android?
note: did you see the latest strangeness: http://lists.subsurface-divelog.org/pipermail/subsurface/2018-September/033025.html
Where libdivecomputer command/message delays don't work on the 4.8.1 app from the playstore but do work with the 4.8.1 that I built.
This was verified with a logic analyzer with the apps running on a Galaxy S4 with Android 4.4.4 and a Galaxy S7 running Android 8.0.0

I followed the instructions from the INSTALL file, except the only package I added to a newly installed Mint 18 OS install was cmake.
I'm building on freshly installed fully up to date 64bit Linux Mint MATE 18.3 in a virtual box vm.
I forked the subsurface repository then cloned from my github repo.
I did the submodule update to get the proper libdivecomputer
I then ran bash subsurface/packaging/android/android-build-wrapper.sh to build the .apk
I never built the code for the desktop.

After I sent the first post about this, I went back and started over with clean clone of the repo and
I installed all the recommended Ubuntu 18.04 packages (even though Mint 18 is based on Ubuntu 16.04)
and rebuilt the app after a clean/fresh clone.
That build would come up but immediately crash on both Android 4.4.4 and Android 8.0.0
I then started over again with a clean/fresh clone and checked out v4.8.1 and then
followed the same steps to build the apk
Nothing else was changed on the machine other then I started with a clean clone and checked out v4.8.1 vs using the head of Master.
This apk worked as expected including having the proper command/message delays
whereas the current app from the app store (4.8.1) does not have the proper delays.

I'm at a loss to explain the delay issue, but I can see it on a logic analyzer.


>
>> I'm currently testing on a Samsung GS4 running kitkat 4.4.4
>>
>> With the one from the play store: version 2.1.0(4.8.0)
>>
>> - When the cable is plugged in OS asks to run subsurface.
>> NOTE: it will not do this if running the app in no cloud mode.
>> and it also won't talk over the ftdi cable either.
>> Once in cloud mode,
> Nope. This has nothing to do with each other.
I hear you and agree it shouldn't be related but I saw this more than once.
I wasn't focusing on this at the time so I just went ahead and connected to the cloud account so I
could get the serial port to spit out some data to look at the timing.
I'll go back and try to replicate and verify this and the details on if/how to replicate it
assuming I can replicate it.

Also, there is no way to download using the FTDI cable if Bluetooth is not enabled.
If bluetooth is not enabled, it won't let you download at all.

>
>> - It can open the port and push bytes out the data cable
>> However, the timing between the bytes & messages is wrong (which is what I'm trying to fix)
>>
>> With the one I just built: version 2.1.2(4.8.1.413)
>> It appears to not be able to open the serial connection.
>> The libdivecomputer log shows:
>> ====================
>> Subsurface: v4.8.1-413-g76c4fb397512, built with libdivecomputer v0.7.0-devel-Subsurface-NG (8f2ac8f61e8768d4774983de1f367f73c8c34ea2)
>> INFO: Open: name=ftdi
>> ERROR: No such file or directory (2) [in /home/bill/Documents/devel/Subsurface-devel/subsurface/libdivecomputer/src/serial_posix.c:295 (dc_serial_open)]
>> ====================
>> Which seems to indicate it is trying open the device "ftdi" vs checking for the magic "ftdi" name and calling the ftdi serial code instead of serial_posix code.
>> Have I not built the app properly, or is the code broken right now and I should go back to the tagged code from the last release?
> You haven't built the app properly.
I figured as much, but I didn't really know why.
I can only assume (perhaps incorrectly) that the subsurface/packaging/android/android-build-wrapper.sh script
looks for the existence of libusb being installed and if it doesn't see it installed doesn't include support for it in the mobile build.
The first build I did, I didn't have libusb-1.0-0-dev package installed on the machine.

The big clue for me is that dc_serial_open() is being called.
This only gets called for /dev type devices.
It should not be called for the fake/magic "ftdi" device filename that is used when selecting the "FTDI" device
from the download UI.


>
>> "23.558: DCDownloadThread started for Aeris Atmos AI on FTDI"
>> Starting download from  ftdi
>> "23.579: Looking at device with VID/PID 1478/36940"
>> "23.579: Looking at device with VID/PID 1027/24577"
>> "23.580: usbManager tells us we don't have permission to access this device"
> This is the money shot: You didn't give Subsurface mobile access to this
> usb device, thus android denies us access to it.

To me the money shot was actually the information from the libdivecomputer log where
dc_serial_open() in serial_posix.c was being called. This appeared to indicated that it was trying to
open a device named "ftdi" vs doing the check for the fake name and handling it
through the other usb code.
I'm assuming that the permission issue is that it could not open a file named "ftdi" because it doesn't have write permission to the directory to create a file by that name
rather than an actual usb permission issue since the incorrectly called serial code was trying to open a device named "ftdi" which does not exist and is not even a device.

--- bill