New traccar issues and feedback
On Android we don't use geofences. We use activity monitoring. But there are some known issues that we're working on.
Form-based protocol is the original protocol Traccar Client used for years, so it's not something new.
This is unrelated to server, but I've seen this issue, so need to investigate.
Do you have access to logs to see the crash stack?
1- Hopefully it will fix it because as of right now. New traccar is unusable due to high battery usage while user is stationary . This is a deal breaker
2- Yes it was the default for the old traccar before switching over to the previous sdk. I guess it isn't a big deal to switch back to form based payload parsing over an application/json one. However since I would imagine that everyone who used traccar within the past year had to migrate to parsing the payload as application/json rather than a form data it would have been nice to keep it this way so that servers don't need to be updated in order for things not to break for those who have their own servers. But again it isn't a deal breaker and easy to simply update on the server.
3- I disagree. I think it is related as I had tested with a local server and as long as I had that server up and running traccar would open in less than a second. The moment I killed the server and closed traccar from the recents page on android, it took around 10 seconds to get past the splash screen and this is consistent for at least the 10 times I tested this. Maybe there are other variables as well leading to this issue that you are looking into but the one mentioned in the original post is certainly another one
4- Will get them for you later on when I have access to that device again
Please try the new version. It should fix some issues (hopefully 1 and 3).
https://traccar.nyc3.digitaloceanspaces.com/download/app-release.apk
I just tested it and point 3 is fixed . However point 1 isn't fixed and is the same for me
Have you checked client logs?
I will be sharing client logs from device with play services that I am using for testing with the gps stuck on even while completely stationary shortly. Issue number 1
For issue 4: I have the crash logs for the device without play services but don't wish to publicly share them here. Is there any chance I can share them on signal with you?
We don't need crash logs. We just need crash stack trace. It does not have any sensitive information. It just points to the code where the crash happened.
Traccar logs for device with play services that has gps stuck constantly on despite being totally stationary sitting on a desk. Masked gps coordinates and added distance in meters from last gps coordinates. I didn't spin up a server as it was irrelevant to the test and that is why location updates failed in these logs
2026-06-07 16:55:54 Tracker start http://192.168.1.29:6790 23807360
2026-06-07 16:55:54 Service created
2026-06-07 16:55:54 Acquiring wakelock
2026-06-07 16:55:54 Using FusedLocationProvider
2026-06-07 16:55:54 Engine started
2026-06-07 16:55:55 Location accepted *********,*********
2026-06-07 16:55:56 Upload error: Failed to connect to /192.168.1.29:6790
2026-06-07 16:55:56 Location filtered *********,********* distance from last location 0.0 meter
2026-06-07 16:56:01 Location filtered *********,********* distance from last location 0.29265373916124604 meter
2026-06-07 16:56:07 Location filtered *********,******** distance from last location 0.2928540592613026 meter
2026-06-07 16:56:13 Location filtered *********,********* distance from last location 0.2907464440516376 meter
2026-06-07 16:56:19 Location filtered *********,********* distance from last location 0.19880615311519717 meter
2026-06-07 16:56:25 Location filtered *********,********* distance from last location 0.058091289876765116 meter
2026-06-07 16:56:31 Location accepted *********,********* distance from last location 0.1681352102501312 meter
2026-06-07 16:56:31 Upload error: Failed to connect to /192.168.1.29:6790
2026-06-07 16:56:32 Location filtered *********,******** distance from last location 0.03840153151962393 meter
2026-06-07 16:56:33 Location filtered *********,********* distance from last location 0.01902339529393967 meter
2026-06-07 16:56:33 Location filtered *********,********* distance from last location 0.034688044867741824 meter
2026-06-07 16:56:34 Location filtered *********,********* distance from last location 0.028535093455490518 meter
2026-06-07 16:56:37 Location filtered *********,******** distance from last location 0.05059986521430687 meter
2026-06-07 16:56:38 Location filtered *********,********* distance from last location 0.08290213729414075 meter
2026-06-07 16:56:39 Location filtered *********,********* distance from last location 0.13040580011860411 meter
2026-06-07 16:56:39 Location filtered *********,********* distance from last location 0.04389805923004838 meter
2026-06-07 16:56:43 Location filtered *********,********* distance from last location 0.4052418061606851 meter
2026-06-07 16:56:49 Location filtered *********,********* distance from last location 1.1136270026323356 meter
2026-06-07 16:56:55 Location filtered *********,********* distance from last location 0.5629531747475619 meter
2026-06-07 16:57:01 Location filtered *********,********* distance from last location 0.3124211854402078 meter
2026-06-07 16:57:07 Location accepted ********,********* distance from last location 0.2186583513148368 meter
2026-06-07 16:57:07 Upload error: Failed to connect to /192.168.1.29:6790
2026-06-07 16:57:12 Location filtered *********,********* distance from last location 0.11628668729656168 meter
2026-06-07 16:57:18 Location filtered *********,********* distance from last location 0.08663758271495077 meter
2026-06-07 16:57:19 Location filtered *********,********* distance from last location 0.05853074190635301 meter
2026-06-07 16:57:24 Location filtered *********,********* distance from last location 0.06125012490040561 meter
2026-06-07 16:57:30 Location filtered *********,********* distance from last location 0.04389805660332143 meter
2026-06-07 16:57:36 Location filtered ********,********* distance from last location 0.145126200825082 meter
2026-06-07 16:57:42 Location accepted *********,******** distance from last location 0.12807270878844085 meter
2026-06-07 16:57:42 Upload error: Failed to connect to /192.168.1.29:6790
2026-06-07 16:57:48 Location filtered *********,********* distance from last location 0.024187700314510868 meter
2026-06-07 16:57:54 Location filtered *********,********* distance from last location 0.0800714438995259 meter
2026-06-07 16:58:00 Location filtered *********,********* distance from last location 0.0 meter
2026-06-07 16:58:06 Location filtered *********,********* distance from last location 0.08779611408875276 meter
2026-06-07 16:58:12 Location filtered *********,********* distance from last location 0.11281046564300005 meter
For the full log ( it was too long to paste here )
https://wormhole.app/kAr7mm#NNnoS4_NXgyo6LgVOI4yxA
I don't see any activity events, so the phone never reports it as being stationary.
Yes indeed. However with the old sdk it works just fine. So I am not sure why did it stop working on the new version.
Have you tried walking and then go back to stationary mode? It's possible that we use slightly different APIs. We use the one that sends only when state changes.
I am not sure how to get the "crash stack trace" that you were looking for honestly fpr the device without play services
adb logcat -b crash -d | grep org.traccar.client
Doesn't return anything interesting.
Honestly these are test devices that I don't personally use. Maybe walking to force a state change will do the trick. I haven't tried honestly. Will try and report back
For crash stack try searching for "Exception" in the logs.
1-On the highest accuracy, traccar constantly keeps the GPS active and in use even after more than 30 minutes of being completely stationary (phone sitting on a desk). I think you are encountring the same bug that the previous sdk used to encouter with play services until they released the workaround that fixed it https://github.com/transistorsoft/flutter_background_geolocation/commit/590b457b645c8598375019c3afe87d93a3518041 for reference : https://www.traccar.org/forums/topic/2-bugs-in-traccar-for-android/page/2/
2-The old traccar used to send the data as a json object with headers content-type application/json, now it switched over to application/x-www-form-urlencoded . Which is okay if someone inspects the payload and edits the server logic parsing location updates, but it would be better if it remained application/json payload in order to avoid having some servers being unable to parse location updates reducing the update friction for users.
3-With the new traccar, if the server used is down when the user opens traccar it will remain stuck on the splash screen for ages. I think it tries to send a location update first and waits for the request to time out before giving the user access to the app. However this isn't ideal, the app shouldn't wait for the request to timeout in order to give the user access to the app.
4- Device on lineage os 18.1 without google play services: Traccar crash on start, it doesn't even show the splash screen