Since Android v8.0 (Oreo), the Clock app’s timer feature is unreliable. Essentially, the alarm clock or countdown timer can become corrupted and simply fail to notify. You would think that the Clock should be one of the most basic and reliable features. A Reddit post has many examples of users’ frustration; Google claims to have fixed it in v5.2, but several users continue to report problems. My Clock app is v7.0, and I have been frustrated enough to find out the problem’s prevalence and write about it. But computationally, I think the problem points to the complexity of system timers that even Google faced since version 5, not just beta or version 1.

I say system timers as distinct from the Clock’s alarm clock or countdown timer. The app may implement its timers differently than using system timers. If so, skip this paragraph. From the documentation I have read, system timers never notify early and may even be late; if that has changed, point me to updated documentation. So using system timers is already fraught with trickiness to handle them carefully. System timers are unreliable in the background, but they work fine in the foreground and for time-flexible tasks. For example, I believe Pokemon GO’s location update operates on a 30-second timer and fits the criteria. I am guessing and hoping that Clock does not use system timers.

Why would timers be more problematic in the background? Based on experience and intuition, I believe there are at least two factors. In the background, timers are updated when Android wakes up, roughly speaking. Before Android wakes up, low memory situations may cause the kernel to clean up memory, corrupting timers in the process. Besides low memory, I think the kernel’s interactions with timers are simply not robust. Without any real time guarantees to reason about, timers are left as concurrency debugging nightmares. Debugging concurrent threads is one of the hardest tasks and perhaps why timers have few semantic guarantees. Please tell me the technology has improved.