GPS stuck constantly on when stationary on some devices. Logs provided

Antony 23 days ago

Traccar sometimes keeps the GPS continuously active indefinitely, even when an Android device is completely stationary for several hours (for example, sitting untouched on a desk). Worth mentioning it doesn't affect all devices and isn't always happening all the time on the same device.

Configuration

The affected devices are all Android devices. I don't have any iPhones available at hand to test whether the issue also occurs on iOS anyways.

Traccar settings are:

Accuracy: Highest
Stop detection: Enabled
Use system location: Disabled

Observed behavior

When the device remains completely stationary for hours, Traccar sometimes continues keeping the GPS active continuously instead of transitioning to stationary mode.

I initially wasn't sure what was causing this because the logs don't record the recognized activity or its probability alongside each location update.

To investigate, I exported the logs while the device was completely stationary and the GPS remained continuously active for several hours and the distance between any 2 consecutive coordinates remained less than 2 minutes at any given moment which shouldn't trigger switching to moving state.

all distances in logs are in meters btw
Here are the logs while experiencing the bug

I then disabled continuous tracking for a moment and enabled it again. Since Traccar fetches and logs the device's current recognized activity when continuous tracking is first enabled, I was able to see that the device was recognized as still with 100% probability.

all distances in logs are in meters btw
Here are the logs after switching continuous tracking off then back on again

Interestingly, a couple of minutes after re-enabling continuous tracking, the GPS was turned off and Traccar correctly entered stationary mode.

This raises the question: if Traccar already recognized the device as stationary with 100% probability, why did it previously continue keeping the GPS active for hours as though the device were moving?

This makes me suspect that there may be a problem with how the recognized activity/state is being used to transition between moving and stationary modes, or that the activity recognition result isn't being evaluated/received correctly while continuous tracking is already running. or maybe sometimes traccar isn't getting the recognized activity from android?.

However, without the activity recognition result and Traccar's internal moving/stationary state being logged for each location update, it is difficult to determine exactly where the problem occurs.

Feature request / debugging information

Would it be possible to include the following information in the logs for every location update?

Traccar's current device state (moving or stationary)
The recognized activity (e.g. still, walking, in vehicle, etc.)
The probability/confidence of the recognized activity
Ideally, any relevant information indicating why continuous GPS/location tracking was kept active or why it transitioned to/from stationary/moving mode

This would be particularly useful now that Traccar supports exporting logs as files, because it would make it possible to capture and analyze the exact sequence of events leading to this issue.

Having these values logged alongside each location update would hopefully make it much easier to determine whether the problem is with Android's activity recognition, Traccar's interpretation of the activity result, or the logic responsible for switching between moving and stationary tracking.

Anton Tananaev 23 days ago

Could you provide logs covering tracking startup, some movement, and then leaving the device stationary until the problem appears? Please export shortly afterward, since only the latest 5,000 entries are retained and earlier events get overwritten.

Antony 23 days ago

Problem is, issue is inconsistent. The same device might not always experience the issue. That's why when by the time it happens, most probably the last start tracking log event would have been overridden. That is why I was wondering if you could include the necessary info with each log entry to be able to figure out where is the issue coming from.

Anton Tananaev 23 days ago

Alternative solution is to reduce reporting frequency.

Antony 23 days ago

Not sure what you mean honestly. Do you mean reducing the interval value?

Anton Tananaev 23 days ago

Basically yes, but I don't know your configuration.

Antony 23 days ago

Hmmm. How is this going to help if you don't mind me asking? Currently it is set to 30 seconds. If reduced that means for example the app will send a location update at an interval of 5 seconds instead of 30 when in moving state.

Anton Tananaev 23 days ago

It's going to help and get full logs, including relevant data.

Antony 23 days ago

Or if you mean by reduce reporting frequency, to increase the interval. That will mean to send a location ipdate once every 120 seconds instead. But the vast majority of entries in logs is obtaining gps coordinates not sending an update so don't think this will help honestly

Antony 23 days ago

Ok, sure will try it on all of my test devices and wait untill a device faces issue and share logs

Antony 17 days ago

After almost a a week, I can't manually trigger this bug as I don't honestly know what triggers it in the first place so by the time any device I have encounters this bug and I try to analyze the logs, it will be full of location update entries and since only the latest 5,000 entries are retained and earlier events get overwritten the relevant info that helps identify what could possibly be leading to this bug will be gone. I really hope that an updated format of the logs that logs the reason each location update is triggered alongside the device's currently recognized activity and the reason the device is in moving state will be considered in order to help figure out the root cause of this bug, otherwise it is near impossible to figure it out.

Antony 9 days ago

I FINALLY was able to obtain the logs from a device that encountered the bug that causes the GPS to remain constantly on and in use despite device being completely stationary and the stop detection logic didn't properly engage as it should. Look at line "2026-09-23 19:04:20 Location filtered Distance from last cordinates 0.405236" which is when the device went completely stationary, however the GPS remained in use and constantly on for the next at least 40 minutes until continuous tracking was turned off and turned back on again, while the logs don't show the full 40 minutes but it follows the same pattern. When turning off continuous tracking and turning it back on the recognized activity was still with confidence of 100%

Traccar configured as follows during this test:
Accuracy: Highest
Distance: 300
Interval: 250
Angle: 90
Stationary heartbeat: 900
Offline buffering: off
wake lock: On
Stop detection: on
Use system location: off

I seriously don't know what is the trigger for this bug as it doesn't always affect the same device and it isn't just an issue with one device!!! , without better logs format that logs the recognized activity and reason why traccar is in moving state with every update, it is near impossible to figure out the reason and the trigger.

Note that all distances in the logs are in meters

Logs' link: https://wormhole.app/NOrAok#nhP7ZhvkkKr53Ju9SZRfJw

Anton Tananaev 9 days ago

Thanks, these logs help. Stop detection worked initially: at 18:52:14 the app entered stationary mode and stopped location updates. At 18:53:47 a geofence exit resumed tracking, but no further activity recognition events appear through the end of the logs at 19:16:23. Without another "still" event, the stop timer was never started again.

This narrows down the problem, although it doesn’t explain why activity recognition stopped delivering events. Logging activity with every location would only repeat the last received value, which could be stale.

Which device model, Android version, and Traccar Client version produced these logs?

Antony 9 days ago

This bug happens on samsung s26 ultra, samsung a17 (both running latest firmware) Redmi note 4 (running lineage os based on android 11 with play services) and the logs were from a Nokia device running android 12. These are some of the devices on which this bug occurred. But again, same device doesn't always encounter same bug amd I truly have no idea what is the trigger! . Logs collected from traccar 10.1.2 but it happened on previous versions as well

Anton Tananaev 9 days ago

Do you have location history around that time?