libdc, libzip, Mac and Android updates

[Dirk Hohndel]

I managed to break^Wfix a few things this weekend.

a) tiny change to libdivecomputer (Linus, this was so trivial that I simply pushed it to our branch... Jef, I /think/ you want this as well) to recognize the Aqualung i750TC as Bluetooth capable divecomputer. I don't know, yet, if it needs any additional code to actually work - I created an Android APK for the one user who appears to have this dive computer to try a download under Android

b) this brings me to the second thing I figured out: building a working APK against Qt 5.11.1. You may remember that I had problems with androiddeployqt not managing to package our APK because a dependency for one of the Qt plugins was unmet. After lots of googling I pieced together enough information to realize that the problem is in qt-android-cmake. I sent a PR to that project and in the meantime switched Subsurface to use my fork of this that actually tells androiddeployqt to scan the QML modules as well for dependencies. Thiago, I thought you might be interested in that part.

c) in the process I got angry at libzip and the consequences of the build fix for Mac that I did yesterday which in turn broke the Android builds on Travis. I think that's sorted and as a side effect we now can use the latest libzip again on Android (with some ugly hacks)

What's still not working is the iOS build and I'm not sure why...

/D

[Dirk Hohndel]

Post by Dirk Hohndel
What's still not working is the iOS build and I'm not sure why...

Fixed that one.

/D

[Thiago Macieira]

Post by Dirk Hohndel
b) this brings me to the second thing I figured out: building a working APK
against Qt 5.11.1. You may remember that I had problems with
androiddeployqt not managing to package our APK because a dependency for
one of the Qt plugins was unmet. After lots of googling I pieced together
enough information to realize that the problem is in qt-android-cmake. I
sent a PR to that project and in the meantime switched Subsurface to use my
fork of this that actually tells androiddeployqt to scan the QML modules as
well for dependencies. Thiago, I thought you might be interested in that
part.

Do you have a link?

[Dirk Hohndel]

Post by Thiago Macieira

Post by Dirk Hohndel
b) this brings me to the second thing I figured out: building a working APK
against Qt 5.11.1. You may remember that I had problems with
androiddeployqt not managing to package our APK because a dependency for
one of the Qt plugins was unmet. After lots of googling I pieced together
enough information to realize that the problem is in qt-android-cmake. I
sent a PR to that project and in the meantime switched Subsurface to use my
fork of this that actually tells androiddeployqt to scan the QML modules as
well for dependencies. Thiago, I thought you might be interested in that
part.

Do you have a link?

You mean to the PR to qt-android-cmake? Sure: https://github.com/LaurentGomila/qt-android-cmake/pull/22
Or you can just look at my fork https://github.com/dirkhh/qt-android-cmake/tree/QMLfix

Thanks

/D

[Dirk Hohndel]

And Laurent just merged my PR...

/D

Post by Dirk Hohndel

Post by Thiago Macieira

Post by Dirk Hohndel
b) this brings me to the second thing I figured out: building a

working APK

Post by Thiago Macieira

Post by Dirk Hohndel
against Qt 5.11.1. You may remember that I had problems with
androiddeployqt not managing to package our APK because a dependency

for

Post by Thiago Macieira

Post by Dirk Hohndel
one of the Qt plugins was unmet. After lots of googling I pieced

together

Post by Thiago Macieira

Post by Dirk Hohndel
enough information to realize that the problem is in

qt-android-cmake. I

Post by Thiago Macieira

Post by Dirk Hohndel
sent a PR to that project and in the meantime switched Subsurface to

use my

Post by Thiago Macieira

Post by Dirk Hohndel
fork of this that actually tells androiddeployqt to scan the QML

modules as

Post by Thiago Macieira

Post by Dirk Hohndel
well for dependencies. Thiago, I thought you might be interested in

that

Post by Thiago Macieira

Post by Dirk Hohndel
part.

Do you have a link?

https://github.com/LaurentGomila/qt-android-cmake/pull/22
Or you can just look at my fork
https://github.com/dirkhh/qt-android-cmake/tree/QMLfix
Thanks
/D
_______________________________________________
subsurface mailing list
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[Matt Thompson]

Post by Dirk Hohndel
a) tiny change to libdivecomputer (Linus, this was so trivial that I
simply pushed it to our branch... Jef, I /think/ you want this as well) to
recognize the Aqualung i750TC as Bluetooth capable divecomputer. I don't
know, yet, if it needs any additional code to actually work - I created an
Android APK for the one user who appears to have this dive computer to try
a download under Android
Woo hoo! How do I get my hands on that APK? I've been meaning to
download some recent dives anyway!

