Incorrect location reported for multiple hours

[nicbou]

• App build number: 2.2.0
• Android version: 11
• Device: Google Pixel 5

Today, I went on a 3 hour kayak trip, and a 2 hour motorcycle trip. I left home at 12:00 and returned at 18:00, but the GPS logs shows that I was at home the entire time. I was 20-50 kilometres away, but several updates show me as being home.

During that time, I used Google Maps and OsmAnd+ for most of the day, so I expected to see a very detailed GPS log. Instead, I only see a dozen updates, all with the exact coordinates of my home address.

In the MQTT logs, I see several log messages from my non-home IP (over the cellular network). I see matching reports in the geolocation logs. However, they all show me at home.

I took picture during that period, and those have the correct GPS coordinates. If you combine them on a map, the trace jumps between the photos' correct locations, and owntrack's incorrect locations (my home's coordinates). This means that the problem really seems to be with owntracks and not Android.

Do you know what could cause such an issue? OwnTracks has been rock solid for months, except today for some reason.

[growse]

Hmmm. This is a little concerning.

Do you know the values of tst and created_at for each "wrong" msg that at sent?

Also, I'm assuming significant changes mode?

[nicbou]

This is the code I use to parse messages. I only use the tst attribute, not created_at.

Looking at the generated entries, I see that the messages created in the afternoon (while I was outside) show the exact same values, even for accuracy and altitude. The points are exactly 30 minutes apart.

The EXIF data of pictures taken between these points have correct coordinates.

[growse]

Interesting. So tst is the timestamp of the location fix as delivered from the device API (when OT gets a new location from the device, that comes with a timestamp). created_at is relatively new, but should be the timestamp of when the message was generated to be sent to the network.

Can you also see the value of the t field? This should tell you what triggered (from within the app) the message to be sent as described in https://owntracks.org/booklet/tech/json/. I wonder if the messages OT sent were just pings where it simply resent the last known good location it had, or whether something else triggered it.

Does the interval between the messages look suspiciously regular? Like every 30 mins or something?

[nicbou]

I did not log the created_at or t fields. The updates were in 30 minute intervals, with a variation of around a minute.

In the evening, I updated to 2.3.0. I am currently on a bicycle ride, and the tracking works as expected. I did not have to do anything.

I will keep a close eye on this today, but so far, it looks like the problem solved itself. I will update this ticket if the problem resurfaces, or close it if I can't reproduce it.

[growse]

A thought:

Is it possible that you rebooted your device before your trip and didn't then explicitly open OT to the foreground?

On Android 11, foreground services that are started in the background don't get locations (see https://developer.android.com/about/versions/oreo/background-location-limits). If you set "Autostart on boot", the service is started from a broadcast intent, which I believe is essentially the same as the background. Locations will only flow through to the service once the OT activity is opened.

This is a problem I'm still trying to work out, but I wanted to see if you think this might be the cause?

[nicbou]

Is it possible that you rebooted your device before your trip and didn't then explicitly open OT to the foreground?

In hindsight, this is likely. I rebooted my phone a day or two earlier. Looking at the map on the day I rebooted, I can see that the reporting ended abruptly.

I'm curious why it would report an incorrect location instead of no location though.

However, the next day (after the reboot, before the trip kayak trip), I see a trace for my walk around the neighbourhood, so it must have been receiving background location. Those GPS points could also come from EXIF data from my photos though (owntracks is only one of the sources).

[growse]

It could be that while the service is not getting up-to-date locations, it's still occasionally receiving the "last available" location, that possibly was delivered to the client when it was in a state that was allowed to receive locations. Also, any changing of the monitoring mode or opening the activity will re-create the service, and since that's a foreground action creating the service, that will allow it to receive locations again.

It's not ideal, I realise. I'm currently toying with the idea of showing an extra little notification alerting the user if the service is started from a background context that no locations will be received until they explicitly ask for them (by opening the app). It's clunky, but the alternative is a lot of faffing around with google, jumping through hoops to get BACKGROUND_LOCATION.

[nicbou]

That's not a problem for me. I'll pay closer attention when rebooting the phone. It's still more reliable than remembering to turn on my Garmin InReach, Komoot or anything of the sort. Besides, there are no consequences if I lose a few points here or there.

I'm really happy with OwnTracks, and I hope you keep up the good work.

[growse]

Thanks - we appreciate it.