Android app crashing while using gps cant restart

Bug Reports
#1

REPRODUCIBILITY: to be done
OS VERSION: 4.4.0.64
HARDWARE: xa2
UI LANGUAGE: ger
REGRESSION: ?

DESCRIPTION:

I used osmand together with podqast, which maybe caused an oom and crashed osmand.
At this time osmand tried to get a gps lock (blinking icon in the top bar) and while this icon was there it couldnt be restarted

PRECONDITIONS:

osmand installed, gps active, quite full memory
STEPS TO REPRODUCE:

  1. open osmand try to get a gps lock
  2. crash the app (with out of memory)
  3. check if gps icon is still blinking in the top bar
  4. restart osmand

EXPECTED RESULT:

The app can restart

ACTUAL RESULT:

app can only restart after the blinking gps icon disappeared

MODIFICATIONS:

tons of storeman and chum stuff, no patchmanager

ADDITIONAL INFORMATION:

I’d like to reproduce this and collect data. Someone got advice how to do that the best way? (record memory usage, gps event, app crashed…, maybe just record dbus?)

2 Likes
Community meeting on IRC 15th September 2022
#2

I’ve same problem with OSM Maps. When opened, it’s impossible to launch Opera or it crashes. Looks like insufficient RAM. But hey, XA2 have 3GB, what’s going on?

#3

The easiest thing would be to simply run free -m.
But yeah, this is exactly the behaviour of lkmd when you have minfree set quite low. All devices up to X10 had this set low, which meant that the android-only lkmd kills apps slightly faster than system-wide lowmemorykiller. 10 II and 10 III had this value brought much higher, which simply meant that system apps are killed faster, so there is some space left for Android apps.
What can you do?
You could raise those values, which will mean native apps will get killed faster, which is exactly the opposite of what we are trying to do in another thread. Values from this post should be fine for example: Tuning the oom killer / low memory killer - #15 by direc85
You could increase /proc/sys/vm/swappiness from 25 to 50 or 60, which should slightly help with memory usage. No drawbacks to this, but also small gains.
Remember that both values get reset with reboot, so you can test without concerns of breaking things, but also need to remember of setting them.
No other ideas I am affraid, I have been struggling with 3GB of ram on X10 too.

#4

Just to clarify @thigg, is osmand the Android app of this name? Or is this a Sailfish app that I’m not familiar with?

#5

Yes, the android app

#6

Thanks for the clarification. If it were a native app I would have suggested checking top or ps to see if the process is still running, just without a UI, since this can sometimes be the cause of an app failing to restart. But for Android apps I’m not sure sure, so I’ve created an internal report for this and tagged it as “tracked”.

#7

FWIW, I also noticed this with Android apps like Street Complete and Phone Track (both from f-droid). Phone Track worked fine, until I used the function to plot the current trace on the map, which caused it to freeze almost immediately. I had to restart Android service to get it working again. An earlier quick test with the live location sharing in Element did give any problems, but at that moment I wasn’t looking for signs of troubles.

Also, FWIW, I used suplpatcher on my XA2 to restore some functionally of GPS SUPL. Not sure how that would interfere with things here.

Last FWIW: PureMaps works flawless over long periods.

#8

I have the same problem. So osmand is working for some time and than it suddenly closes. Also the android layer dies. After some time I can start osman again and go ahead for some time. Quite annoying behavior. But how to fix this??
Just the thread about memory usage https://forum.sailfishos.org/t/tuning-the-oom-killer-low-memory-killer/ is a bit too mutch for me. So I have no glue what to do…

#9

That is the problem, the oom killer is exactly what is causing the problem. And if you lower the values as described, it should much improve your situation.
If you don’t want to do it yourself, you would have to hope someone from Jolla would agree to implement this change, and then wait for next SFOS release. And even though it has been pointed out a few month ago already, no decision on it yet. Consider lowering LMK values to those of 10 III · Issue #24 · sonyxperiadev/device-sony-lena · GitHub