And even if the app is running in the foreground, I get these deviations from the → Clock component (red time) after only 6 and 10 min:
1 Like
Maybe you can avoid the problem by storing the SystemTime of your last critical event and refer to it when you wake up to get running time by subtraction, like in this sample project?
1 Like
That is exactly the critical point.
How can the app pick up this point in time when the timer is no longer active (means that it has been shut off by Doze mode)?
As already said:
So there is no other option but to use a foreground service that prevents Doze mode (if the app is in idle / sleep mode).
(Of course, the time / duration can be queried if you manually bring the device back to the foreground.)
Record the Clock1.SystemTime of when the bike rental starts.
That's all you need.
Total Time Rented will always be Bike Returned Clock1.SystemTime minus bike rental start SystemTime,
converted from ms to whatever scale (minutes, hours,...) you want.
That's of course no problem (that's just a simple calculation of the duration between two dates).
But, if the app should give a warning / alarm at the time of the end of the bike rental, this does not work in idle mode (because of → Doze → the timer is no longer in action).
So again: You need to use a Foreground service to prevent Doze.