App crashes after a very long time in the background

[HarelM]

Describe the bug My app crashes after retuning for foreground after being a long time in the background when using this plugin. More details can be read here: https://github.com/IsraelHikingMap/Site/issues/1746

To Reproduce Steps to reproduce the behavior:

1. Start tracking
2. Go to the background
3. Go back to foreground after 2 hours of hike

Expected behavior App should not crash

Screenshots This was reported by a user, so I don't have more information

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context I'm not sure where the issue is, so any information related to this plugin will be helpful. There are two options here:

1. The fact that all these messages are happening in the background and are creating some overloaded queue in the javascript code that when returning from background it simply "explodes".
2. My app is using a map (maplibre), and the map updates are crashing it since the map.

So any info in that area would help better understand the issue. I'm not sure how Capacitor handles this in general, but it seems that requestAnimationFrame is not completing when the app in the background, but it might be related to chrome webview and not specific to Capacitor.

To compare to the cordova plugin I was using before testing the migration to this plugin, there are two main differences that I'd love to get input about:

1. When the app is in the background I don't update any components and all locations are stored in an sqlite db inside the old plugin. When the app returns to the front all locations are grouped and sent at once, so there's 1 update for the entire time in the background, which might help the app to avoid "choking"...? What's the alternative with this plugin?
2. Locations are stored in an sqlite database and if the OS kills the app while in the background I can recover those when the app starts again. Do I need to implement such logic using indexDB or something (which might be used to solve the above item)? Did you or anyone else wrote something similar?

Thanks! any info is appreciated!

[diachedelic]

Have you tried to reproduce the crash? Without more information there is not much I can do.

Whether you update your UI while your app is backgrounded is up to you. This plugin simply informs you of locations. If it gives you too many locations too quickly, you can always throttle them.

[HarelM]

Yea, unfortunately I don't have more details, just wondering if you have experience with such issues...

[HarelM]

How can I know if the cause of the app stop receiving locations is due to app crash/os kill or something else (in android)? Only logcat, right? I changed the logic to only store the locations in memory while the app is in the background (and written to log which is stored in indexdb), but I now see a report where the locations are not received anymore in the background after a long recording and the movement to the foreground, and the move to the back for 5 minutes...

[diachedelic]

If you are able to reproduce the problem, it should be possible to discover what is going wrong. I would be putting lots of print statements in the Java files and looking very carefully at the logs.

[HarelM]

Seems like this is not specific to this plugin. We can reproduce this with the "old" plugin as well, we are not sure if this is related to the capacitor migration or some changes in the phone's OS (upgrade etc). If you have any pointer how to keep the app running for a long time (i.e. days, not just hours) I would love to know. I know this is related to vendor specific and "don't kill my app" thing: https://dontkillmyapp.com/ But if you have tips please let me know :-) Closing this issue now... Thanks you for all the help!!