Major Traccar Client update

Anton Tananaev 21 days ago

We're doing another major rewrite of the Traccar Client. Instead of a third-party proprietary library, we're developing our own background location SDK:

https://github.com/traccar/traccar-client-sdk

It's fully open source, so you can use it in your own app - but it will also power Traccar Client. Here's a preview version of the new Traccar Client for Android:

https://traccar.nyc3.digitaloceanspaces.com/download/app-release.apk

The UI and configuration should be mostly the same as before. One of the most important changes is that it now supports phones both with and without Google Play services.

Please try it out and share your feedback. We'll be moving quickly toward release, so it's very important to test it and make sure the next version works for your specific use case.

Antony 20 days ago

Finally a version that is play services independent wooohooo

Is there something specific that you want to test ? What is the logic for the new version m does it switch gps on automatically on highest accuracy when moving like old sdk ?

I will give it a shot sometime maybe around the weekend as I barely have the time to test it now. Can't wait to test it and thanks for releasing it as a beta before forcing everyone to switch to it last time when you switched to the previous sdk was a bumpy one.

Anton Tananaev 20 days ago

Test any use case(s) you're interested in.

The logic is slightly different depending on whether you have Google Play services:

  • If you have Google Play services, we support stop detection based on the Google activity API. On highest accuracy we request highest accuracy from Google fused location provider, which should prefer GPS, but can still fallback to other options if GPS signal is not available.
  • If you don't have Google Play services, we don't support stop detection. On highest accuracy we will request highest accuracy, which should mean GPS only.
AussieTraccar 20 days ago

Device: Samsung Galaxy
OS Version: Android 13
Google Play Services: Yes

Settings:

  • Accuracy: Highest
  • Distance: 100m
  • Interval: 300
  • Angle: 0 (Disabled)
  • Advanced:
    • Offline buffering: Enabled
    • Wake lock: Enabled
    • Stop detection: Enabled

Highest Interval:
The interval is sent regardless whether stopped or moving, which appears by design, but when completely stopped, the speed tends to remain at a non-zero value e.g 0.26km/h. I configured <entry key='event.motion.speedThreshold'></entry> to filter out these non-zero values, otherwise the device motion stayed active even though the device was stationary on the table.

High Interval:
Appears to be better with battery and GPS location, although when stopping, it didn't send update and speed was stuck at 30km/h.

On the high and medium settings, the option to configure a heartbeat/interval value (0 to disable) would be nice? This would help prevent inactivity events from being triggered.

As the OSMAND protocol has moved to url encoded elements. Is there a plan to have the element charge=false/true passed through to evaluate?

My biggest issue with the previous version, was the frequency of the location updates (both iOS and Android) which ignored the interval setting and caused the battery life to suffer greatly. This in-house version appears to honour the interval better, so I am hoping for a better battery life with good location experience.

Anton Tananaev 20 days ago

When you select highest accuracy, it will keep GPS ON all the time, so battery won't last very long.

We will look into improving stop position and charge status.

Antony 20 days ago

Whaaaaaat . Why would the highest option constantly keep the gps on and in use despite of the moving state! That was the best thing about the previous sdk which intelligently switched gps on while moving balancing battery use and accuracy. Is this something that will change or is it here to stay?

Anton Tananaev 20 days ago

No, I meant it will be always ON when moving, not stationary.

AussieTraccar 20 days ago

Happy when highest accuracy selected to have location response over battery life.

If you are going to work on sending the charge status. Might as well add sending updates when the battery level changes whilst stationary?

Anton Tananaev 19 days ago

Sending updates when stationary creates noise that most people don't want, so I don't think we should send regular location updates when stationary.

AussieTraccar 19 days ago

So based on that, no heartbeat option either?

Anton Tananaev 19 days ago

Heartbeat is still on the table, but probably won't be in the initial release.

AussieTraccar 19 days ago

That is great to hear.

So if you just happen to add the battery level to the heartbeat, it's a win win for us all then.

Anton Tananaev 19 days ago

Yes, it will likely include include battery, but not new location.

depth7503 19 days ago

Would it be possible to have a toggle for Google Play vs not, at least while testing? I have Google Play Services, but would like to test without as well.

depth7503 19 days ago

P.s. way to go with developing this! ❤️