cgeo 🚀 - App not working (Freeze) on device with Sailfish OS

I can confirm this issue on SailfishOS with AlienDalvik (AOSP 8.1).

This freeze happens with and without microG installed. Haven't tried it with google play services yet, but previous releases worked fine without it.

System information:

--- System information ---
Device: Xperia XA2 (AOSP) (aosp_h3113, Sony)
Android version: 8.1.0
Android build: OC test-keys
c:geo version: 2020.08.04
Google Play services: enabled - 0.2.11.202414
Low power mode: inactive
Compass capabilities: yes
Rotation vector sensor: absent
Orientation sensor: absent
Magnetometer & Accelerometer sensor: present
Direction sensor used: magnetometer & accelerometer
Hide caches: -
Hide waypoints: -
HW acceleration: enabled (default state)
System language: cs_CZ
System date format: dd.MM.yy
Debug mode active: no
System internal c:geo dir: /data/user/0/cgeo.geocaching (818,6 MB free) internal
User storage c:geo dir: /data/user/0/cgeo.geocaching (818,6 MB free) internal
Geocache data: /storage/emulated/0/Android/data/cgeo.geocaching/files/GeocacheData (818,6 MB free) external non-removable
Database: /data/user/0/cgeo.geocaching/databases/data (4,0 KB) on system internal storage
Fine location permission: DENIED
Write external storage permission: DENIED
Geocaching sites enabled: None
Installed c:geo plugins:  none
--- End of system information ---

I can get debug log before proceeding to geocaching service selection.

--------- beginning of main
08-15 02:14:18.649  2558  2558 W cgeo    : [main] Could not make directories /storage/emulated/0/cgeo
08-15 02:14:18.649  2558  2558 W cgeo    : [main] External public cgeo directory '/storage/emulated/0/cgeo' not available
08-15 02:14:18.716  2558  2583 W cgeo    : [RxCachedThreadScheduler-1] 'null' is NOT available as external dir
08-15 02:14:18.718  2558  2583 W cgeo    : [RxCachedThreadScheduler-1] Chosen extCgeoDir null is not an available external dir, falling back to default extCgeoDir
08-15 02:14:18.726  2558  2558 W cgeo    : [main] 'null' is NOT available as external dir
08-15 02:14:18.728  2558  2558 W cgeo    : [main] Chosen extCgeoDir null is not an available external dir, falling back to default extCgeoDir

As SailfishOS user I'm not familiar with troubleshooting of android apps, but I will gladly provide additional info, if needed.

mmtj on 20 Aug 2020

To c:geo team: Is it possible to provide a special nightly build with debug log activated by default?

eddiemuc on 20 Aug 2020

Wouldn't it be possible to submit a PR (not to be merged) with a change to enable debug log by default. The cgeo-debug.apk generated by our CI for this PR could be used for testing then.

Lineflyer on 20 Aug 2020

