Focus Timer: The Session Ended and Nobody Was Told

Two things in this release. One is a feature people asked for. The other is a bug that had been quietly costing users their sessions, and it is the more interesting of the two.

Notifications became a permission and we did not notice

Android 13 made posting notifications a runtime permission. Before that, an app could notify freely. After it, POST_NOTIFICATIONS has to be requested and granted, exactly like the camera or location.

Here is the part that caused the damage: if it is not granted, notify() does not fail. There is no exception and no error return. The notification is dropped by the system. From inside the app, posting a notification that nobody will ever see looks identical to posting one that works.

For most apps that is a degraded experience. For a timer, the notification *is* the product. A focus session's entire output is the moment it tells you the block is over. Users who declined the permission — or who never saw the prompt because of how our request was sequenced — had a working timer that finished silently. They would look up twenty minutes late and find a session that had ended and said nothing.

Worse, the ongoing session notification was also dropped, which meant the way we intended people to check their remaining time was invisible too. From the user's side the app appeared to do nothing at all after you pressed start.

What we changed:

We ask at the point it matters. Not on first launch, buried among other setup, where a permission dialog is a thing to dismiss. The request comes when you start your first session, with a sentence explaining that this is how the app will tell you the session ended. Context in the moment converts far better than a wall of prompts at install, and more importantly it is honest — you are being asked because the thing you just did needs it.

We check state before every session. areNotificationsEnabled() is checked at start. If notifications are off, the app says so before the session begins rather than after it fails, and offers the settings path. A user can decline and start anyway; they just do so knowing.

We check the channel, not only the app. A user can leave notifications enabled globally and disable a specific channel, or set it to a low importance that suppresses any alert. Querying the channel's importance catches the case where everything looks granted and nothing will be seen.

Session end no longer depends only on a notification. If the app is in the foreground when a session ends, it shows the completion directly rather than posting and hoping.

The lesson is the same one we keep relearning: when a platform turns something into a permission, the failure mode is usually silence, and silence is indistinguishable from success unless you go looking.

The stopwatch, and why a countdown was not enough

The feature half of the release.

A countdown is a commitment made in advance. You decide the block is twenty-five minutes and then the app holds you to it. That is genuinely useful for work that benefits from a boundary — study blocks, drafting, clearing a backlog, anything where the hard part is stopping or the hard part is starting.

It is the wrong instrument for a large category of work, and we had been quietly telling people to use it anyway.

Reading until the chapter ends. Cleaning until the room is usable. Debugging something that will take as long as it takes. A recurring admin task you have been estimating badly for months. In all of these the question is not "how long should this take" — that is a guess, and guesses are what got you here — but "how long does this actually take."

A countdown answers the first question by assuming it. A stopwatch answers the second by measuring.

The interesting result, and the reason we think this is worth more than a checkbox in a feature list: people who time a recurring task usually find it takes a different amount of time than they believed, and often the surprise is in the shape rather than the total. The task itself is fine and the setup takes half the session. Or the first ten minutes are re-reading where you left off, every single time.

Neither of those is visible from a countdown, because a countdown does not tell you anything you did not already assert.

Sharing one session record

Under the surface both modes produce the same thing: a session with a task name, a start, an end, and how it terminated. A countdown session additionally has an intended duration. A stopwatch session does not.

Keeping one record type rather than two matters more than it sounds. It means the history is a single list rather than two parallel ones, and it means the app never has to ask you which kind of thing you are looking for. It also means the stopwatch inherits everything the timer already had: state persisted as anchors rather than counters, survival across process death, explicit abandoned and expired states, and a monotonic clock that keeps running while the phone sleeps.

The one thing the stopwatch cannot inherit is the completion alarm, because there is nothing to schedule — it ends when you say it ends. That makes it the simpler mode by a wide margin, which is a good sign about the underlying design.

Which to reach for

Countdown when the boundary is the point. You know roughly how long, or you have decided how long, and the value is in not renegotiating it while you work.

Stopwatch when the duration is the question. You are curious, or your estimates have been wrong, or the task has a natural end that is not a clock time.

The mistake we see most is using a countdown for work that has a natural boundary — reading to the end of something, finishing a specific fix — where the timer either interrupts you mid-flow or leaves you sitting there having finished. The other mistake is using a stopwatch when you actually needed a break to arrive, and working for two hours because nothing told you to stop.

Both are cheap to correct once you have noticed. Neither is worth a productivity system.

What we did not add

No streaks, no scores, no completion percentages, no goals. The record shows what happened. If a stopwatch session tells you a task took ninety minutes, the useful response is to plan ninety minutes next time, and that is a decision for you rather than a number for the app to grade.