Subsurface mobile [phone]) Pelagic data cable issues

[Bill Perry]

I was able to use the Pelagic data cable with an Atmos AI and download dives with a 4.8.1 app that I built.
The latest 2.1.2(4.8.2.0) doesn't work on the Galaxy S4 with Android 4.4.4 or Galaxy 7 with Android 8.0.0

With 4.8.1 Subsurface, Subsurface came up as one of the apps to run when the data cable was plugged in.

With Subsurface 2.1.2(4.8.2.0) on the Galaxy S4 with Android 4.4.4,
Subsurface is not one of the apps that comes up when the data cable is plugged in.

With Subsurface 2.1.2(4.8.2.0) on the Galaxy S7 with Android 8.0.0,
Subsurface is one of the apps that comes up when the data cable is plugged in.

On both phones, the download immediately crashes the app.

To replicate: (You don't need a datacable or dive computer to cause this)

select Aeris, Atmos AI, and FTDI
Click [Download]

The app crashes, regardless of whether the data cable is plugged in.
The 4.8.1 app didn't crash if the data cable was not plugged in and worked if it was plugged in and properly connected to the dive computer.

--- bill

[Bill Perry]

I left out that the 2.1.2(4.8.2.0) that I used was from the Play Store.

--- bill

Post by Bill Perry
I was able to use the Pelagic data cable with an Atmos AI and download dives with a 4.8.1 app that I built.
The latest 2.1.2(4.8.2.0) doesn't work on the Galaxy S4 with Android 4.4.4 or Galaxy 7 with Android 8.0.0
With 4.8.1 Subsurface, Subsurface came up as one of the apps to run when the data cable was plugged in.
With Subsurface 2.1.2(4.8.2.0) on the Galaxy S4 with Android 4.4.4,
Subsurface is not one of the apps that comes up when the data cable is plugged in.
With Subsurface 2.1.2(4.8.2.0) on the Galaxy S7 with Android 8.0.0,
Subsurface is one of the apps that comes up when the data cable is plugged in.
On both phones, the download immediately crashes the app.
To replicate: (You don't need a datacable or dive computer to cause this)
select Aeris, Atmos AI, and FTDI
Click [Download]
The app crashes, regardless of whether the data cable is plugged in.
The 4.8.1 app didn't crash if the data cable was not plugged in and worked if it was plugged in and properly connected to the dive computer.
--- bill

[Bill Perry]

Ok, it seems that there is a newer version of Subsurface mobile available now. 2.1.3(4.8.2.5)
vs the 2.1.2(4.8.2.0) that was released yesterday.

While this release is better, it still has issues.

Downloads are now working on the GS7 (Android 8.0.0)
But it still doesn't work on the GS4 (Android 4.4.4)
(The subsurface 4.8.1 that I built from sources worked on both the GS7 and the GS4)

The app on the GS4 was upgraded from 2.1.2(4.8.2.0) to 2.1.3(4.8.2.5)
When the data cable was plugged in Subsurface was not showing up as an app to use the usb device. (It does on the GS7 running Android 8.0.0)
The app was started manually, and it jumped to the divelist sreen with all the cloud synchronized dives.
I went to try a download using the FTDI data cable for the Aeris Atmos AI.
When [Download] was clicked the app crashed just like with 2.1.2(4.8.2.0)

I then uninstalled the app, and re-installed it.
I started the app. It asked for cloud credentials which I entered and it synchronized.
I exited the app, and plugged in the data cable. The subsurface app does not show up as an app to use the USB device.
(It does on the GS7 running Android 8.0.0 and and it did when running a 4.8.1 mobile app that I built from sources)
When [Download] is clicked the download fails.
I'm assuming that this is related to the app not showing up and being selected for using the USB device when the datacable is plugged in.

Here is the output from libdivecomputer.log

==================================
Subsurface: v4.8.2-5-g4fc0d9ee132c, built with libdivecomputer v0.7.0-devel-Subsurface-NG (fb70928c83ee09f7a74158d7c316fb18334caf6e)
==================================

Here is the relevant part of subsurface.log

==================================
"60.711: DCDownloadThread started for Aeris Atmos AI on FTDI"
Starting download from  ftdi
"60.781: Looking at device with VID/PID 1478/36940"
"60.781: Looking at device with VID/PID 1027/62560"
"60.782: usbManager tells us we don't have permission to access this device"
"60.782: Input/output error"
Finishing download thread: "Unable to open ftdi Aeris (Atmos AI)"
no new dives downloaded
"60.840: DCDownloadThread finished"
"66.989: AppState changed to inactive with no save ongoing and no unsaved changes"
"67.557: AppState changed to suspended with no save ongoing and no unsaved changes"
==================================


There is also one new minor annoyance.
The code is now trying to be "smart" by jumping directly to the dive download screen
and pre-selecting a the vendor name when the datacable is plugged in.

This seems nice, but in my case, the vendor of the cable is Oceanic but the dive computer is Aeris.
And even if I did have an Oceanic dive computer, it doesn't remember the last used dive computer.
It seems like simply remembering the last used device information (vendor name, dive computer, connection)
would actually be MUCH simpler and right more often than trying to guess the correct one,
particularly when the user is repeatedly doing downloads from the same dive computer say daily during a dive trip  - which is my usage case.

Perhaps there could be some smarts that if the VID/PID match the last used on, that all the last used settings are used.
If VID/PID doesn't match the last one used, then try to guess or just don't fill in anything just to keep things really simple.

--- bill

[Dirk Hohndel]

Post by Bill Perry
"60.711: DCDownloadThread started for Aeris Atmos AI on FTDI"
Starting download from ftdi
"60.781: Looking at device with VID/PID 1478/36940"
"60.781: Looking at device with VID/PID 1027/62560"
"60.782: usbManager tells us we don't have permission to access this device"

Well, Android thinks that you told it not to allow Subsurface-mobile to access your dive computer. Not much we can do then.

/D

[Bill Perry]

Post by Dirk Hohndel

Post by Bill Perry
"60.711: DCDownloadThread started for Aeris Atmos AI on FTDI"
Starting download from ftdi
"60.781: Looking at device with VID/PID 1478/36940"
"60.781: Looking at device with VID/PID 1027/62560"
"60.782: usbManager tells us we don't have permission to access this device"

Well, Android thinks that you told it not to allow Subsurface-mobile to access your dive computer. Not much we can do then.
/D

Clearly something is possible as it works in the 4.8.1 code that I build from sources and nothing on the phone has changed other than installing the new app from the playstore.
I'm assuming it could be related to the Subsurface app not showing up as an app for the USB device when the data cable is plugged in.
Is the USB manager responsible for poppping up that USB device/app dialog and then granting permission to the selected app ?

---bill

[Dirk Hohndel]

Post by Bill Perry
Clearly something is possible as it works in the 4.8.1 code that I build from sources and nothing on the phone has changed other than installing the new app from the playstore.
I'm assuming it could be related to the Subsurface app not showing up as an app for the USB device when the data cable is plugged in.
Is the USB manager responsible for poppping up that USB device/app dialog and then granting permission to the selected app ?

My guess is that you tapped on "no" by mistake at some point.
I'm sure this can be reset somehow in the settings, but I don't know how of the top of my head.

/D

[Bill Perry]

Something odd is going on with the my S4 running Android 4.4.4 (the latest playstore app works on the S7 Android 8.0.0)

On the S4

With the 2.1.1(4.8.1.0) app built from source a "Choose app for the USB device" dialog comes up with Subsurface-mobile in the choices.
With the 2,1.3(4.8.2.5) this dialog does not come up.

2.1.1(4.8.1.0) built from source can access the ftdi device when run from the USB choose app dialog.
2.1.3(4.8.2.5) from the app store can not access the ftdi device and gets the permission error.


I'm still trying to figure out what is going on.

Post by Dirk Hohndel

Post by Bill Perry
Clearly something is possible as it works in the 4.8.1 code that I build from sources and nothing on the phone has changed other than installing the new app from the playstore.
I'm assuming it could be related to the Subsurface app not showing up as an app for the USB device when the data cable is plugged in.
Is the USB manager responsible for poppping up that USB device/app dialog and then granting permission to the selected app ?

My guess is that you tapped on "no" by mistake at some point.
I'm sure this can be reset somehow in the settings, but I don't know how of the top of my head.
/D

[Dirk Hohndel]

How do you feel with signing your app with a different certificate. Did you change the name?

Post by Bill Perry
Something odd is going on with the my S4 running Android 4.4.4 (the
latest playstore app works on the S7 Android 8.0.0)
On the S4
With the 2.1.1(4.8.1.0) app built from source a "Choose app for the USB
device" dialog comes up with Subsurface-mobile in the choices.
With the 2,1.3(4.8.2.5) this dialog does not come up.
2.1.1(4.8.1.0) built from source can access the ftdi device when run
from the USB choose app dialog.
2.1.3(4.8.2.5) from the app store can not access the ftdi device and
gets the permission error.
I'm still trying to figure out what is going on.

Post by Dirk Hohndel

On Sep 19, 2018, at 1:22 PM, Bill Perry
Clearly something is possible as it works in the 4.8.1 code that I

build from sources and nothing on the phone has changed other than
installing the new app from the playstore.

Post by Dirk Hohndel

I'm assuming it could be related to the Subsurface app not showing

up as an app for the USB device when the data cable is plugged in.

Post by Dirk Hohndel

Is the USB manager responsible for poppping up that USB device/app

dialog and then granting permission to the selected app ?

Post by Dirk Hohndel
My guess is that you tapped on "no" by mistake at some point.
I'm sure this can be reset somehow in the settings, but I don't know

how of the top of my head.

Post by Dirk Hohndel
/D

[Bill Perry]

Post by Dirk Hohndel
How do you feel with signing your app with a different certificate. Did you change the name?

I have no feelings about it.
Are you wanting to have multiple subversion apps installed at the same time?

All I did to build the mobile app from sources was checkout the v4.9.1 tag and run the scripts as noted the INSTALL file in the subsurface tree.
Actually, after I modified any libdivecomputer files I manually ran make down in libdivecomputer-build-arm
and subsurface-mobile-build-arm as the subsurface/packaging/android/build.sh script didn't work for me beyond the first run as it didn't rebuild the libdivecomputer library
when source files changed and it rebuilt lots of things it didn't need to re-build.

The name of the app created is subsurface-mobile-build-arm-debug.apk
Currently, I'm just using the samsung file manager to install it from a thumb drive rather than transferring it over using adb
as I wasn't intending to do very many builds & installs.



--- bill

Post by Dirk Hohndel
Something odd is going on with the my S4 running Android 4.4.4 (the latest playstore app works on the S7 Android 8.0.0)
On the S4
With the 2.1.1(4.8.1.0) app built from source a "Choose app for the USB device" dialog comes up with Subsurface-mobile in the choices.
With the 2,1.3(4.8.2.5) this dialog does not come up.
2.1.1(4.8.1.0) built from source can access the ftdi device when run from the USB choose app dialog.
2.1.3(4.8.2.5) from the app store can not access the ftdi device and gets the permission error.
I'm still trying to figure out what is going on.
installing the new app from the playstore. I'm assuming it could be related to the Subsurface app not showing up as an app for the USB device when the data cable is plugged in. Is the USB manager responsible for poppping up that USB
device/app dialog and then granting permission to the selected app ?
My guess is that you tapped on "no" by mistake at some point. I'm sure this can be reset somehow in the settings, but I don't know how of the top of my head. /D
--
From my phone

[Dirk Hohndel]

Post by Bill Perry

Post by Dirk Hohndel
How do you feel with signing your app with a different certificate. Did you change the name?

I have no feelings about it.

Grr. Don't respond on the phone, Dirk.

The question was supposed to be "how do you DEAL with signing your app"

i.e., did you give your app a different name so you wouldn't have a signature conflict when installing it?

Post by Bill Perry
Are you wanting to have multiple subversion apps installed at the same time?
All I did to build the mobile app from sources was checkout the v4.9.1 tag and run the scripts as noted the INSTALL file in the subsurface tree.
Actually, after I modified any libdivecomputer files I manually ran make down in libdivecomputer-build-arm
and subsurface-mobile-build-arm as the subsurface/packaging/android/build.sh script didn't work for me beyond the first run as it didn't rebuild the libdivecomputer library
when source files changed and it rebuilt lots of things it didn't need to re-build.
The name of the app created is subsurface-mobile-build-arm-debug.apk
Currently, I'm just using the samsung file manager to install it from a thumb drive rather than transferring it over using adb
as I wasn't intending to do very many builds & installs.

What I'm wondering is if somehow Android now only delivers the connect Intent to your app and no longer offers it to the official one.

In other words, I'm grasping for straws.

/D

[Bill Perry]

Post by Dirk Hohndel

Post by Bill Perry

Post by Dirk Hohndel
How do you feel with signing your app with a different certificate. Did you change the name?

I have no feelings about it.

Grr. Don't respond on the phone, Dirk.
The question was supposed to be "how do you DEAL with signing your app"
i.e., did you give your app a different name so you wouldn't have a signature conflict when installing it?

Auto correct can do funny things.

I didn't do anything special or any sort of signing.
I used the .apk file as named and created by the makefile down in subsurface-mobile-build-arm
I used "unknown sources" to side load it from a thumb drive.
As another test I installed my source built .apk  on another S4 and the first time it is loaded from the thumb drive there is a warning from the Play service
that this code is from an unknown developer. You can click on "install anyway" to install it.
You won't get the warning again on future installs. (I had forgotten about this)

It is strange since the current app installed from the play store works just fine on my S7 running Android 8.0.0 with the same datacable and divecomputer.
And gets the "select an application for the USB device" dialog with Subsurface being one of the applications.

As a side note, the USB device app dialog does come up on both phones.
Divemate is also installed on the S4 and the S7 and it shows up in the USB device dialog on both phones when the data cable is plugged in.
However, Subsurface only shows up in the USB device dialog with the 2.1.1(4.8.1.0) app built from source
and not when using the 2,1.3(4.8.2.5) app installed from the play store.

I'm still digging. It is driving me crazy.
I'll come back when I know more about what is going on.

Post by Dirk Hohndel

Post by Bill Perry
Are you wanting to have multiple subversion apps installed at the same time?
All I did to build the mobile app from sources was checkout the v4.9.1 tag and run the scripts as noted the INSTALL file in the subsurface tree.
Actually, after I modified any libdivecomputer files I manually ran make down in libdivecomputer-build-arm
and subsurface-mobile-build-arm as the subsurface/packaging/android/build.sh script didn't work for me beyond the first run as it didn't rebuild the libdivecomputer library
when source files changed and it rebuilt lots of things it didn't need to re-build.
The name of the app created is subsurface-mobile-build-arm-debug.apk
Currently, I'm just using the samsung file manager to install it from a thumb drive rather than transferring it over using adb
as I wasn't intending to do very many builds & installs.

What I'm wondering is if somehow Android now only delivers the connect Intent to your app and no longer offers it to the official one.
In other words, I'm grasping for straws.
/D

[Anton Lundin]

Post by Dirk Hohndel

Post by Bill Perry

Post by Dirk Hohndel
How do you feel with signing your app with a different certificate. Did you change the name?

I have no feelings about it.

Grr. Don't respond on the phone, Dirk.
The question was supposed to be "how do you DEAL with signing your app"
i.e., did you give your app a different name so you wouldn't have a signature conflict when installing it?

This is how I do it:

commit eb42e3c0190acf0e03c57c83f0ef3f04c1f05599
Author: Anton Lundin <***@acc.umu.se>
Date: Wed Jun 20 20:03:46 2018 +0200

JUNK: Rename mobile app for local dual install

diff --git a/android-mobile/AndroidManifest.xml b/android-mobile/AndroidManifest.xml
index 0a591eb99..c655a3a89 100644
--- a/android-mobile/AndroidManifest.xml
+++ b/android-mobile/AndroidManifest.xml
@@ -1,6 +1,6 @@
<?xml version='1.0' encoding='utf-8'?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
- package="org.subsurfacedivelog.mobile"
+ package="org.subsurfacedivelog.mobile.anton"
android:installLocation="auto"
android:versionCode="@BUILD_NR@"
android:versionName="@SUBSURFACE_MOBILE_VERSION@" >
@@ -8,12 +8,12 @@
<application
android:name="org.qtproject.qt5.android.bindings.QtApplication"
android:hardwareAccelerated="true"
- android:label="@string/app_name"
+ android:label="Anton-ssrf"
android:icon="@drawable/subsurface_mobile_icon" >
<activity
android:name="org.qtproject.qt5.android.bindings.QtActivity"
android:configChanges="orientation|uiMode|screenLayout|screenSize|smallestScreenSize|locale|fontScale|keyboard|keyboardHidden|navigation"
- android:label="@string/app_name"
+ android:label="Anton-ssrf"
android:theme="@style/AppTheme"
android:launchMode="singleTop"
android:windowSoftInputMode="adjustResize"


That way I can see which is which, and I can have them both installed at
the same time.

Bill: I suggest you do something equivalent if you're planing on playing
around both with the official and your own builds of subsurface mobile.


//Anton

[Bill Perry]

Here is the latest.
I have built apps from tags v4.8.1 and v4.8.2
They behave differently when the data cable is inserted on my S4 (Android 4.4.4)
with v4.8.1 and older apps (prior to 2.1.3(4.2.5) from the Playstore, Android would pop up a dialog asking the user to "Choose an app for the USB device"
On my devices Subsurface is in the list of apps - along with DiveMate and an OBD2 app.

With v4.8.2 I built, and the 2.1.3(4.8.2.5) from the play store this pop dialog does not happen on the S4 (android 4.4.4).
But with 2.1.3(4.8.2.5) from the playstore on my S7 running Android 8.0.0 the dialog does happen.

I have also noticed that if you do not go through the Android USB/app dialog to start the app, the app cannot talk to the FTDI serial port.
i.e. if you cancel out of the dialog and start the app manually, or start the app before you plug in the data cable and cancel the dialog when the cable is plugged in
the app can't talk to the FTDI data cable.
So going through the dialog and letting it start the app seems to be important to grant access to the USB device.
This is true on both the S7 and the S4 with any/all versions of the app.

I'm beginning to think that this USB issue is related to the USB device dialog not starting up anymore on the S4 when the data cable is plugged in.

I am clueless about android and how it works but I did notice that it looked like there were some changes with respect to device intents
in the code between the v4.8.1 tag and the v4.8.2 tag - the addition of SubsurfaceMobileActivity.java
There was also a change to get rid of the decimal VID/PID values to get back to using hex in device_filter.xml

Is it possible that some of these updates have issues on Android 4.4.4 on the S4
which prevents the USB device app dialog from starting when the cable is plugged in?

--- bill