jamulus icon indicating copy to clipboard operation
jamulus copied to clipboard

Android/LineageOS: Jamulus settings don't get saved on closing app

Open ann0see opened this issue 3 years ago • 15 comments

Describe the bug If you change settings in the Jamulus App and close it via the app switcher. On LineageOs it seems as if settings don't persist. Closing via File>Close does save the settings. Probably the .ini file doesn't get written if you close the app via app switcher.

To Reproduce

  • Install Jamulus 3.8.2rc1 on Android 9 (?)
  • Make changes to your profile
  • Close the app via App Switcher
  • Re-open Jamulus and see that the profile settings are reset

Expected behavior The profile settings are saved (i.e. the ini file gets written on closing the app).

Screenshots

Operating system Android/LineageOS 16.0

Version of Jamulus 3.8.2rc1

Additional context This bug seems to be found some time ago by @ngocdh https://github.com/jamulussoftware/jamulus/discussions/1382 Maybe not all versions of Android/LineageOS are affected. Therefore someone else with another device should verify.

ann0see avatar Feb 16 '22 20:02 ann0see

Moto G9 Power, Android 11 ("Stock" Motorola release). Freshly installed Jamulus 3.8.2rc1. Same behavour: change a setting (Fancy -> Compact), close the app normally, it's saved; change a setting (Compact -> Fancy), close the app with a swipe to clear, it's not saved.

At a guess, there will be some signal sent to the app, either a *nix SIGxxx or a Qt-level one, that we can catch and process, so I'd hope it's an easy fix if someone can find the appropriate Qt/Android tech docs.

pljones avatar Feb 16 '22 21:02 pljones

Further, my partner reports that simply switching off the screen can cause the app to "time out" and it closes without saving then.

pljones avatar May 21 '23 13:05 pljones

Looks like we need to catch changes to state: https://doc.qt.io/qt-5/qt.html#ApplicationState-enum https://doc.qt.io/qt-5/qguiapplication.html#applicationStateChanged

(Same in 6.5: https://doc.qt.io/qt-6/qguiapplication.html#applicationStateChanged)

Also this looks interesting - I guess we should honour the request: https://doc.qt.io/qt-5/qguiapplication.html#saveStateRequest https://doc.qt.io/qt-6/qguiapplication.html#saveStateRequest

pljones avatar May 23 '23 18:05 pljones

It's a nasty bug. I can only test on a VM as I don't have access to an up to date Android device at the moment.

ann0see avatar May 23 '23 20:05 ann0see

If there were a way of just running the Android build (and, ideally, limiting it to one architecture), I guess I could use github to produce the APK and then install that... Currently, Windows is refusing to build it and my Linux box has no access to an Android device. If I could build the APK at all, using Qt Creator, it would help...

pljones avatar May 25 '23 16:05 pljones

I mean you could probably install Qt with Android support and then set the respective configuration?

ann0see avatar May 25 '23 17:05 ann0see

Yes, that's what I did - following the Qt for Android guide. It gets as far as the deploy step and errors out with

Starting a Gradle Daemon, 1 incompatible and 1 stopped Daemons could not be reused, use --status for details
java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7

pljones avatar May 25 '23 18:05 pljones

Maybe the Java version isn't compatible (related to your issue here: https://github.com/jamulussoftware/jamulus/issues/2767)

Funny what pops up on searching for that (I believe that's quite low effort: https://www.youtube.com/watch?v=izHfFiEK9Jw) I'd rather look at: https://stackoverflow.com/questions/61289461/java-lang-noclassdeffounderror-could-not-initialize-class-org-codehaus-groovy-v directly

ann0see avatar May 25 '23 20:05 ann0see

https://docs.gradle.org/current/userguide/compatibility.html
https://gradle.org/releases/
gradle compatibility
https://groovy.apache.org/download.html#requirements groovy compatibilty
(which doesn't have any mention of what version of JDK have been tested against)

Now to find out where the tooling is setting the gradle version... hmmm...

pljones avatar May 26 '23 19:05 pljones

I'd assume it's in .github/autobuild/android.sh ?

ann0see avatar May 28 '23 14:05 ann0see

I don't see specific mention of gradle and it's a linux-based build, too, whereas I'm trying to work on Windows. (It's also using Java 8 and I'm trying to use Java 17... My Windows box has 8, 11 and 17 on but my linux box only 17, currently.)

pljones avatar May 30 '23 17:05 pljones

2023-05-28T14:55:32.7595676Z Unzipping /home/runner/.gradle/wrapper/dists/gradle-5.6.4-bin/bxirm19lnfz6nurbatndyydux/gradle-5.6.4-bin.zip to /home/runner/.gradle/wrapper/dists/gradle-5.6.4-bin/bxirm19lnfz6nurbatndyydux

From https://github.com/jamulussoftware/jamulus/actions/runs/5104913232/jobs/9176149075 lets me believe that it's gradle 5.6.4

ann0see avatar May 30 '23 19:05 ann0see

https://github.com/jamulussoftware/jamulus/actions/runs/5104913232/jobs/9176149075#step:10:1502 indeed.

Unzipping /home/runner/.gradle/wrapper/dists/gradle-5.6.4-bin/bxirm19lnfz6nurbatndyydux/gradle-5.6.4-bin.zip to /home/runner/.gradle/wrapper/dists/gradle-5.6.4-bin/bxirm19lnfz6nurbatndyydux Set executable permissions for: /home/runner/.gradle/wrapper/dists/gradle-5.6.4-bin/bxirm19lnfz6nurbatndyydux/gradle-5.6.4/bin/gradle

I guess I need that as a dependency to build, then. I'd have expected Qt Creator to get it right, though.

pljones avatar May 31 '23 12:05 pljones

I'm keen to get this one closed for 3.11.0.

pljones avatar Aug 12 '23 10:08 pljones

Yes! Please note that I can only test in a VM as I don't have access to a (modern) Android device.

ann0see avatar Aug 12 '23 20:08 ann0see