We have two different API endpoints. supportEmail() which adds the
default subject, recipient, and message body, and the generic
shareViaEmail() which takes all of these as arguments.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
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>
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>
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>
