Why your app blocker stops working after a phone update

An app blocker that stops working after an update has had a setting reset underneath it: the battery allow-list, a runtime permission, or the accessibility connection. Beyond Alarm is built to catch all three — it re-checks them on every launch and flags a guard that has gone quiet.

The short version:

• Beyond Alarm re-checks its settings on every launch, re-arms a running block after updates and restarts, and warns you when the guard stops.
• A system update can put the phone's battery allow-list back to defaults.
• Android resets unused apps' runtime permissions, but not accessibility.
• An app update can drop the accessibility connection while the toggle still says on.
• The only real test is opening a blocked app on purpose.
• Toggling accessibility off and on again forces a fresh connection.

Somebody who searches this is usually staring at a phone that was doing its job until yesterday. The blocker's code rarely breaks on its own; what it sits on top of does.

It is almost never the app's own code

An app blocker on Android works by holding an accessibility service connection open — the same API screen readers use — watching which app just came to the front and covering it before it finishes loading. That code either works or it doesn't, and it doesn't degrade with time.

What does degrade with time is permission. Three things stand between "the service is installed" and "the service is actually running right now," and an update is exactly when any of them can get switched back off.

Three different things reset, and updates trigger all three

The first two are documented, dated mechanisms. The third is the one nobody names, and it's the one worth reading to the end for.

Android's own auto-reset is real, but narrower than people assume

Since Android 11, the system automatically resets an app's permissions if it goes unused for a few months — and it's worth being precise about what that actually covers, because the imprecise version of this claim is everywhere.

If your app targets Android 11 or higher and isn't used for a few months, the system protects user data by automatically resetting the sensitive runtime permissions that the user had granted your app... The system resets only runtime permissions, which are the permissions that display a runtime prompt to the user when requested. — Android Developers: Permissions updates in Android 11

Accessibility access is a special permission, granted in its own settings screen — not a runtime one — so this specific mechanism does not touch it. What it does reset, quietly, is Notifications, which became a runtime permission in Android 13. Lose that one and the blocker can be enforcing correctly while you stop seeing any sign that it's running at all.

The manufacturer's own layer resets its own list

This is the same family of setting that breaks alarms on Xiaomi, vivo and OPPO phones — autostart, background power, "don't optimise" — and app blocking needs the identical allow-list entry an alarm does, for the identical reason: both depend on a background component the manufacturer's battery manager is specifically built to kill.

The part that's harder to prove, because nobody at Google or Samsung documents it in public, is that a system update can put a phone's own allow-list back to its factory defaults — even for an app you'd already switched on. Search Samsung's own community forums for "accessibility keeps turning off" or "One UI update killing accessibility" and you'll find the same report repeated across phones and across years, right after a One UI version bump. It isn't rare, and it isn't one phone.

The fix is the one from the alarm post, repeated for whichever brand you're on: find autostart (Xiaomi), background power (vivo), "don't optimise" (OPPO/realme), or remove from sleeping apps (Samsung), and check it again after every update — not just once.

The quirk almost nobody names: the toggle can lie

Here's the one that's genuinely rare knowledge, and the reason this post exists rather than just linking back to the alarm one.

An accessibility service is a long-lived connection between your app and the system's accessibility manager. Replacing the APK — which is exactly what an app update is — kills that connection, and on several manufacturers the system does not reliably reopen it on its own. The toggle in Settings still reads "on," because the toggle only reflects whether you granted the permission, not whether the connection is currently live. The blocker looks enabled and isn't doing anything.

How we handle this in our app: Beyond Alarm's guard writes a heartbeat every second while a block runs. If a block is supposed to be active and that heartbeat has gone cold, the home screen treats the guard as stopped and says so, instead of trusting the toggle.

This is common enough that it has its own folk fix, repeated across Samsung's own support forums: turn the toggle off, then back on. That forces a fresh connection. It's not a setting you configure once — it's a step you may need to repeat after any update that touches the app, on some phones every single time.

Test it properly, not by looking at a toggle

Looking at the Accessibility switch proves the permission survived. It does not prove the service is running. The only real test:

1. Open a blocked app on purpose.
2. Confirm the shield actually appears — not just that the toggle is on.
3. If it doesn't, toggle accessibility off and back on, then repeat step 1.
4. If it still doesn't, go through the manufacturer table above — the allow-list reset is the more common cause of the two.

Do this the same day you install any system update, not the next time you happen to notice the block failed — by then you won't know how long it's been off.

The once-a-month checklist

• Open a blocked app on purpose and confirm the shield appears
• Re-check autostart / background power / "don't optimise" for your brand
• Confirm Notifications is still granted, especially after being unused a while
• After any accessibility toggle looks stuck: switch it off, then on

Why Beyond Alarm is the blocker to trust after an update

Every Android blocker sits on the same accessibility layer. What sets Beyond Alarm apart is that it watches that layer instead of assuming it:

• Its reliability screen re-reads battery optimisation, notifications and the guard each time the app opens.
• A running block is restored after an app update or a restart, so an update never quietly ends it.
• Phone Block's Strict mode has no stop button until the timer ends. Most blockers charge for their strictest mode; in Beyond Alarm a free user turns it on by watching one short ad, and Pro members get it without the ad.

See how it compares in our Android app-blocker guide, and how to cover set hours in scheduled app blocks on Android.

On iPhone, Beyond Alarm's blocking uses Apple's Screen Time rather than an accessibility service, so there is no Android-style connection to drop.

If what actually failed was the alarm itself rather than the block that follows it, the mechanism is a close cousin of this one — autostart is the usual cause there too, just with a different symptom.