Hi Anton.
I compiled version 6.7 of the Traccar Client to customize it.
It compiled and ran successfully on My Xiaomi Redmi 9 SmartPhone with Android 10. Everything seemed fine until I realized that when the app goes to the background, either because I turn off the screen or because I close the App, the process
apparently it stays in the background but it no longer sends GPS coordinates. Once I open the application or send an SOS from the icon, it works again and sends data back to the server, leaving a gap of data lost in the time it was in the background (in console view do not give me a concrete clue, only it state waiting coordinates from position provider java routines).
I have not moved anything in the code and I compile without any error in android studio, just rename it in the string.xml.
Doing many tests I have realized that only by removing the default battery restriction that the phone applies to new apps that are installed, only then does it work normally in the background. That is, the battery restriction affects at least
on this phone. Looking at the java code I see that there are parts that interact or sense the state of the battery.
I have also installed the official traccar client application from the playstore and the battery restriction has no effect on this same phone as in version 6.7 that I compiled.
Anton, I was wondering if there is some calibration or constant parameter in java code that controls this behavior with the battery, or how to make the versions that I compile as stable as the official client to deal with?
Or any clue of what may be going on?
Thanks a lot in advance...
There are actually two flavors of Traccar Client. Google version and pure Android API version. There's a bit of a difference. Google version uses fused location provider. You can compile both from GitHub if you want to compare.
Muy Agradecido Anton, observaré el comportamiento de ambas versiones.
Okay. The google version is more stable. Thanks.
I had to pull up a google-services.json in the firebase console so that it could run because the flavor asked for it.
The question is what is the object of it? Cloudmessaging is not used in the traccar client.
Is it for a more precise or complementary geolocation using google apis?
The question is aimed at calculating or anticipating some extra cost in this version of the traccar google client, when using firebase services.
Thank you very much as always Anton.
The difference is that Google version is using fused location provider, which is only available as a part of Google Play services.
We also use Firebase for crash analytics, but that won't affect anything else.
Hi Anton.
I compiled version 6.7 of the Traccar Client to customize it.
It compiled and ran successfully on My Xiaomi Redmi 9 SmartPhone with Android 10. Everything seemed fine until I realized that when the app goes to the background, either because I turn off the screen or because I close the App, the process
apparently it stays in the background but it no longer sends GPS coordinates. Once I open the application or send an SOS from the icon, it works again and sends data back to the server, leaving a gap of data lost in the time it was in the background (in console view do not give me a concrete clue, only it state waiting coordinates from position provider java routines).
I have not moved anything in the code and I compile without any error in android studio, just rename it in the string.xml.
Doing many tests I have realized that only by removing the default battery restriction that the phone applies to new apps that are installed, only then does it work normally in the background. That is, the battery restriction affects at least
on this phone. Looking at the java code I see that there are parts that interact or sense the state of the battery.
I have also installed the official traccar client application from the playstore and the battery restriction has no effect on this same phone as in version 6.7 that I compiled.
Anton, I was wondering if there is some calibration or constant parameter in java code that controls this behavior with the battery, or how to make the versions that I compile as stable as the official client to deal with?
Or any clue of what may be going on?
Thanks a lot in advance...