A screen-time app is a chain of Android components, and it only works when every link holds. The accessibility service has to be enabled, the protected app has to be in the list, the plan has to cover it, and the system has to let the service run. Break any one of those and the result looks identical: you open the app and nothing happens.
This is the order worth checking, from the most common cause to the least.
How is a pause supposed to work?
ScrollBreak runs an accessibility service that listens for one event type: TYPE_WINDOW_STATE_CHANGED. When the foreground package changes, the service compares it with your protected list. If it matches, it opens the challenge screen. It does not read screen content, and it does not declare broad package visibility — the app list comes from a narrow query for apps with a launcher activity.
That design is also why the failure modes are about permissions and process lifetime rather than about the timer. The timer is the easy part.
1. Is the accessibility service still on?
This is the cause more often than everything else combined. Open Settings → Accessibility → ScrollBreak and check the toggle. If it is off, turn it on and test immediately.
Three things turn it off without asking:
- Force-stopping the app. Android clears the enabled accessibility service when an app is force-stopped. That includes the “Force stop” button in App info and many OEM “cleaner” tools.
- Reinstalling. A reinstall can leave the service disabled even though the app is installed.
- An OEM update or a security sweep. Some ROMs reset accessibility grants after a major update.
On Android 13 and later, a sideloaded APK has a second gate: the accessibility toggle is greyed out and the system says the setting is restricted. Open App info → ⋮ → Allow restricted settings, then enable accessibility. Apps installed from Google Play do not usually hit this.
2. Is the app actually protected, and does your plan cover it?
Open ScrollBreak and look at the protected list. The free plan enforces two apps. If you have added a third, it can sit in the picker looking selected while nothing enforces it.
There is a second, subtler version of this: the optional rewarded video grants one extra app for 24 hours, and the grant expires. An app that was protected yesterday can stop being protected today without any setting changing.
If the pause works for one app and not another, this is the first place to look.
3. Has an OEM battery or autostart manager killed it?
Android’s background restrictions are only half the story. Samsung, Xiaomi, Oppo, Vivo, Realme and several others add their own battery and autostart managers, and they are much more aggressive than stock Android.
ScrollBreak offers an optional battery-optimisation exemption, which opens the system list where you can mark it as unrestricted. It does not request the exemption automatically, and it cannot change OEM autostart settings for you. On Xiaomi, look for Autostart in App info; on Oppo and Realme, Allow background activity; on Samsung, Battery → Unrestricted.
The symptom is distinctive: pauses work while you are using the phone and stop after it has been idle, or stop after a reboot. That is a process-lifetime problem, not a detection problem.
4. Did Android restart the service after a reboot?
ScrollBreak has no boot-completed receiver of its own. After a restart it relies on Android re-binding an enabled accessibility service, which usually works and occasionally does not, especially on OEM builds with their own startup managers.
If pauses stop after a reboot and the accessibility toggle still looks on, toggle it off and on. That forces a fresh bind. If the toggle is off, that is cause one.
5. Is a reward or an ad suppressing the pause?
Two deliberate exceptions can make the app look broken:
- A visible ad is never interrupted. If an ad is on screen, the challenge is held back rather than covering it.
- A rewarded 24-hour unlock suppresses the pause for the app it was granted to. That is what the grant is for, and it expires on its own.
Neither is a bug, but both look like one if you forgot the grant.
6. Is an overlay covering the app?
The service ignores transient windows: keyboards, the notification shade, Quick Settings, permission dialogs, and about seventy-five named system and OEM overlay packages, plus pattern matching for panels and floating assistants. It also gives the launcher an 800 ms grace period so the trailing launcher animation after an app opens is not treated as a new session.
The practical effect is a pause that arrives late rather than not at all. If you open a protected app, pull down the shade, and leave it open, the challenge waits until the shade closes. Close the overlay and the pause appears.
What about Usage Access?
Usage Access is presented prominently during setup, and it is easy to assume it is what detects a protected app. It is not. Detection is the accessibility service’s job.
Usage Access feeds the dashboard, the hourly chart, per-app totals and the “today’s minutes” toast that appears before a pause. Turning it off will not stop blocking — it will stop the numbers. That distinction is worth knowing before you spend twenty minutes re-granting the wrong permission.
A five-minute test
- Pick one app you can open easily and confirm it is in the protected list.
- Set the interval to one minute — the shortest option.
- Open the app and wait, without touching the screen.
- If nothing happens, go back and check the accessibility toggle before changing anything else.
If the challenge appears at one minute but not at five, the mechanism works and the setting is the explanation. If it never appears, the link that is broken is in the list above, in that order.
One last detail: consecutive solves inside the same blocked app halve the limit each time, down to one minute, for up to four escalations. A pause that seems to arrive faster and faster is the design working, not the timer drifting.
If you are still choosing between approaches — a pause, a hard block, or a breathing delay — the screen time app comparison explains what each one does at the limit. And if the question is really about how much you use an app rather than how to interrupt it, how to see which apps you use most on Android starts with the numbers Android already keeps.