If you fail, you owe money to the cause you hate most. So every screen-time bug in my app is a billing bug

Itai Hoffman — Tue, 06 Oct 2026 11:21:12 +0000

Go one minute over your Instagram limit and you owe $15 to the NRA. Or to Everytown. Or to whichever organisation makes your skin crawl. You picked it yourself when you set the goal.

That's Punish, an Android app I built alone. You set a goal ("Instagram under 30 minutes a day"), put money on it, and choose the organisation you'd hate to fund. Go over and you owe them. You pay it yourself through every.org; the app never touches the stake.

Which means I'm not allowed to get the number wrong. In a normal screen-time app, a number that's a bit off is a cosmetic bug. In mine, a number that's too high sends someone's money to people they despise, for time they never spent. A number that's too low turns the whole threat into a joke. So the native layer runs on one rule: when you can't tell, under-count, and when you can't measure at all, say so out loud.

The app is React Native + Expo. The measuring lives in two Kotlin modules. Here's where Android lied to me.

Android's own totals lie. Walk the events.

The obvious API is UsageStatsManager.queryAndAggregateUsageStats(), which hands you totalTimeInForeground per package. On my phone it read clearly higher than Digital Wellbeing, because an app left resumed behind a dark screen still counts as "in front". Ship that, and you're billing people for a phone lying face-down on a table.

So daily goals walk the raw stream from queryEvents() and track exactly one current activity. Simplified:

when (type) {
  UsageEvents.Event.ACTIVITY_RESUMED -> {
    close(ts)
    curPkg = pkg; curCls = event.className; curSince = ts
  }
  UsageEvents.Event.ACTIVITY_PAUSED ->
    if (pkg == curPkg && (event.className == null || event.className == curCls)) close(ts)
  // Arrives AFTER the next RESUMED. Acting on it ends the wrong session.
  UsageEvents.Event.ACTIVITY_STOPPED -> {}
  UsageEvents.Event.SCREEN_NON_INTERACTIVE,
  UsageEvents.Event.KEYGUARD_SHOWN -> close(ts)
  else -> {}
}

What bit me:

STOPPED lands after the next RESUMED. When the new activity was another instance of the same class (two windows of one browser), the old one's late STOPPED matched and closed the session that had just begun. Forty minutes counted as a third of a second. Only PAUSED closes a session now.
Sessions that started before the window. If an app was open at midnight, its first event in the new day is a PAUSED with no RESUMED. Ignore that and every session crossing the day boundary loses its head.
The phone dying. A battery cut sends no PAUSED and no screen-off, so the app in front "runs" until the phone boots again. That's ten hours of Instagram for a night the phone was dead, and somebody's money on its way to their least favourite cause. On Android 10 and later the stream logs DEVICE_SHUTDOWN and DEVICE_STARTUP (event types 26 and 27). At a startup, the open session ends at the last event seen before it. It under-counts the downtime and never bills it.
No permission is an empty stream, not an error. Without usage access, queryEvents() quietly returns nothing, which my code read as zero minutes: a perfect day. The module now checks the app op first and throws ERR_NO_USAGE_ACCESS, so "can't read" can never look like "didn't use". (Also: unsafeCheckOpNoThrow is API 29. On Android 7 to 9 you need the deprecated checkOpNoThrow.)

The event stream only goes back about a week. For a 28-day baseline I use queryUsageStats(INTERVAL_BEST, from, to), which reads Android's rolled-up buckets. Two catches. Android widens the range to whole buckets, so divide by the span the buckets really cover (firstTimeStamp to lastTimeStamp), not the 28 days you asked for. And the buckets carry the same screen-off inflation, so I scale them by how the event walk compares with the aggregate over the last week. Only ever down.

One more: the home screen. Samsung's One UI Home declares a HOME activity and no LAUNCHER one, so it's missing from any launchable-apps list, and whole-phone totals left it out: 13 minutes and 214 visits in one day on my phone. I resolve the active default with resolveActivity() on CATEGORY_HOME, not a query for every HOME activity, because that query also returns Settings.

Websites: read the address bar, and nothing else

UsageStatsManager knows packages and nothing finer. An hour of Wikipedia and an hour of Reddit are both "Chrome". The only option for a normal app is an AccessibilityService that reads the browser's address bar.

Mine doesn't block anything and performs no accessibility actions. It watches and times, and at set moments puts its own message on screen, which you can always continue past.

Which apps are browsers: whatever answers an ACTION_VIEW for an http link, from the package manager, cached for ten minutes, plus a seed list in case Android 11 package visibility filters the query. A hardcoded list breaks the day someone installs a second browser, which is the cheapest bypass there is.
The bar: Chromium forks keep the resource id url_bar, so one findAccessibilityNodeInfosByViewId() covers Chrome, Edge, Brave, Opera and Vivaldi. Firefox and Samsung Internet get their own ids. Unknown browsers fall back to a bounded walk (depth 12, 400 nodes) that looks only at editable or address-like fields, never page text.
Bar text is not a URL. It can be a search, a page title or placeholder text. Anything with a space is a search, so "how to block reddit.com" isn't a visit. Google Translate's proxy, reddit-com.translate.goog, is unwrapped back to reddit.com, because that's the bypass people actually reach for when there's money on the line.
Throttle content events. Reading the bar is a synchronous trip into the browser's process. With Chrome in front, the handler averaged 1.7 to 4.9 ms an event, spiking to 136 ms, at seven to nine events a second while a page renders. A navigation always brings a window-state change, so content events now get one read a second. The average dropped under a millisecond.
Screen-off isn't an accessibility event. Without an ACTION_SCREEN_OFF receiver, a tab left open at night kept counting until the next morning.

The watcher will die. Write down when it was alive.

Vendors and battery optimisation kill accessibility services. After an app update, Settings can still show the service as enabled while dumpsys accessibility shows it isn't bound. A dead watcher reports zero browsing, which looks exactly like a perfect day. Great for the user's wallet, fatal for the product.

So the service keeps coverage windows: opened when it connects, kept alive by a heartbeat on each event, closed when it unbinds. A website goal's day the watcher missed more than 5% of is treated as unmeasured, never as kept.

Decide which way you're allowed to be wrong

Before writing any of this, pick your failure direction. Mine: under-count rather than over-count, and "unknown" rather than zero. Most of the code above is that one sentence applied to one edge case at a time.

Punish is in closed beta on Android, iPhone in progress: punishapp.com.

If you've fought UsageStatsManager on other OEMs, tell me what broke. And tell me which organisation you'd hate to fund. I'm collecting.

DEV Community: Itai Hoffman

If you fail, you owe money to the cause you hate most. So every screen-time bug in my app is a billing bug

Android's own totals lie. Walk the events.

Websites: read the address bar, and nothing else

The watcher will die. Write down when it was alive.

Decide which way you're allowed to be wrong