Missing locations while the app is in the background

[HarelM]

Describe the bug
I'm using this plugin in my app and it generally works great. Thanks for all the effort you put into it!
Having said that, I noticed in my last recording that there was a place where there were no locations updates for 6 minutes when the app was in the background and after that the GPS seems to trying to reposition itself as the accuracy went down from 120 meters to around 10 in a few seconds.
This can be seen in the following image (I was walking on the blue trail):

I can share the recoding of this session or the log file my app collected if needed.

My question/request is to understand how to better debug these kind of glitches to better understand what went wrong in this case - was the service killed/stopped/paused? the GPS from the phone stopped sending signals? Capacitor stopped receiving messages? etc...

In some cases the OS kills the app, but it doesn't look like it in this case as the app's log doesn't show boot-up messages.

To Reproduce
Steps to reproduce the behavior:

1. Start location tracking
2. Go to the background
3. Return from background
4. Expect some GPS signal to be collected while in the background - this doesn't happen all the time, and on a trip of around 3 hours it only happened once, while the app went to the background for multiple times for varying time spans.

Expected behavior
Get locations updates while in the background

Screenshots
See above

Smartphone (please complete the following information):

• Device: [e.g. iPhone6] Samsung S20
• OS: [e.g. iOS8.1] Android
• Browser [e.g. stock browser, safari] chrome webview
• Version [e.g. 22] 12

Additional context
I think it might prove beneficial to store some logging information in the native code and allow fetching this info when required for better debugging? IDK, any insight and thought will be helpful.
If you think there's something I can push forward in terms of PR please let me know.
This plugin is a core capability of my app and I'm willing to invest the time needed to improve this plugin to better support my needs.

[diachedelic]

I test this plugin using the example app. If you can reproduce your problem using the example app, then there is a problem with the plugin.

To debug problems, I litter the code with print statements and then walk around with my phone plugged into my laptop, and a debugger open. The relevant Android code is in BackgroundGeolocation.java and BackgroundGeolocationService.java.

[HarelM]

Thanks for the super fast response!
I don't think I'll have an easy time reproducing the issue. As I said, I walked for 3 hours and it only happened once.
In most cases I can't walk around with my laptop plugged to my phone to allow debugging so I believe a better debugging option is needed.
This might complicate things a bit but the previous plugin I used had the logs written to an sqlite DB and allowed fetching those when needed.
I really like the simplicity of this plugin and I don't want to return to the old one since its too complicated, but still had some nice features...
I also prefer not to create a fork and have this code available for others.
Let me know how you would like to proceed.

[diachedelic]

Was your phone locked the entire time? Or just for the short time when it stopped recording?

You could modify the plugin to write to a log file on disk, that would be much simpler than writing to a database. You could also modify your application to write to a separate log file. Then, the log files can be compared.

[HarelM]

Ah, yes, disk log file is a lot simpler.
The phone was locked from time to time, not all the time.
In the time this glitch happened (the straight line) it was locked and the positions afterwards are from when it was open and the app in the front. After that and before that it was locked again from time to time without any issues.

[HarelM]

Would you be interested in a PR which writes some app logs to file and allowing to retrieve the file's content from capacitor js code?

[diachedelic]

No, sorry. I intend to keep this plugin as simple as possible. But if you find a way to reliably reproduce the problem I will take a look at it.

Keep in mind that GPS is not super reliable - satellites are constantly moving, and the device must work to maintain a fix. We have found that in certain places, at certain times, with certain devices, or even in certain cars (interference?) GPS can be extremely flakey.

[diachedelic]

Actually, I'm thinking that this might be a good idea. What about something like this?

BackgroundGeolocation.addWatcher(
    {
        ...

        // In addition to being delivered to the callback, locations can be
        // appended to a file. Locations that have been written to disk are
        // more likely to survive a crash. Each location is JSON encoded and
        // appended to the file as a single line.

        // The "file" option, if specified, is a string containing the URI to a
        // writable file. The file is created if it does not exist.
        file: "file:///path/to/my_locations.txt"

        ...

[HarelM]

This is a very simple and elegant solution! I like it.
The only question I have is who manages this file, i.e. can the app delete it? If so, how will the plugin avoid file corruption? Or more to the point when can this file be deleted? Any time? Just when not "watching locations".
Also the file path stuff is super complicated between ios, Android and how capacitor works.
I saw the same problem in sqlite capacitor plugin where giving a location to a file is complicated.
But, nevertheless, I find this as a good improvement where I can later on debug the difference between what I got from the callback and what's in the file. It will help me makes things more robuts, hopefully.
Thanks for considering it!

[diachedelic]

It is up to the app to delete the file, if it wants to, and it can do any at any time. If at any time the file does not exist and the plugin wants to write a location to it, then a new file will first be created. Why would there be file corruption?

[HarelM]

I see. I don't know, if you delete while writing?
In any case, if this is handled by the OS then there's no problem.

[diachedelic]

If the file is deleted partway through a write (which might be possible if each happen on a different thread) then:

• the write operation might fail with an exception, and
• the file will end in a partial line.

We can handle the exception, of course, but I think we can leave it up to the consumer of the file to ignore any lines that can not be parsed as JSON.

In practice, I think there will be minimal opportunity for corruption.

[HarelM]

I see, you're probably right. I'm in 😄

[diachedelic]

Would you like to build it?

[HarelM]

Whatever works for you. I can give it a go.

[diachedelic]

Yes please.