Android FTDI support not working with fresh app build

[Anton Lundin]

On 14 September, 2018 - Bill Perry wrote:

> 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.

Might be anything. My suspect would be powersave on your android device.

 
> >
> >> 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.
> 

Ok. Just another bug. Document how to reproduce it, and file it.

> >
> >> - 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.

Doesn't matter. That libusb isn't used for anything, and if it does
matter, triangulate it and file the bug.

> 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.
 
Wrong. Read the code. Its always called as a last resort.

> >
> >> "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.

Wrong. Read the code. The ftdi_open call is before dc_serial_open. If
ftdi_open fails, then dc_serial_open is called.


//Anton


ps. I think the conditional return in:
#ifdef SERIAL_FTDI
	if (!strcmp(data->devname, "ftdi")) {
		rc = ftdi_open(&data->iostream, context);
		if (rc == DC_STATUS_SUCCESS)
			return rc;
	}
#endif

is wrong. If the devname is "ftdi" we should always return, whatever
ftdi_open returned.

ds.


-- 
Anton Lundin	+46702-161604