As I said before, this extension has nothing to do with a → Background service, it is all about a → Foreground service in order to prevent → Doze mode from becoming active.
Note: And a Background service has no effect on Doze mode.
1 Like
Thank you soon much for the extension.
It works perfectly on my phone. My app is running in background and triggering the timer perfectly.
Thank you soo much again.
1 Like
Hi Anke,
How we can solve this problem.
I'm trying to write an application with a time counter.
The app sleeps after a while even when charging 
1 Like
Show your blocks.
And did you enable TimerAlwaysFires?
1 Like
Yes Anke,
But 1 or 2 min. is sleeping applicaiton.
1 Like
And even when i add it to "never go to sleep" section from andorid settings the app is still sleeping!...
1 Like
What is your goal? Do you only want to keep the screen on?
Or do you claim that the timer does not work in idle (sleep) mode even when the device is charging?
1 Like
My aim is this;
I want the application I wrote to continue to run in the background.
The user ran the application.
The seconds began to increase. It also started increasing by +1 on a counter.
User switched to Instagram. Or turned off the screen, the screen is now black.
I want the application to keep counting the seconds, the counter to keep moving.
I wonder if I could explain
1 Like
Ok, the reason why the timer stops in background / idle / sleep mode is that Doze mode strikes and shuts down / throttles all possible functions (CPU, WiFi, timers, internet connection / LTE etc). But that shouldn't happen while the device is charging. I've checked this on dozen of devices running all versions of Android (for years).
In order for it to work without charging, a Foreground service is definitely required. Search hereafter in the forum and you will find my answers / solution (AI2, Kodular, ...).
Last here:
1 Like
Hi Anke,
I am a Sansung Galaxy A50 and Android 11 version user.
The timer stops while the phone is charging, it definitely lags behind.
At the same time I am running a stopwatch on another device.
There is a very obvious difference between them.
1 Like
What duration are we talking about? 5 min?
It is well known that the Clock component is not accurate. It is always something lagging behind, which is clearly noticeable over a long period of time compared to a chronometer. On average (device-dependent) the timer loses around 1 second per minute.
1 Like
Definitely in a 20 minute experiment, 5-10 min. lags behind. After the first 1-2 minutes, my application stops (sleeping). It doesn't work until I call it back to the screen. I don't care about milliseconds anyway. It's enough for me to be the same for about seconds. do you understand? For example, I am making a taximeter. I am making a bike rental application.
1 Like
Ok, I'll check this again on my 16 test devices (Android 4.x, 5.x, 7, 8.x, 9, 10, 11).
Maybe something has changed in the meantime ...
1 Like
Thank you so much.
1 Like
Try this app. It shouldn't lose a single millisecond, even not when the screen (the app) is in the background or in idle (sleep) mode (also not, if the app is running for many hours):
Compare it to a chronometer.
1 Like
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.