@Lineflyer I created such a PR (#8852), but I do not know how to continue from there...

eddiemuc on 20 Aug 2020

If you open the checks, which have run for this PR and follow the link "details" to get to our CI server, you will find cgeo-debug.apk as artifact of this build. This should be an installable and runnable developer version using the codebase of your PR.
So @mmtj could install it and try to see if it outputs more log data.

Lineflyer on 20 Aug 2020

Hi @mmtj I built a version of c:geo with debug logging enabled by default (and you can't turn it off with this version too). You can find the apk in our CI server here: https://ci.cgeo.org/job/cgeo%20pull%20request/3420/
Direct download link: https://ci.cgeo.org/job/cgeo%20pull%20request/3420/artifact/main/build/outputs/apk/basic/debug/cgeo-debug.apk

Would it be possible for you to install this apk, reproduce the freeze problem and send the created log?

eddiemuc on 20 Aug 2020

I'm experiencing the same issue. I have a Sony Xperia XA2 running SailfishOS 3.4.0.24 (Pallas-Yllästunturi).

There is a thread about the same problem on the Sailfish OS Forum with some more information. Summarizing the key points from there:

the bug only affects Sailfish X devices running the newer AlienDalvik Android emulation layer based on AOSP 8.1 (e.g. Xperia XA2 and Xperia 10 families)
the c:geo app used to work in Sailfish OS 3.2 (Torronsuo), but stopped working with the upgrade to version 3.3 (Rokua) and upgrading to the current 3.4 early adopter version (Pallas-Yllästunturi) does not help either
there are two separate problems, or both could be related: the freeze issue (cannot set up geocaching accounts or other services) and a startup problem; the startup problem can be worked around by clearing the application data through Settings and restarting the Android emulation layer.

Here are my own observations:

The freeze isn't actually a total freeze, as the Android back button (bottom center of screen) can still be used to back out of the frozen screen. Typical sequence of events:

I open the c:geo app for the first time (after installing it, or clearing app data and restarting Android support to make sure the app isn't running in the background)
I see the "About c:geo - Getting Started" screen; I can scroll up and down or flick the tabs at the bottom - everything seems to be working
I press the "Configure your geocaching platform(s)" button and get to the Services screen
In the Services screen, I can scroll up and down, toggle the "Android browser" checkbox etc, everything seems to work
Now if I tap on any of the geocaching platforms (Geocaching.com, opencache.uk ...) or any of the "further services" (GCvote.com ...) or Twitter, the background of that item will flicker briefly in a lighter shade - indicating that I selected it - and return to normal. Immediately the UI freezes, still showing the same pixels as before but I cannot scroll or select anything.
If I now click the Android back button at the very bottom, I can get back to step 4, i.e. the UI unfreezes and I can again scroll up/down etc. but as soon as I select anything else than "Android browser" it will freeze again.
I can also tap the Android back button a second time to get to the "Getting started" screen. So I can navigate between the top two levels, but not down to the third level (individual services).
If I tap the back button when on the "Getting started" screen, the UI also freezes. I don't know how to unfreeze in that situation.

Based on my observations, I think this could be a UI level bug. For some reason, the screen that would allow me to configure any of the services/providers never appears; it could be invisible, or obscured by the Services screen. The experience reminds me of some Windows apps that confusingly open a modal window that gets hidden somewhere and then the main window freezes until I discover the modal window.

Is there something special about how the Services screen opens the next level (service specific) screens? Could it be triggering some edge case in recent versions the AlienDalvik emulation?

I'd like to try out the PR #8852 version where the debug log is forced on, but I can't find the APK - there are no Artifacts listed in the Jenkins UI, and the direct link above is not working. Was it perhaps already deleted from the Jenkins CI server? I could of course open another PR with identical code to trigger a new build, but it seems rather stupid to pollute the c:geo GitHub repo with another "do not merge this" PR.

Disclaimer: I'm not really an Android developer, though I've created a small demo app with Android Studio in the past.

osma on 11 Oct 2020

@osma we have implemented a option to configure logging via file, you have to place the file named log-properties.txt into you local cgeo/logfiles directory. Than it should generate the needed logfile...

Download link:
https://github.com/cgeo/cgeo/files/5213102/log-properties.txt

fm-sys on 11 Oct 2020

Thanks @fm-sys, I will try it out!

osma on 11 Oct 2020

This was posted in the Sailfish OS thread, maby it helps:

The app has a “Generate logfile” button and I was able to get a few lines there:

[main] External public cgeo directory ‘/storage/emulated/0/cgeo’ not available
[RxCachedThreadScheduler-1] ‘null’ is NOT available as external dir
[RxCachedThreadScheduler-1] Chosen extCgeoDir null is not an available external dir, falling back to default extCgeoDir
[main] ‘null’ is NOT available as external dir
[main] Chosen extCgeoDir null is not an available external dir, falling back to default extCgeoDir
[looper callbacks] Unable to create network location provider: provider doesn’t exist: network

fm-sys on 12 Oct 2020

Could it perhaps be, that the new Android layer has partly implemented the newer permission system, but not the capabilities for requesting them? c:geo needs storage and location access in order to work...

rsudev on 12 Oct 2020

I think I made a bit of progress debugging the issue.

First, I upgraded to c:geo 2020.10.10 and used the log-properties.txt method to increase logging verbosity. It wasn't immediately obvious where to put this file, but eventually I discovered that the correct location from the perspective of the host Sailfish OS is the (quite well hidden!) /home/.android/data/data/cgeo.geocaching/logfiles directory. Within the Android container, this path shows up as /data/user/0/cgeo.geocaching/logfiles/log-properties.txt.

I then did the normal clear-cgeo-app-data-and-restart-android-support routine to ensure the app starts up. I recorded two log files, one from the host system by using the lxc-attach -n aliendalvik -- /system/bin/logcat command recommended in Jolla support docs and another one from within the cgeo app, by pressing the "Generate logfile" button (after trying to configure the Geocaching.com service and backing out with the back button). I'm attaching both files to this comment.

In the system logfile I'm seeing lines like this:

10-12 15:48:43.954    74   324 D VoldConnector: SND -> {8 volume mkdirs /storage/emulated/0/Android/data/cgeo.geocaching/files/}
10-12 15:48:43.958    74   144 D VoldConnector: RCV <- {200 8 Command succeeded}
10-12 15:48:43.966    74   324 D VoldConnector: SND -> {9 volume mkdirs /storage/sailfishos_storage/Android/data/cgeo.geocaching/files/}
10-12 15:48:43.967     5    12 E cutils  : Failed to mkdirat(/storage/sailfishos_storage/Android): Read-only file system
10-12 15:48:43.968    74   144 D VoldConnector: RCV <- {400 9 Command failed}
10-12 15:48:43.969   746   746 W ContextImpl: Failed to ensure /storage/sailfishos_storage/Android/data/cgeo.geocaching/files: 400

and in the c:geo generated logfile the same last line:

10-12 15:48:43.969   746   746 W ContextImpl: Failed to ensure /storage/sailfishos_storage/Android/data/cgeo.geocaching/files: 400

So this looks like c:geo has trouble accessing the file system. By searching the web for these error messages, I discovered one more discussion thread about Android apps - including c:geo - having trouble accessing the SD card since the Sailfish OS 3.3 Rokua update, on the old together.jolla.com (TJC) forum.

In my understanding c:geo doesn't actually require the SD card storage, so maybe it just gets confused when it sees that some storage is available but then can't access it read-write due to limitations of Alien Dalvik? Though I don't even have an SD card currently inserted.

I've now started up the c:geo app numerous times from a clean slate, trying to get the logging working etc. Strangely enough, I was able to get to the Geocaching.com service configuration screen once, while I was also using system logcat to collect logs, and was able to set up my user account! But it happened just once, the app still wouldn't start afterwards, and I couldn't repeat it despite taking exactly the same steps!
system-logcat4.log
logcat_2020-10-12_15-50.txt

osma on 12 Oct 2020

FWIW these items from the Sailfish OS 3.3 Rokua release notes could be relevant:

Many Android apps can access the SD card, now. For instance, OsmAnd and HERE WeGo map apps can save the offline map tiles to the card. Likewise, Spotify can save music to the card. Apps like WhatsApp can attach pictures from the SD card to messages now. The card name (the nickname given when formating the card) must not contain spaces.

Nemo storage mounted as an AlienVolume(PublicVolume) and named 'sailfishos_storage'; unneeded bindfs dependency removed

I entered a root shell inside the Android container using the command lxc-attach -n aliendalvik /system/bin/sh. From there I could go to the directory /storage/sailfishos_storage, which shows the home directory of the default nemo user, i.e. the contents of /home/nemo on the host system. But I cannot create any files in there - I get a Read-only file system error just like c:geo did. There is no directory /storage/sailfishos_storage/Android that c:geo was trying to access.

That's all I can do for now. It looks like c:geo is trying to create directories in a path it can't write to. Not sure if this is the root cause of the freeze problem, or a separate non-critical issue.

Note that I've given the c:geo app permission to access location and storage. I believe the "Read only file system" message is an indication of a lower level failure - it's not specific to the app, as even a root shell within the Android container cannot write under /storage/sailfishos_storage.

osma on 12 Oct 2020

My few cents:

/Android/data/cgeo.geocaching/files/ is not the SD card but the default internal app storage as defined by Android. Below Android/data/ apps are free to store data in a directory with their package name.
This should be pretty much standard, therefore I can't understand why it is not possible.

Lineflyer on 12 Oct 2020

The so called 'externalStorageDir' (/storage/emulated/0/Android/data/cgeo.geocaching) is something, which is expected to be available and writable as far as I can tell on every Android version we currently support. We do not deduce that ourselves but rely on the Android Api to provide it (which seemingly fails, ContextImpl is an Android internal class AFAIK).
Not sure if there is much we can do about that.

rsudev on 12 Oct 2020

(@Lineflyer The 'real' internal storage is in this context /data/user/0/cgeo.geocaching)

rsudev on 12 Oct 2020

@rsudev
You are right, I forgot this historical and confusing naming of internal/external.

This briefly describes the storage (but needs update as the migration described is done meanwhile): https://github.com/cgeo/cgeo/wiki/Disk-usage-structure

Lineflyer on 12 Oct 2020

Looking at https://github.com/cgeo/cgeo/wiki/Disk-usage-structure#additional-data-for-caches : If this external storage is not available we should already fallback to the system internal storage.

@pstorch Correct?

Lineflyer on 12 Oct 2020

Yes, we should. But to me it seems, that the Android layer fails to provide this information correctly, due to being unable to create the app specific external data directory when we ask for its existence.

rsudev on 12 Oct 2020

It wasn't immediately obvious where to put this file, but eventually I discovered that the correct location from the perspective of the host Sailfish OS is the (quite well hidden!) /home/.android/data/data/cgeo.geocaching/logfiles directory. Within the Android container, this path shows up as /data/user/0/cgeo.geocaching/logfiles/log-properties.txt.

Normally c:geo uses the path /emulated/0/cgeo/ for storing data like logfiles or backups. So it's probably true that the dir is not writable and it falls back to the private data directory.

Just a random thought: Can someone test, if c:geo also freezes on Android 11. Maybe Sailfish OS is implementing the same SAF like Google is doing (and maybe left out the legacyStorageFlag additionally)...

fm-sys on 12 Oct 2020

The docs state, that Sailfish OS is implementing Android 8.1, if I figured that correctly. OTOH has the storage access framework been introduced already much earlier than Android 11 (it is e.g. available on my 7.1.1 device)

rsudev on 12 Oct 2020

Thanks for all your comments. It's truly amazing to see so much activity around this issue. I mean, you could have just said "Sailfish is not a real Android system, go away." But instead you try to be helpful and find out what's wrong. I very much appreciate that attitude!

I'm not entirely convinced that the "Read-only file system" error is the root cause of the freezing and startup problems described in this issue. Here is the system information from my c:geo app (sorry for not posting it earlier but others have posted very similar ones above):

--- System information --- 
Device: Xperia XA2 Dual (AOSP) (aosp_h4113, Sony)
Android version: 8.1.0
Android build: OC  test-keys
c:geo version: 2020.10.10
Google Play services: enabled - 0.2.12.203315
Low power mode: inactive
Compass capabilities: yes 
Rotation vector sensor: absent
Orientation sensor: absent 
Magnetometer & Accelerometer sensor: present
Direction sensor used: magnetometer & accelerometer
Hide caches: - 
Hide waypoints: - 
HW acceleration: enabled (default state)
System language: fi_FI 
System date format: d.M.y
Debug mode active: no 
System internal c:geo dir: /data/user/0/cgeo.geocaching (3,3 GB free) internal
User storage c:geo dir: /data/user/0/cgeo.geocaching (3,3 GB free) internal 
Geocache data: /storage/emulated/0/Android/data/cgeo.geocaching/files/GeocacheData (3,3 GB free) external non-removable
Database: /data/user/0/cgeo.geocaching/databases/data (4,0 KB) on system internal storage
GPX import path: /data/user/0/cgeo.geocaching/gpx 
GPX export path: /data/user/0/cgeo.geocaching/gpx
Offline maps path: null
Map render theme path: 
Live map mode: true
Global filter: display all caches
Fine location permission: DENIED
Write external storage permission: DENIED
Geocaching sites enabled: None 
Installed c:geo plugins: none
BRouter connection available: false 
--- End of system information ---

I think the selected paths are sensible - the problematic one /storage/sailfishos_storage does not appear there. So despite c:geo having problems creating directories in there according to the log file, it ends up selecting directories that can be accessed. When I start the app, it creates the directories cache, code_cache, databases, files and shared_prefs under /data/user/0/cgeo.geocaching and also the directory /storage/emulated/0/Android/data/cgeo.geocaching/files/GeocacheData is created. So maybe c:geo can access all the paths it really needs? Also note that many other Android apps are running just fine on Sailfish OS (e.g. I use Firefox, Slack, Skype and Zoom, and the official Geocaching app), so I doubt there is anything seriously wrong with the data directories Alien Dalvik provides for apps.

Is there anything else I can do to help debug the issue? I notice the issue is still tagged with "Feedback required" and "Unverified" labels, can these be dropped now that many users have reported the same issue, either here or on the Sailfish OS forum?

osma on 13 Oct 2020

Your sysinfo points clears to this:

Fine location permission: DENIED
Write external storage permission: DENIED

This happens (and thus the fallback to internal dirs) as c:geo freezes before being able to ask for permissions. Can you add the app permissions manually on Sailfish OS?

Lineflyer on 13 Oct 2020

Your sysinfo points clears to this:

Ah, sorry @Lineflyer ! I had granted those permissions manually before but apparently they got lost at some point. I did the normal clear-data-restart-Android cycle and granted the Location & Storage permissions manually (from Settings -> Apps -> c:geo -> Android settings). Now the system info looks like this:

--- System information ---
Device: Xperia XA2 Dual (AOSP) (aosp_h4113, Sony)
Android version: 8.1.0
Android build: OC test-keys
c:geo version: 2020.10.10
Google Play services: enabled - 0.2.12.203315
Low power mode: inactive
Compass capabilities: yes
Rotation vector sensor: absent
Orientation sensor: absent
Magnetometer & Accelerometer sensor: present
Direction sensor used: magnetometer & accelerometer
Hide caches: -
Hide waypoints: -
HW acceleration: enabled (default state)
System language: fi_FI
System date format: d.M.y
Debug mode active: no
System internal c:geo dir: /data/user/0/cgeo.geocaching (3,3 GB free) internal
User storage c:geo dir: /storage/emulated/0/cgeo (3,3 GB free) external non-removable
Geocache data: /storage/emulated/0/Android/data/cgeo.geocaching/files/GeocacheData (3,3 GB free) external non-removable
Database: /data/user/0/cgeo.geocaching/databases/data (4,0 KB) on system internal storage
GPX import path: /storage/emulated/0/cgeo/gpx
GPX export path: /storage/emulated/0/cgeo/gpx
Offline maps path: null
Map render theme path:
Live map mode: true
Global filter: display all caches
Fine location permission: granted
Write external storage permission: granted
Geocaching sites enabled: None
Installed c:geo plugins: none
BRouter connection available: false
--- End of system information ---

You can see that the permissions are now shown as granted. The "User storage c:geo dir" changed to /storage/emulated/0/cgeo and the GPX import/export paths changed similarly as well.

I still get the freeze when trying to open e.g. Geocaching.com specific settings. So granting the permissions manually doesn't fix the actual issue and the app is still unusable.

osma on 13 Oct 2020

I've been trying to look for more clues. I even installed Android Studio and compiled my own version of c:geo, with some additional logging inserted. I'm still unsure whether the freezing problem is related to file access problems or not. It seems to me that it may be a hiccup that is unrelated to the freezing problem and in fact harmless, since c:geo ends up using sensible paths, at least if you grant it permissions manually before starting it for the first time.

Looking at the log files generated using logcat, I noticed quite a few lines like this:

10-12 15:48:10.253    74    86 I SurfaceFlinger: ALIEN: discarding frame without app/window (system process).
10-12 15:48:10.273    74    86 I SurfaceFlinger: ALIEN: discarding frame without app/window (system process).

They seem to correlate with the freezing that happens when I try to configure a service. I wonder if these indicate some UI level issue - that the app is unable to display the specific screen for configuring a service such as Geocaching.com?

If you have any ideas, I'm happy to try them out. I now have a working testbench where I can modify the c:geo code in Android Studio, build an APK, transfer it to my Sailfish phone and run it there, watching the logcat output.

osma on 14 Oct 2020

What is special about the service settings is, that the UI is derived from the Preferences framework, not sure whether this might be the source of the failure. If you skip activating a service - does the 'normal' ui work? Can you download and use offline maps, perhaps import caches as gpx and view them in lists and on the map?
Or are other parts of the app (besides the preferences) affected?

rsudev on 14 Oct 2020

@rsudev I don't know how to skip activating a service. When I start up c:geo for the "first" time (not really, but after clearing app data), it will only show the button for configuring services, as well as some tabs for changelog, system information etc. I can't get to the main UI.

osma on 14 Oct 2020

On a real Android device you have a back arrow in the title bar. With that you can leave the 'getting started' screen without configuring anything.

rsudev on 14 Oct 2020

@rsudev Ah, right, thanks. I tried pressing the back arrow - ~~it freezes the app~~ :( The effect is the same as pressing the Android back button at the bottom of the screen, as was already mentioned earlier in a comment.

But thanks anyway for the suggestion, this is another problem to investigate. And I hope it's a bit simpler than the settings activity, which is quite complex as it does so many things.

Edit: Sorry, I was too hasty. The app freezes for a moment when I tap the back button in the title bar, but after maybe 20 seconds or so, I get to the main screen. The live map is working. I didn't test other functionality yet. But if I open the settings from the hamburger menu at the top, I can't get to any of the sub-screens (e.g. services or storage paths), the UI will freeze again if I try. So it seems that the settings/preferences activity is misbehaving once more.

osma on 14 Oct 2020

You are right, you mentioned it in your very detailed description at the top.
I have to digest that again and ponder on it a bit to think of possible points to look at (what could be a common cause for freezing when returning to the main screen or entering the service configuration).
I'll come back to you tomorrow.
BTW: Is there a way to check/run sailfish os on some kind of emulated device?

rsudev on 14 Oct 2020

@rsudev Please see my edited comment above, I was able to get to the main screen after all.

Regarding emulated Sailfish: there is a free SDK available with an emulator, but I don't think it includes the Alien Dalvik Android emulation layer. I haven't used the SDK myself though.

osma on 14 Oct 2020

I'd like to thank everyone working on this issue, I'm also one of those Sailfish users and have been missing out on c:geo for a few months now. The issues of course started for me with a Sailfish OS upgrade, but it would be interesting to know if these same issues would become relevant also in the Android 11 context.

ExTechOp on 15 Oct 2020

As the Android layer in sailfish os is on version 8.1 (according to the release notes and the system info from above) I would not expect a direct relation to any issues we (might) encounter with Android 11.

rsudev on 15 Oct 2020

While preparing to have a look at the emulator and trying to get into the overall architecture (to find a mental reference frame for possible obstacles), I would like to ask if it would be possible to get a full logcat of the process of switching from the welcome screen to the main screen (this should definitively not take 20 seconds), perhaps this gives clues as to where an issue might come from.

rsudev on 15 Oct 2020

👍1

@rsudev I did the following, while collecting logcat output (attached). I tried to wait a bit between operations and time them to the clock to make it possible to match actions to log entries, though I may have been off by a second or two - more likely I was a bit late than too early.

logcat-20201015.txt

Cleared c:geo app data
Turned off Android support (this destroys the Alien Dalvik container AFAIK)
~18:14:00 started Android support (this takes maybe 20 seconds)
Opened the Android permissions for c:geo and granted it rights for Storage and Location
~18:15:00 started c:geo (opens the welcome screen)
~18:15:30 tapped the back arrow in the title bar
~18:16:05 the main window opens after a freeze of ~35 seconds
~18:16:30 tapped the hamburger menu to open Settings
~18:16:40 tapped the first settings category (Services) -> UI frozen
~18:16:50 tapped the Android back button to unfreeze the UI
~18:17:00 tapped the second settings category (Display) -> UI frozen
~18:17:10 tapped the Android back button to unfreeze the UI
Tapped the back button a couple more times to close the app

This was done using my custom c:geo development build, based on the current master branch code. No API keys were defined. I have inserted a few extra log messages into some methods but they should not affect what the code is doing.

osma on 15 Oct 2020

Thanks for the speedy response. Unfortunately the log is inconclusive. There is some interference from LeakCanary, a supporting component that should report memory leaks. Perhaps a good idea to remove it and try again (esp. the delay going back to the main screen in step 6. could come from that)

diff --git a/main/build.gradle b/main/build.gradle
index d20478e07..fe272852b 100644
--- a/main/build.gradle
+++ b/main/build.gradle
@@ -283,9 +283,9 @@ dependencies {
     testImplementation 'junit:junit:4.13'

      // Leak Canary, memory leak detection
-    def leakCanaryVersion = '2.5'
-    debugImplementation "com.squareup.leakcanary:leakcanary-android:$leakCanaryVersion"
-    implementation "com.squareup.leakcanary:plumber-android:$leakCanaryVersion"
+    //def leakCanaryVersion = '2.5'
+    //debugImplementation "com.squareup.leakcanary:leakcanary-android:$leakCanaryVersion"
+    //implementation "com.squareup.leakcanary:plumber-android:$leakCanaryVersion"

      // Locus Maps integration
     //noinspection GradleDependency

As you reported earlier, the app also freezes if it is restarted after a first run without again cleaning the data. I would be interested to see the log of such an attempt as well (preferably with a c:geo version without LeakCanary)

rsudev on 15 Oct 2020

@rsudev OK, I will try. I uninstalled my custom build (which included LeakCanary) and installed vanilla c:geo 2020.10.10 instead.

I made another discovery that could be crucial! By waiting long enough, I noticed that the freezes in the Settings activity are not permanent. When defining services for the first time, I selected Geocaching.com, the UI froze, but I left the app running. (I watched top on the phone, c:geo was not using significant amounts of CPU here). After 3-4 minutes the screen for Geocaching.com opened! It was still extremely sluggish to activate the service, but then I was eventually able to open the screen for entering username/password. That screen worked quickly and I was able to log in to Geocaching.com, then back out using the back button a few times. The transition from the welcome screen towards the main screen was again extremely slow, it took more than a minute. Before actually opening the main screen the app asked for permissions to access Storage and I think it was also asking for Location, but something went wrong there, I got a black screen and had to close the app. I will try again, capturing the log as well and working systematically. But it seems now that the app might still be borderline usable, as long as you are prepared to wait for minutes to access and change the settings.

Note that this was with the vanilla c:geo, no LeakCanary installed. So the sluggishness is not due to LeakCanary.

osma on 15 Oct 2020

Here are two log files. I was using c:geo 2020.10.10 and I granted Storage and Location permissions before starting it.

Here is what the first logfile shows.
logcat-vanilla.txt

20:22:30 start app
20:23:00 open services
20:23:10 select Geocaching.com
(freeze for 20 seconds)
20:23:30 Geocaching.com opens
20:23:40 tap Activate
(freeze for around 8 minutes!)
20:31:?? geocaching.com username & password dialog opens and I enter my information and log in
20:31:25 tapped back button from welcome screen
(freeze for around 45 seconds)
20:32:09 main screen opens, it shows I am logged in to geocaching.com
opened live map (shows I'm in Paris since there is no GPS fix)
moved around the map
...eventually closed the app

So I was able to use the app, but I had to wait approximately 8(!) minutes before being able to enter the Geocaching.com credentials. After I got to the main screen, things seemed to work smoothly though. So I might have been able to use the app normally at this point, though without a GPS fix it's a bit difficult to test.

The delays seem to be pretty random. Sometimes you have to wait 20 seconds, sometimes several minutes. I haven't noticed any regularity yet.

Some time later I tried to start the app again 3 times, without clearing the data in between. Every time it tried to start for about 20 seconds, then closed, never showing any screen except for the spinner that indicates that the app is starting up.
logcat-vanilla-restart.txt

20:52:00 try to start app again
20:52:20 app closes on its own
20:53:00 try to start app again
20:53:18 app closes
20:54:00 try to start app again
20:54:18 app closes

Since it's not possible to restart the app after closing it once, I wouldn't say this app is usable on Sailfish, but the problems are a bit different than initially thought.

osma on 15 Oct 2020

Would any other Sailfish users like to experiment - now that we've found out that it is actually possible to configure the app, it's just extremely slow? @mmtj @ExTechOp - you indicated that you are using Sailfish, want to give it a shot?

To get started, install the newest c:geo version, clear the app data (Settings -> Apps -> c:geo), restart Android support, then (optional but recommended) go to Settings -> Apps -> c:geo -> Android settings and grant permissions. Start up c:geo and try to set up your geocaching services - be patient, you will eventually get past the frozen UI situations if you wait long enough - and see if you can then use the app normally.

osma on 15 Oct 2020

Thank you for providing the logs. Unfortunately are there no indications as far as I can see that can indicate where the frozen app states emerge from.
Even when restarting the app, no indication that any code of the app got activated (MainActivity.onResume should be called immediately)
An additional test could be, to try to start the already configured app after a restart of the Android support container.

rsudev on 15 Oct 2020

👍1

Here is a log I captured after restarting Android support, but without clearing app data.
logcat-vanilla-android-restart.txt

22:47:30 tried to start app
22:47:48 app closes
22:48:00 tried to start app
22:48:18 app closes
22:48:30 tried to start app
22:48:48 app closes

The first time I tried starting it, there is some activity shown in the log and exception tracebacks related to coordinates and geocoding. For the two subsequent runs, there is very little information in the log, as before.

osma on 15 Oct 2020

Hi all, thanks for all the effort taken so far.
I'm using a Sony Xperia XA2 in German with Sailfish OS 3.4 and c:geo 2020.07.02.

I can confirm what @osma says: c:geo reacts really slow to user inputs. Some tests (I always have to clear cache and data before tests):
At one test I could go back to the main screen of the app.
At another test I managed to login to geocaching.com with the app.
These tests took minutes...

I have one interesting observation: When going to the Jolla main screen and back to c:geo, the screen goes black. This can be observed from the c:geo main screen but not from the c:geo setup screen.

It seems to me that c:geo cannot redraw the screen correctly or does it behind the black screen.

rolfa on 16 Oct 2020

Thank you @rolfa for confirming my findings about the extremely slow reactions to some actions.

I have also noticed the black screen. It seems to be a more general problem with Sailfish OS 3.4, as other Android apps such as Firefox also sometimes show a black screen, especially in app covers. But c:geo gets stuck with the black screen, while other apps quickly redraw themselves when you open them to the foreground.

osma on 16 Oct 2020

I made yet another discovery! Whenever the UI freezes, you can bypass it by dragging from the side edge of the screen - as if you were going to put the app in the background - but then abort the gesture by dragging back to the edge, returning c:geo to the foreground. It's a bit annoying to have to do this all the time especially when configuring, but this way you can set up services in almost no time!

I'm guessing once more that the freeze problem is strictly UI related, nothing to do with storage access, location services etc. For some reason the app UI isn't redrawing normally but tends to get stuck. Is c:geo using some non-standard or rare method of controlling UI redraws?

Although with the above trick the app can be used for the first time, I still haven't figured out how to restart the app. Once you've closed it, there is no way to open it again, except by clearing app data and restarting Android support, which will lose your settings.

Since the logcat logs haven't been very useful, I've tried to gather more clues by watching the journal log on the Sailfish OS side (journalctl -ab -f will follow all log messages). That hasn't been very helpful either though. I can't find anything relevant in the journal.

osma on 16 Oct 2020

I found a buggy onRestart method override and proposed a fix in PR #9199. Unfortunately fixing it does not affect the freeze issue on Sailfish OS.

osma on 16 Oct 2020

Tested disabling hardware acceleration, but it didn't help.

osma on 16 Oct 2020

I don't think c:geo does any special or overly sophisticated on the UI level - rather being 'behind the curve' and using older widgets and themes (which could also be a problem).
I looked once more into the release notes for Sailfish OS. AlienDalvik was updated from 8.1.0_r65 to 8.1.0_r73, so no major version change. OTOH was the packaging restructured, not sure whether any detrimental side-effect could come from there.

rsudev on 17 Oct 2020

👍1

I spent some time looking at the Java code especially for the misbehaving activities - MainActivity (along with its superclasses) and SettingsActivity - but couldn't find anything suspicious there (apart from the PR I did). My next hypothesis is that this could be related to either the app manifest or styles and themes.

Last night I tried to tweak a few settings in the styles.xml file but I couldn't figure out how to make an APK with those changes - no matter what I did, it seemed to me that my edits were being ignored. Is there maybe a trick I'm missing? I tried cleaning the project, clearing the caches, restarting Android Studio etc. but I always ended up with an APK of the exact same size and functionality.

For now I've tried the approach of tweaking various things and testing if that helps - but if that doesn't work out, I may have to switch to a more systematic approach. One way to do that would be to cut out various parts of the c:geo app (e.g. activities, themes, styles...) until the freeze no longer appears. Another way would be to start with a minimal app and then keep adding parts of the c:geo codebase until the problem surfaces. But both of these approaches can be a bit tedious...

osma on 17 Oct 2020

A little bit of progress...

I can now generate APKs with my changes to the manifest, styles and themes. I don't know what the problem was yesterday. Maybe I was misled because APKs often tend to be the same size, even if you change the files.

If I remove this theme statement from the MainActivity definition in the AndroidManifest.xml file:

            android:theme="@style/cgeo_main"

then the transition from the initial screen to the main screen becomes fast. It is also possible to reopen the app after closing it!
Of course, this affects the layout of the main screen - in particular the background is missing.

I've tried tweaking the manifest, styles and themes to avoid the freezes in the settings screen, but so far had no luck.

osma on 17 Oct 2020

That is indeed a big step forward! I suspected increasingly issues from that side, as the theme/style topic is one of the most 'legacy' we have (IMO). Several attempts to address this from ground up in the past failed due to the complexity of defining a style that works sufficiently well across a wide span of Android versions and device configurations.

rsudev on 17 Oct 2020

For the preferences you could try to remove the android:theme attribute from the SettingsActivity definition in the manifest.

rsudev on 17 Oct 2020

I've tried removing that, but it didn't help. I also tried removibg all other theme attributes from the manifest, but if I remove the one from application the app becomes unusable. I then tried removing individual style and theme definitions. It's possible that I missed something, but it seemed to me that the settings freeze cannot be solved that way.

osma on 17 Oct 2020

Interesting. Perhaps I can prepare a suggestion on what possibly to try tomorrow. In some places the style/theme is also selected programmatically, to support dark/light style switching (or to work around glitches between Android versions)

rsudev on 17 Oct 2020

Thanks! Now that I have some clues about the main screen / restart problem I think I'll try to narrow it down further and put aside the settings problem for now.

osma on 17 Oct 2020

I reinstated the android:theme attribute (so the manifest is now unchanged) and instead started tweaking themes.xml.

One or more of these settings seems to be relevant:

        <item name="android:windowBackground">@android:color/transparent</item>
        <item name="android:colorBackgroundCacheHint">@null</item>
        <item name="android:windowShowWallpaper">true</item>

If I remove either android:windowBackground or android:windowShowWallpaper, then the main screen transition and restarts start to work. (~~The app also now says it is in debug mode and asks if I want to deactivate that - I wonder why that happens?~~ Edit: Nevermind, that was my own code change I had forgotten about - I had forced debug mode on.)

In both cases the background picture of the main screen will be lost; if I drop windowBackground the background is dark gray, if I drop windowShowWallpaper instead it is black.

Maybe there is something strange going on with the background picture?

osma on 17 Oct 2020

I've done a little bit of further testing and experimentation. After removing windowShowWallpaper from themes.xml, the app seems to be basically usable on Sailfish OS, except that it's annoying to configure the settings when you have to do the put-to-background-no-wait-leave-it-in-the-foreground gesture all the time to fix the freezes. But you generally only have to do that once.

Regarding the settings freezes: I tested many things, but nothing I could think of seemed to fix it. My current suspicion is that the method for changing preference screens - especially the two methods both called redrawScreen in the SettingsActivity class - could be causing the problem and perhaps the transition from one PreferenceScreen to another should be done in some slightly different way.

I've tried to study how the Preference framework should be used, but it's a bit difficult since the current code is at least two generations behind state of the art (no fragments, and not using AndroidX Preferences) so the official documentation is not very helpful.

osma on 18 Oct 2020

I am (stil) in the process of preparing a 'stripped down' version of the themes, but the settings are a tricky nut to crack.
BTW, the documentation regarding preferences was not that helpful either, when it was describing our current implementation.
I'll take you comment into account and see whether I can find something for the preferences to tweak.

rsudev on 18 Oct 2020

(current state which crashes in settings at https://github.com/rsudev/c-geo-opensource/tree/theme_tryout)

rsudev on 18 Oct 2020

I'm getting more and more convinced that the settings freeze is not caused by static aspects such as themes, styles or manifest attributes (unlike the main screen freeze which is related to the background). I've already tried many ways of tweaking these, for example stripping down the themes, but haven't had any positive result.

Instead I think that the settings freezes are caused by the transition between hierarchy levels in the settings. For example, when you click on the "Configure services" button, the Services preference screen works fine, until you select a particular service such as Geocaching.com. But if you instead go to the Settings from the main screen (behind the three dots menu), the top level setting categories work well but if you go down one level to Services, the UI will freeze. So it appears that it's the transition that triggers the freeze - the Services screen works fine when you get to it directly via the welcome screen button, but not when you enter it from the top level settings.

I did a little experiment, changing this line (222) in AboutActivity from:

        services.setOnClickListener(v -> SettingsActivity.openForScreen(R.string.preference_screen_services, AboutActivity.this));

to

        services.setOnClickListener(v -> SettingsActivity.openForScreen(R.string.preference_screen_gc, AboutActivity.this));

so that the button on the welcome screen will take the user directly to the Geocaching.com preferences, one level deeper than usual. Confirming my suspicion, now the Geocaching.com configuration screen works fine. There is no transition between levels, so no freeze!

I will try to narrow it down further but as I indicated above, the redrawScreen methods are my prime suspect currently.

osma on 19 Oct 2020

It's not the redrawScreen methods though. Disabled them but the freezing persists.

osma on 19 Oct 2020

I tried removing nearly all the methods from SettingsActivity, leaving only the bare minimum needed to open the activity (onCreate etc.). The freeze still persists. So it looks like my suspicions were a bit off. I'm still convinced that the transition between hierarchy levels is important, as it seems to consistently trigger the freeze, but it's probably not caused by the Java code in the SettingsActivity class.

osma on 19 Oct 2020

I have prepared an updated version of my experiments, which is mainly fiddling with the themes. The main settings-related change is, to use a different base theme. And as these also influence the transitions (through animation effects) it might be worthwhile to check it out.
On the other research direction i was able to get the Sailfish OS sdk up and running, but didn't find a way to install/activate AlienDalvik...

rsudev on 19 Oct 2020

Wow, thanks @rsudev ! Is that on the theme_tryout branch you linked to above?

Regarding Sailfish emulation: thanks for trying that out - unfortunately I don't think it's possible to install Alien Dalvik in that environment. It's a proprietary component, the versions of it are device specific (I doubt the emulator even tries to accurately emulate a device such as Xperia XA2), and you normally have to pay a license fee (40 EUR or so) to install it on a Sailfish device.

osma on 19 Oct 2020

I found the recently updated code on the theme_tryout branch, built it and tested it on my XA2. The main screen works fine, it has a dark gray backround - not a surprise since you had removed the android:theme attribute from MainActivity. But the Settings screens still freeze when you go from one level to another. So unfortunately, no real progress on identifying the settings issue.

osma on 19 Oct 2020

Thanks for the tryout - I will try to tinker a bit with the preferences implementation, perhaps there is a way to make it work again with SFOS and at the same time be more aligned with the current Android APIs.

rsudev on 19 Oct 2020

Quick test using the above information on c:geo version 2020.10.20-NB-e10a942 (clear all app data from both Sailfish and Android side, pre-approve location/storage Android permissions, use trick of almost switching away from app to quickly get past UI freeze) produces running c:geo that seems to work until you switch away from it (seemingly redraw is an issue, you just get a black screen) or close it and then attempt to restart it (after that it's the "sits around for a moment and then closes" routine). I suspect there may be multiple issues at play here.

ExTechOp on 20 Oct 2020

Thanks for testing @ExTechOp ! Your results are in line with mine. There are indeed at least two issues:

The main screen (MainActivity) freezes when you navigate to it and the app cannot be restarted. Both of these problems can be fixed by removing the transparent background from the theming. Maybe not an ideal solution because we lose the nice background effect, but at least the app becomes usable.
The configuration screens freeze when you navigate from one hierarchy level to another. A workaround is to use the "almost switch away from app" trick that you used. No better fix or workaround has been identified yet.

osma on 20 Oct 2020

can be fixed by removing the transparent background from the theming. Maybe not an ideal solution because we lose the nice background effect, but at least the app becomes usable.

Can the unpatched c:geo version be started if you disable the transparent background at settings > appearance (or something like that, I don't know the English strings)?

fm-sys on 20 Oct 2020

Can the unpatched c:geo version be started if you disable the transparent background at settings > appearance (or something like that, I don't know the English strings)?

I think I tried it and it didn't help, but I need to double-check.

osma on 20 Oct 2020

@fm-sys I installed unpatched c:geo 2020.10.10. Opened the app. Struggled myself to the main screen and the appearance settings (this requires several "almost switch away" gestures). Disabled the transparent background setting. Closed the app. Reopening the app doesn't work. So no, just disabling the transparent background setting won't make the main screen / restart problem go away, the fix has to be done in themes.xml (or removing the theme setting from MainActivity in the manifest).

osma on 20 Oct 2020

Not sure if it is relevant, but I was able to crash debug build of cgeo (2020.08.20).

System info

--- System information ---
Device: Xperia XA2 (AOSP) (aosp_h3113, Sony)
Android version: 8.1.0
Android build: OC test-keys
c:geo version: 2020.08.20-2e12f78 developer build
Google Play services: unavailable
Low power mode: inactive
Compass capabilities: yes
Rotation vector sensor: absent
Orientation sensor: absent
Magnetometer & Accelerometer sensor: present
Direction sensor used: magnetometer & accelerometer
Hide caches: -
Hide waypoints: -
HW acceleration: enabled (default state)
System language: cs_CZ
System date format: dd.MM.yy
Debug mode active: yes
System internal c:geo dir: /data/user/0/cgeo.geocaching (1001,4 MB free) internal
User storage c:geo dir: /data/user/0/cgeo.geocaching (1001,4 MB free) internal
Geocache data: /storage/emulated/0/Android/data/cgeo.geocaching/files/GeocacheData (1001,4 MB free) external non-removable
Database: /data/user/0/cgeo.geocaching/databases/data (4,0 KB) on system internal storage
Fine location permission: DENIED
Write external storage permission: DENIED
Geocaching sites enabled: None
Installed c:geo plugins:  none
--- End of system information ---

Crash log from LeakCanary

┬───
│ GC Root: Input or output parameters in native code
│
├─ android.os.MessageQueue instance
│    Leaking: NO (MessageQueue#mQuitting is false)
│    ↓ MessageQueue.mMessages
│                   ~~~~~~~~~
├─ android.os.Message instance
│    Leaking: UNKNOWN
│    ↓ Message.next
│              ~~~~
├─ android.os.Message instance
│    Leaking: UNKNOWN
│    ↓ Message.callback
│              ~~~~~~~~
├─ cgeo.geocaching.-$$Lambda$DZZgYxdNmVBhmbrpR6PFv4jQOx8 instance
│    Leaking: UNKNOWN
│    ↓ -$$Lambda$DZZgYxdNmVBhmbrpR6PFv4jQOx8.f$0
│                                            ~~~
╰→ cgeo.geocaching.MainActivity instance
     Leaking: YES (ObjectWatcher was watching this because cgeo.geocaching.MainActivity received Activity#onDestroy() callback and Activity#mDestroyed is true)
     key = f64c8bc1-2e36-416c-b1ee-52eec05e40e8
     watchDurationMillis = 5231
     retainedDurationMillis = 229

METADATA

Build.VERSION.SDK_INT: 27
Build.MANUFACTURER: Sony
LeakCanary version: 2.4
App process name: cgeo.geocaching
Analysis duration: 15478 ms

mmtj on 23 Oct 2020

@osma: I created a very hacky test implementation converting our preferences to androidx and fragments (which should be the current standard). It will mostly 'not work', but the navigation should be mainly there (at https://github.com/rsudev/c-geo-opensource/tree/pref_tester)
Could you give it a try? If it would solve the issues with Sailfish OS I would try to get that done for real.

rsudev on 23 Oct 2020

Thanks a lot @rsudev ! I will try it out later today.

osma on 23 Oct 2020

@rsudev I tested your pref_tester branch. It built OK and I was able to install it. On the initial screen, the "Configure services" button took me to the main screen (asking for permissions first) instead of the service settings. It was a bit glitchy (app goes into background when asking for permissions) but this has happened before with other variants as well, happens with some other apps as well, and is not too bad. The main screen worked fine, with a grey background, same as with the version where I disabled the transparent background by editing the theme.

From the main screen, I could go to the settings via the menu on the top right. The navigation between settings screens worked perfectly! The layout seemed a bit off (lots of padding on the left side) but it's probably the same for you as well. I didn't try editing the settings very much but what I tried seemed to be working. No freezes.

I think this was a very promising experiment - thanks a lot! I hope you can work further on this! I can try to help where I can, although I have no real experience building Android apps so I guess it will be mostly about testing and perhaps small scale experimentation such as editing themes.

osma on 23 Oct 2020

Thanks a lot for the quick experiment!
Right now, it is really just a hack, where much is broken and I just implemented enough to get the settings navigation working based on fragments (I did not even look at fixing the layout or anything like that, and many settings likely don't work or make the app crash).
I will will try to get that in shape as soon as possible for real, as it even helps c:geo on 'normal' Android to use the 'current' frameworks and technologies.
If I may throw intermediate versions into your direction for testing (and verifying that it still works on SFOS) that would be very helpful.

rsudev on 23 Oct 2020

Sounds like an excellent plan, and I'm glad this helps other Android users as well! Happy to test intermediate versions.

osma on 23 Oct 2020

Any progress here? Btw. if cgeo is up and running again with Sailfish OS, I'll donate for the project for sure!

rolfa on 2 Nov 2020

Maybe @rsudev can comment on the progress of reimplementing the settings screens? This is the main remaining obstacle currently and the most difficult to fix.

For my part, I could put together a semi-working APK of c:geo for Sailfish users where the main screen problem has been fixed (by removing the transparent background in theme configuration) and the app can be restarted normally. The settings screens will still freeze but this can be bypassed using the put-to-background-then-abort gesture. Would this be helpful to you @rolfa? One way of doing this would be to make a PR, which then gets auto-built into an APK by the Jenkins CI infrastructure of the project - but the PR probably shouldn't be merged as it disables the transparent background feature for everyone. Or I could just attach my self-built APK to a comment on this issue if that's helpful.

osma on 2 Nov 2020

After the initial success with the navigational part of the settings, the real issues with the more advanced items (authentication etc...) started to crop up and I have not yet been able to get it into a state that would be worth looking onto (need to read up on fragments and settings interaction compared to the 'old style').
If you mark a PR as WIP/DO NOT MERGE you can safely use the infrastructure to provide an apk with disabled transparency.
Regarding that, I have an idea how to solve it with different styling and a setting.
To make this really helpful there should be a way to detect the SFOS environment in a somewhat reliable fashion.

rsudev on 2 Nov 2020

Thanks @rsudev , it sounds like you are making some progress with the new configuration despite the problems.

I created (draft) PR #9342 which removes the transparent background effect from the main screen. I tested building it on Android Studio and it works as expected on my XA2 - i.e. the settings freeze is still there but the main screen works. However, I can't see any activity on the Jenkins CI. Do I need to do something special to make the CI build it into an APK?

osma on 2 Nov 2020

@bekuno just triggered our CI to build your PR.

Lineflyer on 2 Nov 2020

👍1

@osma I'd be interested to try out that APK.

rolfa on 3 Nov 2020

@rolfa You can find the APK here: https://ci.cgeo.org/job/cgeo%20pull%20request/3948/
(didn't try the CI built APK yet myself but I trust that it's similar to my own)

osma on 3 Nov 2020

@rsudev

Regarding that, I have an idea how to solve it with different styling and a setting.
To make this really helpful there should be a way to detect the SFOS environment in a somewhat reliable fashion.

So the idea is to detect that the app is running under SFOS and dynamically disable the transparent background effect? Or vice versa - if we're not under SFOS, make the background transparent.

One possible way to detect SFOS is to look at the device and/or Android version information that is also visible in the system information tab, e.g. for my device:

--- System information --- 
Device: Xperia XA2 Dual (AOSP) (aosp_h4113, Sony)
Android version: 8.1.0

This doesn't directly say it's Sailfish, but at least it says AOSP which I believe is uncommon in non-Sailfish devices. I assume there can be different devices affected by this (various Xperia XA2 and Xperia 10 models) but detecting both "AOSP" in the Device string and Android version 8.1.0 should be pretty accurate I think. (Older Sailfish devices such as Jolla 1 and Jolla C have older Android 4.x based emulation layers, but in my understanding they are not affected by this bug.)

osma on 3 Nov 2020

We already have a setting for the transparent background, but that is disabling the background transparency programmatically (and seemingly too late).
My idea is to include this flag already in the theme selection (so if it is not set, a theme without transparency is selected) and to change the default setting for this flag (which is normally true) to false on SFOS.
By that, you can anytime change it (to test e.g. after updates of SFOS or the Android environment) while hopefully having a good onboarding experience.
I'll take the suggested bits of the system information.

rsudev on 3 Nov 2020

We already have a setting for the transparent background, but that is disabling the background transparency programmatically (and seemingly too late).
My idea is to include this flag already in the theme selection (so if it is not set, a theme without transparency is selected) and to change the default setting for this flag (which is normally true) to false on SFOS.

We could change the theme for mainscreen to not include transparency by default, and add transparency in MainActivity if both of the following conditions are met:

not running under Sailfish OS
the config flag "opaque background" is not set

(effecively reversing the "opaque/transparent" program logic we currently have)

moving-bits on 3 Nov 2020

Could also be worth a try (if transparency then works across the supported range of Android devices...)

rsudev on 3 Nov 2020

@osma there are two apks. Which one is it?

cgeo-basic-debug-androidTest.apk or cgeo-debug.apk

rolfa on 3 Nov 2020

@rolfa TBH I don't know the difference, but I just installed cgeo-debug.apk from that CI page and it works as expected on my SFOS XA2.

osma on 3 Nov 2020

cgeo-debug.apk is the right one to use. The other one contains only test cases to verify that all c:geo functions are working as it should (so only made for development purposes)

fm-sys on 3 Nov 2020

I made a short test: it's working well, thanks!
I understand that there is some debugging action going on but that was expected from a debug version.
Also I suspect the app is not closing fully, because after I reopen it, the registration with the server is there immediately.

rolfa on 3 Nov 2020

@rolfa I think it's normal that when you "close" an app it will actually stay in the background.

With the APK from CI, I was able to configure my geocaching.com account using the put-to-background-then-abort gesture to bypass the freezes. Then I went geocaching and it worked fine, I was able to find a cache using the app and also log it as found.

osma on 4 Nov 2020

The app works fine so far, thanks again.
A version without LeakCanary would be nice :)

rolfa on 13 Nov 2020

@osma While still struggling with the move to Androidx preferences (they conceptually removed support for the kind of multi-level hierarchies we have, so it is a bit more work to get this up-and-running again. sad but unavoidable) I prepared a test version which implements the transparency switch through theme selection (I also dropped leak canary from that version, to make it a bit smoother)
Could you give that version a try (CAVE: it is based on current master, so if you have important data in c:geo, please back it up)?

rsudev on 25 Nov 2020

Thanks @rsudev , I will try it out soon and report back!

osma on 26 Nov 2020

@rsudev I installed the cgeo-debug.apk from https://ci.cgeo.org/job/cgeo%20pull%20request/4066/ on my XA2 and did some brief testing. Unfortunately it wasn't very encouraging.

On the plus side, the app now starts up reliably every time. When you open it it shows the c:geo splash screen (big yellow square with the c:geo logo) for a few seconds, which I believe is new. I think the splash screen may be what makes the startup work, as previously opening the app (when it had been already configured before) brought up the main screen, which had the transparent background problem.

The transparent background defaulted to on, which I believe wasn't the intent for Sailfish OS (see my comment on the PR, I think there's a typo in the test). I was able to turn it off manually and after restart the main screen had an almost black background. But regardless of the setting, the UI freezes in many places - possibly even more than it used to though I'm unsure. For example, you can't get from the main screen to the settings (via the three dots menu) without triggering the freeze. As before, the freezes can be bypassed with a special gesture.

Looking at the code you used to switch between normal and transparent background - perhaps you could do it the other way around i.e. call setTheme(R.style.cgeo_main.transparent); if and only if the transparent background setting is enabled?

osma on 26 Nov 2020

Thank you for the quick test and feedback.
Yes, the splash screen is a recent addition (and quite a bunch of other changes).
I will implement your suggestion in the branch and see if it helps or if there are other things that need to be looked at now (there were some activity regarding styling, unfortunately I do not have the time to follow the development closely nowadays).

rsudev on 26 Nov 2020

Update pushed. While I did follow your suggestion, the main culprit likely was calling setTheme too late. This only became apparent in my tests when doing the 'non-transparent-first' version.

rsudev on 26 Nov 2020

@rsudev Tested the new build. The transparent background was still on by default, so even though you fixed the aosp typo the check seems not to work correctly.

But after I changed the setting to disable the transparent background, the main screen started behaving well without any freezes! So the new theme selection mechanism is working.

osma on 26 Nov 2020

The value for SDK_INT to compare with was just a guess. So I prepared a new version (building right now) and put that into the system information (together with the check result). Could you once more check it out, so I can finalize at least this part? Than the latest version would again be usable with your workaround while I continue the modernisation of the settings.

rsudev on 27 Nov 2020

I can test, but it seems that the build failed: https://ci.cgeo.org/job/cgeo%20pull%20request/4072/
I don't have access to Android Studio right now so can't try to fix it myself.

osma on 28 Nov 2020

Hi @osma Unfortunately did it take quite some time for me to untangle this, but now there is a new version to test available: https://ci.cgeo.org/job/cgeo%20pull%20request/4111/artifact/main/build/outputs/apk/basic/debug/cgeo-debug.apk
There I extended the system info to include the SDK_INT value I test for.
Could you check it out and post here what your system reports?
Thanks in advance!

rsudev on 3 Dec 2020

Here is the relevant section from the system information:

Device: Xperia XA2 Dual (AOSP) (aosp_h4113, Sony)
Android version: 8.1.0, 27
I am a Sailfish: true

The transparent background setting still defaults to on.

osma on 4 Dec 2020

The transparent background setting still defaults to on.

@osma Could it be that only the checkbox in the settings is not updated, but the non-transparent layout is used internally anyway? That would be my first guess looking at the PR....

fm-sys on 4 Dec 2020

@fm-sys

Could it be that only the checkbox in the settings is not updated, but the non-transparent layout is used internally anyway? That would be my first guess looking at the PR....

No, the transparent background is actually there, causing UI freezes. If I go to settings, disable it, and restart the app, then the background is not transparent any more.

osma on 4 Dec 2020

Thanks for the test!
I will check were in the chain this fails. As I now know that the test as such works, I can tailor it to the emulator and see where it fails to provide the intended information.

rsudev on 4 Dec 2020

A question @osma: Did you clear all data for c:geo prior to your test? Did the app take you first to the 'Welcome' screen when starting? If not, the settings from a previous start attempt would remain and block the usage of the default.
With cleaned settings and an adapted detection the app did not present a transparent background in the main activity (but the setting is not correctly initialized as observed by @fm-sys )

rsudev on 4 Dec 2020

@rsudev I deleted the previous version of the app, then installed the test version. In my experience, this has the effect of clearing all app settings, but I didn't specifically clear the settings. After installing the new test version, I had to go through the Welcome screen and configure my geocaching.com account again.

I just tested clearing the app data (from Settings -> Apps -> c:geo). There's something fishy with the transparent background setting. Here is an example:

Opened the app and got the Welcome screen
Pressed the back button to get to the main screen (without setting up accounts)
Accept the permissions (storage & location)
The main screen background is almost black, no transparent background
Opened settings and checked the transparent background setting: it's enabled!
Closed the app
Opened the app again - now the main screen background is transparent

Another attempt, after clearing the app data once more:

Opened the app and got to the Welcome screen
Configured my geocaching.com account
Pressed back button 3 times to get to the main screen
Accepted permissions
Got to the main screen - background is transparent!

One possible explanation for these two sequences of events would be that the transparent background indeed now defaults to off, but if I ever visit any of the settings screens (for example to set up my geocaching.com account), it gets turned on by itself. So if I ever want to check the setting I always see that it's on - a real Heisenbug if you ask me :)

osma on 4 Dec 2020

Thanks for the extensive test. In fact does visiting the settings screen override the default I have programmatically put in place with a static default from the preferences screen definition. I already have a fix for that in the pipeline, will be available in a few minutes.

rsudev on 4 Dec 2020

@osma A new version is ready at https://ci.cgeo.org/job/cgeo%20pull%20request/4115/artifact/main/build/outputs/apk/basic/debug/cgeo-debug.apk if you wouldn't mind another test (whenever it fits in).

rsudev on 4 Dec 2020

Tested again. Now the transparent background setting defaults to off and stays that way! Great work @rsudev !

osma on 4 Dec 2020

That is very nice to hear and good that it now works. I will finalize that as a proper change against master in the next days, so that you can use the nightlies and soon the next release again with your special trick while I pursue the modernization of our preferences implementation.

rsudev on 4 Dec 2020

Cgeo: App not working (Freeze) on device with Sailfish OS

826588

All 112 comments

Related issues