Android's sandbox makes us jump through hoops in order to share files
with other apps. We need to declare a file provider and use specific
paths where the files are located.
Then we have java code (I couldn't make it work as JNI) that takes the
filenames and creates content:// URIs for them and then hands those off
to a sharing activity that is provided by Android.
This can then be used to create attachments for support emails, or to
share the log files with other apps - both of which will solve the
annoying maximum log file length that we have with using the binder to
add the log file text to the message body.
This also finally replaces the 'compile' directive in build.gradle with
'implementation' - removing a warning that we've had for ages.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Builds were failing because gradle tried to download libraries from
bintray. JCenter is shutting down in a few weeks.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
As of November 20201 the Google Play store now requires that new apps
target API level 30. The minimum API level remains 21 so we should
continue to support devices all the way back to Android 5.0 (Lollipop).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Builds started to fail because v2.2.2 (about 18 months old) couldn't be
found anymore. That issue seems to have been fixed, but it was a good
reminder not to get completely disconnected from upstream here.
This switches things to the currently latest version of the Android USB
library (which coincidentally will also provide support for additional
USB-serial chipset - not that I think that any dive computers will
benefit from that).
Some of the interfaces changed in the upstream Java library and our code
had to be adjusted to accomodate this.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In trying to avoid the wrath of the Google Play police I ended up giving
up too many permissions. And while in my test installs things continued
to work, in new installs on Android 10 or newer the lack of
FINE_LOCATION permission resulted in BLE scans no longer working.
The frustrating thing is that apparently installing an update with a
different set of permissions isn't enough to trigger either the bug or
the fix (at least not reliably). What appears to work is to uninstall
the existing app and then do a fresh install of a new app with the
correct permissions.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On Android devices that no longer get updates to the system installed
SSL root certificates, the user can easily install the updated Let's
Encrypt root certificate, but that is only used by Subsurface-mobile if
we explicitly allow the use of those user installed root certificates.
Fixes#3335
Suggested-by: Greg Hunter
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
That seems to be the way to force it to not request FINE_LOCATION or GPS access.
If I leave this on 'auto' then the dependency on QtPositioning (for showing the
map) appears enough for it to claim access to GPS location. I no longer want
to deal with the Google Play police for that.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With the switch to the bundle build (introduced at Qt 5.14) a couple of the
settings in the manifest had to change.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user tries to download from a device that he hasn't given the app
permission to read from, Android will pop up a dialogue asking for that
permission. With this after giving the permission we continue (well,
technically, restart) the download which is likely the expected behavior.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user hadn't granted USB permissions, yet, we asynchronously get informed
once they did that. This ensures that the user gets taken back to the download
page once they approve.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of creating a string with all the object information, simply pass
the actual object to the C++ code.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When a user is downloading from a DC for the first time (without using
the "usb device connected" popup), the user is requested to grant
permission to use the USB device.
This is done asynchronously, thus the download is aborted. To be more
user-friendly, we now react to the intent with the "usb granted" result.
The plan here is to start the download again.
Signed-off-by: Christof Arnosti <charno@charno.ch>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Android takes some pretty hard measures to save power, including
shutting down the CPU. Since this can interfer with the download from an
usb serial device, we now use a wakelock to keep the CPU running during
download.
Signed-off-by: Christof Arnosti <charno@charno.ch>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This commit contains the serial_android_usb part of the changes proposed
in issue #2657.
What's implemented:
- A data structure that contains all the data that can be used to
describe an usb device (including user-facing string).
- A function to get a list of all attached usb devices (optionally with
selectable driver class).
- Changes in the serial_android_usb_open-function and in the Java part
to use the information about the usb device and optionally selected
driver when connecting.
This commit keeps compatibility with the current UI-Code in the case
that only one USB-Device is connected. If two devices are connected,
only the first one is tried.
There are still some small things to do:
- Change the user-facing string to something more descriptive.
- Parts which aren't uesd anymore when the UI-Part is implemented are
simply marked as obsolete (to keep compatibility for now).
But generally it seems to work.
[Dirk Hohndel: some white space / coding style adjustments]
Signed-off-by: Christof Arnosti <charno@charno.ch>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The HID devices and the Atomics Aquatics Cobalt cannot work on Android
right now. We should claim to support them.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since the Android USB stack and subsequently the usb-serial-for-android
driver have problems with read-timeouts, the read-timeout is now
implemented in AndroidSerial.java. Also, DC_STATUS_TIMEOUT is returned
if there are less bytes returned than expected.
Different chipsets seem to behave differently with
usb-serial-for-android. On CP210x the read blocks until there is some
data here, but on FTDI the chip seems to return whatever is currently in
the buffer (so 0 bytes if the buffer is empty). This different behaviour
should be mitigated by the changes by this commit.
Signed-off-by: Christof Arnosti <charno@charno.ch>
Implement the libdivecomputer API in Java and create C/JNI translation
layer.
[Dirk Hohndel: whitespace harmonization - yes, some of this is Java,
this still makes it much easier to read for me;
also changed the FTDI conditional compilation to make
sure we can still use that for mobile-on-desktop if
necessary]
Signed-off-by: Christof Arnosti <charno@charno.ch>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is working around a Qt Bug https://bugreports.qt.io/browse/QTBUG-69494
which prevents correct rendering of the OnePlus fonts.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Using more recent versions of the Android NDK results in a build failure
saying something like "No toolchains found in the NDK toolchains folder
for ABI with prefix: mips64el-linux-android". Mips support went away
after Android NDK, Revision r17c, and we are using r18b at this moment.
Too old Gradle stuff gets confused by this.
The solution is simple. Use a newer version of the Gradle plugin.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
I'm not sure this is actually relevant for anything any more, but this
adds the USB device ID's for the Scubapro G2 Console and HUD versions.
It also fixes things to use the proper vendor name (a bit too much
cut-and-paste, where the code said "Suunto" instead of "Scubapro").
The real device ID changes are in libdivecomputer, this is just the
Android xml list for recognized USB devices that likely nobody really
uses.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Hard coding desired ANDROID_PLATFORM on multiple places is simply bad.
Fix this. Further, set the variables to a much newer state.
CAVEAT: this will likely break android build, so be careful on
bisecting. All fixed in next, related commits.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
At this point in time there seems something wrong with jcenter that
is used to download all Android build artifacts from. It simply does
not find the needed stuff on there and our build fails. Its unclear
if this is a temporary issue at jcenter, or its just an intended change.
This fix is a bit of a hack. It provides our own gradle build spec
instead of the one that is provided from Qt (which is pulled in using
androiddeployqt). Added is a working download link to maven, and a
newer com.android.tools.build:gradle is used compared to Qt.
All this makes Travis happy again.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The old code happened to work because this function only got called if
the app was already running, but the correct thing to do is to always
wait until we have first called back from C++ code, indicating that the
app is indeed fully initialized.
This way we only process the Intent in one place in the Java code.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We want to be able to respond to a USB device being plugged in.
This simply logs the information we get from the device. Sadly the
really useful getProductName and getManufacturerName require API level
21 (so Android 5.0 or newer) and we still have a couple hundred users on
4.1-4.4.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This doesn't affect the minimum we support, but a target level of at
least 26 will be required starting in August in order to be able to
upload to the Google app store. This is equivalent to targeting Android
8.0. Google plans to bump this target API level every year.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way plugging in a Cobalt should pop up a question if the
user wants to open Subsurface-mobile.
Unfortunately, this, too, fails on my Android devices, so I can't test
it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This very simple commit has a long story. See the mailing list
subject "mobile: android splash screen (and issue 513) opacity
weirdness".
There is even more. I found the following deccription on Internet:
https://falsinsoft.blogspot.nl/2017/07/qml-show-android-native-splash-screen.html
and tried to implement this with the potentially nice Qt functionality
(since 5.8) to manually get rid of the splash screen. Unfortunately,
this does not work. Notice that there are subtile differences in
the here found internet page, and the method originally implemented
in commit 04e994b575.
This fix is as mimimalistic as it can be. Just do not set black but
white for the initial background. Unfortunately, there is still
a small position change of the icon. It is known why, but solving
is left as an exercise to the reader.
Fixes: #513
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This way plugging in an EON Steel should pop up a question if the
user wants to open Subsurface-mobile. Unfortunately, the download
doesn't work, yet, and worse, if the phone goes to sleep while an
EON Steel is plugged in, this appears to trigger a hard crash on
the EON Steel.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
First, Ministro (an app to help installing Qt dependencies on
the mobile platform) is not needed in Subsurface context, as all
dependencies are part of the distribution. Secondly, it breaks the
build as the strings (removed here) are also defined in Qt, and
apparently the Gradle build is detecting this double define.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This reworks build.sh for proper argument parsing and variable quoting.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is based on post by Ben Laud
https://medium.com/@benlaud/complete-guide-to-make-a-splash-screen-for-your-qml-android-application-567ca3bc70af
It creates a theme that uses a splash drawable that Android will show
immediately when the application is launched. And then starts the QML
application with visibility set to false adn only makes it visible (and replace
the splash screen) once initialization is finished.
We still get a little flicker with the switch from splash to start page to dive
list, but over all the experience is hugely improved. And the bug that the
splash screen stays around when starting Subsurface-mobile in landscape also
appears to be fixed.
Fixes#994
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We call the app Subsurface-mobile most of the time, let's do so for the app
name too
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
../android-mobile/res/drawable-xhdpi/subsurface_mobile_splash.9.png
../android-mobile/res/drawable-xxhdpi/subsurface_mobile_splash.9.png
../android-mobile/res/drawable-xxxhdpi/subsurface_mobile_splash.9.png
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
