Recording stops in the background

[valleyofdawn]

Bug

What I expect to happen

I expect the recording to be continuous.

What really happened

It was stopped twice and completed using bogus locations.

What I did that caused the issue - step by step

I recorded a track.
Mobile reception was at ~1 bar. The app was running in the background while I was using OruxMaps to navigate and record in the foreground. There was another planned route on the screen. I made sure that it was not limited in battery use while in the background.
I occasionally checked that the recording continued and it worked fine until about 15.5 km in when I checked it and I saw that it wasn’t recording since km 13.5. It immediately logged one point off route and jumped back to my location (without freezing). Went on riding with it in the foreground and than moved back to Orux. Next time I checked the same phenomenon happened, but this time it went on to record the rest of the way in the background with no problems.

My environment

• Operating System and version:
• Web Browser and version:
  Debug version 8.0.0

Thing I think the developers should know, images, links etc.

Shared recording: https://israelhiking.osm.org.il/share/sgdosQQ2VQ
I can't seem to upload the log and GPX files.
faulty.gpx.txt
faulty log.txt

[HarelM]

I'm not sure why - but it seems that the application has started again according to these log lines:

2019-06-01T05:20:49.716Z | DEBUG | Valid position, updating: [34.91432708,31.62019-06-01T05:20:49.692Z | DEBUG | geo-location received location, bg: true l: {"provider":"gps","locationProvider":2,"time":1559366450000,"latitude":31.68034644,"longitude":34.91432708,"accuracy":4.288000106811523,"speed":1.0399999618530273,"altitude":282.251953125,"bearing":78.19999694824219,"isFromMockProvider":false,"mockLocationsEnabled":false,"id":2118}
2019-06-01T05:40:52.484Z | DEBUG | Starting IHM Application Initialization

It stopped at around 05:20 and started again at around 05:40 - 20 minutes gap which can explain one of the gaps, I haven't continued reading the file afterwards.
Can you check attach the battery setting screenshot for this app?

[valleyofdawn]

Come to think of it, you are right, the second time round the app has shut down on its own and I restarted it continuing the "previous recording not completed".
5:40z is 8:40 in Israel, right?

[HarelM]

I see two places where the app started - times are GMP ISO time - meaning you need to add 3 hours to get the IL time.
2019-06-01T05:40:52.484Z | DEBUG | Starting IHM Application Initialization
2019-06-01T06:27:30.854Z | DEBUG | Starting IHM Application Initialization
When the application starts the first location is always used so it might explain the jumps when the app starts.
Looking deeper in the log I see a gap in the recording - seems like there was no movement at that time as the point before the gap and the point after the gap are very similar:
2019-06-01T05:44:06.815Z | DEBUG | Valid position, updating: [34.91996901,31.69598314]
2019-06-01T06:09:30.608Z | DEBUG | geo-location received location, bg: true l: {"provider":"gps","locationProvider":2,"time":1559369371000,"latitude":31.69597095,"longitude":34.92002197,"accuracy":3.2160000801086426,"speed":1.590000033378601,"altitude":244.819091796875,"bearing":83.80000305175781,"isFromMockProvider":false,"mockLocationsEnabled":false,"id":2207}
Seems like the data that is collected when the application is in the background before a failure is lost, but I don't think there's much I can do about it...
I'll contact the maintener of the cordova application and ask him if he has an idea how to prevent this app from getting killed by the OS.

[HarelM]

Well, it seems that this is a repeating question as described in the readme of the plugin:
https://github.com/mauron85/cordova-plugin-background-geolocation#android-background-service-issues
I don't know how to make this better unfortunately, the only thing I found is startForeground, which I'm not sure will have any affect.
I can create a debug version with this option enabled to see if it makes any difference... Let me know what you think...

[zstadler]

I suggest we try everything we can

[valleyofdawn]

[34.91996901,31.69598314] was indeed a coffee break, during which I also checked my Email and WhatsApp (bad habits).

[HarelM]

I have added the startForeground flag to the initialization list of the location service.
I have uploaded a new debug version to google drive.
Please try using it and let me know if you encounter the issue again or if it's harder to reproduce it now.
Other than the last fix I have no idea how to improve this, and I think the author of the plugin doesn't also as it seems to be related to how aggressive the power management of the device was written.
We can think of buying a plugin from transistorsoft: https://www.transistorsoft.com/shop/products/cordova-background-geolocation
I think it has a demo on google play store if we want to measure how it works, I have my doubts if it will truly be better...

[valleyofdawn]

This morning experience.
Again recording in the background, this time with no other nav app working.
Occasionally turning on the screen to check the app.
Was recording nicely for 1.5 h until 2019-06-03T05:39:23.434Z when I turned on the screen to see that the app had crashed.
Opened it again, authorized continued recording of the disrupted track. It completed the missing portion with a straight line.
~10 minuted later I reopened the screen.
The app was non-responsive for ~20 seconds, then it moved the center of the screen to a point some 1 KM away (without showing the arrow cursor), than went back on course, showed the right position and continued recording.
https://israelhiking.osm.org.il/share/RaVXGN8V5I
log_2019-06-03_06-15-45.243Z.txt

2019-06-03_06-14-47.072_מסלול_2019-06-03.gpx.txt

[HarelM]

Logging issue with multithreading solution:
https://stackoverflow.com/questions/25668876/problems-using-phonegap-cordova-file-plugin-part-2-synchronicity

[valleyofdawn]

Another debugging session this morning.
First lag (~6:15-7:22) was fine. Kept the app running on the screen.
Second lag (~7:23-8:06) I turned off the screen. Whenever I opened it again the app regained location and drew a straight line from where it lost the location some time after I turned off the screen. Power saving was turned off for the app and a raster map was loaaded.
I then turned the app off; turned on Oruxmap and recorded with no issues while turning the screen off.
Logs and tracks attached.

2019-07-08_05-06-20.388_מסלול_2019-07-08_7-24-51.gpx.txt
2019-07-08_04-22-23.758_מסלול_2019-07-08.gpx.txt

log_2019-07-08_05-06-30.999Z.txt
log_2019-07-08_04-22-29.554Z.txt

[HarelM]

I have looked at the logs.
The app was not closed by the OS.
There are times that the location is sent to the app apparently but it's not always - meaning the app does work in the background but not perfect. I see about 2-3 time jumps in the logs where the app did not receive any updates. Maybe the required rate when in the background is too high so that the phone stops sending, not sure.
What is the time rate you get with orux when in the background?

[valleyofdawn]

Minimum time 0 sec.
Minimum distance 20 m.

[valleyofdawn]

Another faulty recording.
Intermittently turning off the screen.
Each time I turn it on again it takes longer for the app to figure where it is before catching up and completing the missing bit till at km 10 it struggled to catch up for a few minutes and crashed.
I reopened the app (17:38:46) and continued recording without turning off the screen (it was dark by then).
Recording went on normally.
attaching log and GPX
2019-07-25_20-30-34.756_מסלול_2019-07-25.gpx.txt
log_2019-07-25_20-33-26.326Z.txt

[HarelM]

Beside the fact that I see that the app restarted at 17:38:46 everything else in the logs seems fine.
@valleyofdawn any chance you can follow this manual in order to collect the system logs using adb logcat?
https://support.citrix.com/article/CTX232375

[HarelM]

Latest solution attempt might suffer from this issue.
mauron85/cordova-plugin-background-geolocation#653

[HarelM]

Closing this for now as initial testing shows this is now fixed.
In case there's a need please re-open.