Throttled location updates when in foreground service?

[Phyks]

Hi,

Description

I am using Traccar client for Android for tracking my phone position. It basically wraps around LOST, as can be seen here. I tried to debug a bit around the issue and so far it seems to be coming from within LOST.

The app uses a foreground service to update location, main location updating code is mainly here.

For my tests, the setInterval call (https://github.com/tananaev/traccar-client-android/blob/master/app/src/main/java/org/traccar/client/PositionProvider.java#L91-L94) is such that the location should be updated every minute. That's more or less the case when the app is running in foreground (between 60 and 120s, but that's more or less accurate).

However, whenever the app is running in background, the location is no longer updated at the expected interval. It seems that LOST is not sending events at expected interval. Basically, with a 1 minute interval, the location is updated every 4 minutes in background. And with 10 mins interval, that's even worse and the location is updated once per hour.

I am using NetworkProvider (running LineageOS 14.1 with microg, and using the UnifiedNIP location provider). Everything is working perfectly fine when the app is in background.

Is there any reason for this difference of intervals? Is Android throttling location updates in the background? So far, the only reason I could come up with (from the docs) is the "battery optimization" feature of latest Android versions, but I tried to disable with with same results.

Lost & Android Version

LineageOS 14.1 with microg + LOST 3.0.4 (in https://github.com/tananaev/traccar-client-android).

Thanks!

[JosefRypacek]

I have the same issue using Nexus 5 and stock ROM 6.0.1. I request updates every 10 minutes and I got only few updates per day when phone is not used for anything else. Battery optimizations are disabled, not sure what is going on...

[Phyks]

A small update on this: I have been using successfully Owntracks (which uses Google Play Services API) for two days now, so I guess my bug is either in Traccar or LOST. I'll try compiling lost-sample app as soon as possible to be able to distinguish between a Traccar bug or a LOST bug :)

[sarahcodes100]

Thank you all for the details and sorry for the delay, I have been away on vacation. I will need to do some testing to verify if this is a bug in LOST or throttling by the OS. I’ll get to it later this week and report back! Thanks for your patience

[Phyks]

No problem, thanks a lot for looking into it!

[JosefRypacek]

I've tested traccar 5.5 (without lost) and 5.7 (with lost). Traccar without lost used similar code to retrieve position.
Results are not much accurate, but I can't see big difference between versions. I prefer GPS (HIGH accuracy) in traccar. Interval is set to 5 minutes.

In Android Settings->Location I can select which data sources are used to get position.
While HIGH accuracy (gps, wifi, network) is selected, traccar sends update almost each 5 minutes.
While DEVICE only is selected, traccar sends less updates (6-7 per hour instead of 12). Typical example is below:
$ cat /opt/traccar/logs/tracker-server.log | grep -io '2018-01-18.*>' | grep ' 12'
2018-01-18 12:07:02 DEBUG: [DF65485A: 5055 >
2018-01-18 12:15:30 DEBUG: [125D2916: 5055 >
2018-01-18 12:21:46 DEBUG: [86583E88: 5055 >
2018-01-18 12:33:22 DEBUG: [61D5568E: 5055 >
2018-01-18 12:41:48 DEBUG: [CFDD4D04: 5055 >
2018-01-18 12:50:53 DEBUG: [57C405EC: 5055 >

[X-Ryl669]

This is likely due to Oreo new restrictions for background location polling. See here:
https://developer.android.com/about/versions/oreo/background-location-limits

Note: If your app needs access to location history that contains time-frequent updates, use the batched version of the Fused Location Provider API elements, such as the FusedLocationProviderApi interface. When your app is running in the background, this API receives the user's location more frequently than the non-batched API. Keep in mind, however, that your app still receives updates in batches only a few times each hour.

The only way I've found to solve this is to exclude the application from Doze "optimization" (go to Battery / Application / no restriction).

[msmollin]

Closing as this repo is no longer maintained.