[Dirk Hohndel]

Post by Dirk Hohndel
a) tiny change to libdivecomputer (Linus, this was so trivial that I simply pushed it to our branch... Jef, I /think/ you want this as well) to recognize the Aqualung i750TC as Bluetooth capable divecomputer. I don't know, yet, if it needs any additional code to actually work - I created an Android APK for the one user who appears to have this dive computer to try a download under Android
Woo hoo! How do I get my hands on that APK? I've been meaning to download some recent dives anyway!

Install this APK from our website.

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.132-arm.apk <http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.132-arm.apk>


I'm also going to start making betas available again on Google Play, soon.

/D

[Matt Thompson]

Post by Dirk Hohndel
Install this APK from our website.
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.132-arm.apk
I'm also going to start making betas available again on Google Play, soon.
/D

I was able to test this but for some reason when I select AquaLung as the
vendor and i750tc as the model, subsurface shows a message that Bluetooth
is not enabled as shown in the screenshot. I am able to connect to the DC
using the vendor app so Bluetooth is working.

[Dirk Hohndel]

When you pair with the i750TC, what name does it use?
Can you run Subsurface-mobile with the dive computer already paired with the phone and send us the log? That will show us how Subsurface-mobile "sees" the dive computer...

Thanks

/D

Post by Dirk Hohndel
Install this APK from our website.
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.132-arm.apk <http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.132-arm.apk>
I'm also going to start making betas available again on Google Play, soon.
/D
I was able to test this but for some reason when I select AquaLung as the vendor and i750tc as the model, subsurface shows a message that Bluetooth is not enabled as shown in the screenshot. I am able to connect to the DC using the vendor app so Bluetooth is working.

[Jef Driesen]

Post by Dirk Hohndel
a) tiny change to libdivecomputer (Linus, this was so trivial that I
simply pushed it to our branch... Jef, I /think/ you want this as
well) to recognize the Aqualung i750TC as Bluetooth capable
divecomputer. I don't know, yet, if it needs any additional code to
actually work - I created an Android APK for the one user who appears
to have this dive computer to try a download under Android

I also don't know whether bluetooth (rfcomm) communication will work out
of the box or not. I know from Nick that the BLE communication requires
some small changes to protocol, and to make things even worse there are
several different BLE variants. So BLE support will certainly need some
more work first. But for rfcomm, I have no idea. I don't even know
whether the device support it.

So for the time being, I think I'll postpone applying this patch until
someone can conform it does indeed work. Otherwise it will create false
expectations for users.

Note that there are some more bluetooth capable models as well:

* Aeris A300CS
* Oceanic Pro Plus X
* Oceanic VTX
* Aqualung i300C (not supported yet)

Jef

[Dirk Hohndel]

Post by Dirk Hohndel
a) tiny change to libdivecomputer (Linus, this was so trivial that I
simply pushed it to our branch... Jef, I /think/ you want this as
well) to recognize the Aqualung i750TC as Bluetooth capable
divecomputer. I don't know, yet, if it needs any additional code to
actually work - I created an Android APK for the one user who appears
to have this dive computer to try a download under Android

I also don't know whether bluetooth (rfcomm) communication will work out of the box or not. I know from Nick that the BLE communication requires some small changes to protocol, and to make things even worse there are several different BLE variants. So BLE support will certainly need some more work first. But for rfcomm, I have no idea. I don't even know whether the device support it.
So for the time being, I think I'll postpone applying this patch until someone can conform it does indeed work. Otherwise it will create false expectations for users.

I think you are correct - this was based on data from one user and it seems that sadly the data were misleading. The device he tried to download from wasn't actually the rfcomm BT address of his i750TC, but instead his headset... :-(
So it seems this is indeed a BLE device which makes this much harder to do. I'll adjust the code in our branch accordingly, but until we figure out how to actually talk to it over that BLE link, that's not really useful.

* Aeris A300CS

We have one of those, but I think Linus gave up trying to get it to work.

* Oceanic Pro Plus X
* Oceanic VTX
* Aqualung i300C (not supported yet)

I've seen all three of those when looking around on the web. There are a few more from vendors I'm not familiar with.

/D