| apol |
There are probably still many features that aren't properly mapped to
Android, but at least the basics work:
This is also the first time we have Java code for Android in a KF5
framework, I tried to follow what Qt does for this.
| No Linters Available |
| No Unit Test Coverage |
| Buildable 6443 | |
| Build 6461: arc lint + arc unit |
By using AndroidX (formerly known as the support library) we could enable it for Android version older than 23 (which is about 29% of all active devices). That would require adding the appropriate jar to the build.
This looks really cool! I'd say let's get this in and we can iterate from here if needed.
Maybe it would be useful to have builds of a test application?
This makes sense. The tricky part seems to be the CMake integration of a dependency only available via Maven. Doable it seems, but not straightforward. The changes needed on the Java side seem fairly minimal.
That would be much appreciated, juggling a stack of big interdependent patches with arc is not fun...
Maybe it would be useful to have builds of a test application?
Yes. I have been testing with KDE Itinerary, but that isn't really elegant. Adding a dedicated test application here would add extra dependencies though.
These changes only will apply to Android, so let's get this in. The status quo is broken there anyway.
As for the application, it could be in a separate repository too, no need to bloat the repository. For Kirigami we had to split it already because it was a bad idea.
Please note that all apps uploaded to the Play Store need to have a target API level >= 26 (Oreo). This means (among other things) that notifications need to have a channel (see https://developer.android.com/training/notify-user/channels). The current code will fail as soon as the app developer has a target API >= 26 specified. See https://developer.android.com/training/notify-user/channels for details. I would know how to do the required Java changes (I have done it for KDE Connect D9514) but I'm not sure if/how it's possible to do it without the support library/androidx and adding it to the build seems above my knowledge.
Yep, I'm working on getting the support libs... I managed to get downloading of maven-based dependencies to work, but turns out all the Android support libs are AARs rather than JARs (which we can consume directly). Extracting the JAR from the AAR and linking against that builds, but that doesn't look like the right approach at all. I'd therefore like to explore building the entire Java side with Gradle (similar to what androiddeployqt does). This would solve the dependency problem for free and bring us much closer to how "normal" Android stuff is built, which should be much more sustainable.