Does the timer keep running when you lock your phone?

Published on August 29, 2026

Tags:technicalandroidhow-it-works

An owl with ear tufts perches on a wooden post in calm water next to a melting pocket watch, with forested islands on the horizon at dusk

You start a timer, lock the phone, put it in a pocket. Twenty minutes later you take it out.

Is the number right?

It is a reasonable thing to be unsure about, because a modern phone is actively working against you. Its operating system treats a backgrounded app as a battery problem to be solved — freeze it, stop its timers, and eventually kill it outright. Anything that wants to survive that has to be built for it deliberately.

This post is about how TiCaNo Stopwatch handles it, and about the trade-off underneath, which is more interesting than the feature list. The short answer: yes, and the reason it works is also the reason for its one real weakness.

Two ways to build a stopwatch

There are broadly two designs, and the choice between them decides everything else.

Cutaway engraving of a tower clock, showing the gear train, escapement, driving weights and pendulum.
A tower clock movement: the tick-counting design made physical. Stop the train and the count stops with it. Engraving, Wikimedia Commons, public domain.

Count ticks. Start a monotonic counter — a number that only ever increases, immune to anything happening to the clock — and read it when you stop. This is the textbook answer, and it is precise. Its weakness is not the clock but the bookkeeping. The running total lives in memory, and if the operating system freezes or kills the process, the total goes with it. A careful implementation can work around that by storing the counter’s reading at the start and subtracting later — but these counters measure time since the device booted, so a restart resets the thing you were counting from. The design survives being killed. It does not survive being rebooted.

Note the time and subtract. Record when the timer started, then whenever you need a reading, take the current time and subtract. Nothing needs to run in between. The elapsed time is a calculation, not a measurement in progress.

TiCaNo uses the second. Every value on screen is now minus start — recomputed from scratch, many times a second while you watch, and once more the moment you come back to it.

Two stopwatch designs across the same interval. Counting ticks keeps the total inside the running process, so when the operating system kills it the count is lost. Noting the start time stores only the moment the timer began, so elapsed is recalculated as now minus start and stays correct across the gap.
Why the choice matters: one design has to survive the gap, the other only has to remember when it began.

That is the whole trick, and it has an unobvious consequence: the app does not need to be running for time to pass correctly. It only needs to know when you started. The phone can freeze the app, put it to sleep, or kill it entirely, and the arithmetic still works when it returns.

What actually happens when the screen locks

On Android, a foreground service starts whenever the stopwatch does. It is the mechanism that tells the system this app is doing something the user asked for, and it is why the process is not suspended when the screen goes dark. It is also the reason there is a notification — that is not a marketing choice, it is the price Android charges for staying alive, and it is deliberately silent and non-dismissible while you are timing.

Switch to another app and the same thing happens: the timer keeps running, and the notification starts updating once per second so you can see the count without switching back. That notification is explicitly marked visible on the lock screen, so a glance at a dark phone shows the running time; and if the stopwatch was the thing on screen when you locked the phone, the app is allowed to display over the lock screen rather than sit hidden behind it.

There is one limit on the Android guarantee worth stating, because it is a hard number rather than a caveat. The kind of foreground service the app uses is capped by Android at six hours of background running in any 24-hour period on devices running Android 15 and later. Bringing the app back to the foreground resets the clock on that allowance, so it is not a limit anyone timing a run, a workout or a bake will meet. An unattended session left in a pocket for a working day is a different matter — and when the cap is reached, the service stops being a foreground service. The elapsed total still recovers, for the reason the next section explains. The live notification does not.

On iOS there is no equivalent background service, and this post should not pretend otherwise. There is no persistent background notification. What you still get is the arithmetic: iOS may suspend the app, but the start time is recorded, so when you return the elapsed figure is correct for the whole interval, including the part where nothing was running.

That is a weaker guarantee than Android’s, and it is a real difference rather than a rounding error. It is worth knowing which one you are relying on.

What if the app is killed outright?

This is where the design earns its keep.

The running state — the start time, the accumulated total, your laps — is written to storage when you start, on every pause and lap, and every thirty seconds in between. If the system kills the app while it is timing, relaunching restores it. Because elapsed time is recomputed from the stored start time, the resumed display includes the entire period the app was dead. You do not lose the gap; you were never really counting through it in the first place.

What survives an unexpected shutdown. State is written on start, on every lap and pause, and every thirty seconds in between. The total elapsed time always recovers because it is recalculated from the stored start time; only laps recorded since the most recent save can be lost.
The total is derived, so it always comes back. The most recent detail is stored, so it can be missed.

Two honest limits on that.

A hard kill can cost you the newest laps. The running total always recovers, because it derives from the start time. But laps recorded in the up-to-thirty-second window since the last save can be lost. The total is safe; the most recent detail might not be.

It is not reboot-proof. Nothing restarts the timing stack automatically after the device restarts. The state is still on disk and resumes when you next open the app — but a phone that reboots mid-session will not be quietly counting in the background while it comes back up.

The cost of the design

Every engineering choice buys something and pays for something, and this one pays here:

If the device’s clock moves, the stopwatch moves with it.

Because elapsed time is the difference between two wall-clock instants, changing the clock while a timer runs shifts the reading by exactly that amount, immediately. Set the clock forward ten minutes and ten minutes appear. A network time correction that steps the clock does the same thing. A gradual correction — the phone slewing a slightly-wrong clock back into line during your session — distorts the rate rather than just the offset.

Two scientists at the US National Bureau of Standards in the 1950s working on an early caesium beam atomic clock, one pouring liquid nitrogen over a cold trap.
An early caesium clock at the US National Bureau of Standards. Your phone’s own oscillator is what drifts; instruments like this one are the standard it eventually gets corrected against. Photo: NIST, Wikimedia Commons, public domain.

In normal use this rarely comes up: phones keep good time, and the corrections are small. But it is the genuine trade-off, and it deserves stating plainly rather than being left in the small print: a tick-counting design would be immune to it, and would in exchange lose your session every time the operating system decided to reclaim some memory.

We would rather be wrong by a rare clock correction than lose an hour of timing to a routine app kill. That is a judgement about which failure is worse, not a claim that one design is universally better.

Time zones are a separate matter and a happier one: durations are computed on absolute time, so crossing a zone or passing through a daylight-saving change does not alter an elapsed reading. It can change how a timestamp is labelled, but the length of the thing you measured stays the length of the thing you measured.

So: should you trust it in your pocket?

For the things people actually time — a run, a set, a rest interval, a batch in the oven, a meeting — the answer is yes. Lock the screen, switch apps, let the phone do what it likes with memory. The number will be right when you look, and on Android you can watch it without unlocking for as long as the six-hour background allowance lasts.

The honest boundary is worth keeping in view, and it is not really about phones at all. Your thumb is still on the button at both ends, and that is worth about two hundred milliseconds — considerably more than any error the background behaviour is likely to introduce. A phone stopwatch is an excellent instrument for human events. For anything where the last hundredth genuinely decides the outcome, the finish line needs a camera, not a pocket.

There is also a “Keep Screen On” setting, off by default, for when you want the display to stay awake and are willing to spend the battery. It changes what you can see. It does not change what is being measured — and that distinction is the whole point of how this is built.

Sources

← Back to all posts