An app blocker that can't be bypassed on Android: what "can't" really means

If you are searching for an Android app blocker that cannot be bypassed, the honest answer is that it does not exist, and any app promising otherwise is describing its own lock screen rather than your phone. Every blocker on Android, including Lock, the one I build, runs as an ordinary app with permissions you granted and can revoke. Settings is always one swipe away, safe mode disables third party apps entirely, and uninstalling works like it does for any other app. What varies between blockers is not whether the block can be broken. It is how many seconds and how much deliberate effort breaking it takes, and whether your thumb can do it without you really noticing.

What the marketing sentence actually claims

Lock’s own feature list says “impossible to bypass: no hidden button, no cheating, the tag is the only key”. I wrote that, and I still think it is accurate, but its scope is narrow. It is a claim about Lock’s lock screen: no snooze, no “just five more minutes”, no exit control anywhere in the app while a session runs. It is not a claim about Android. The operating system sits underneath every blocker and will always let you take back a permission you gave.

The distinction matters because the two fail differently. An in-app exit button gets used dozens of times a week: it is there in the exact second your resolve dips, while you are already holding the phone. A trip through Settings to revoke an Accessibility permission gets used rarely, because by the time you find the right submenu you have stopped being on autopilot. Same outcome, completely different frequency.

I am not alone in saying this. Habit Doom, a competing blocker, publishes the same conclusion about Android, and about its own app. AppBlock maintains a public page listing what it cannot block: floating and pop-up windows, the duplicate created by dual-app features, and on some devices parts of Settings even with its strict mode on. The vendors who are specific about their limits are the ones worth trusting.

Every exit route, and what it costs

Here is the inventory, ranked by how cheap it is. “Cost” means what actually predicts whether you will use it: time, deliberate steps, and whether you have to put the phone down.

Exit route	Roughly what it takes	Does it feel like a decision?
In-app snooze or break button, where one exists	One tap, no leaving the app	No
Revoke the overlay or Accessibility permission in Settings	Under a minute, several menus	Barely
Uninstall the blocker	Under a minute	Barely
Reboot into safe mode	A reboot, plus a long press on the shutdown dialog	Yes
Use the mobile website instead of the app	Seconds, if the site is usable	No
A second user profile or work profile	Minutes of setup, once	Yes, the first time
Factory reset	Half an hour and your data	Very much yes

Two deserve a note. Safe mode is a diagnostic boot state that loads only system software, so as AppBlock’s own support page puts it, in safe mode “all third-party apps, including AppBlock, are disabled” and “blocking will not work while Safe Mode is active”. That is true of Lock too. No permission a normal app can hold survives it.

The browser route is the one people forget when picking which apps to block. Blocking the Instagram app does nothing about instagram.com in Chrome. If that is your pattern, you want a browser-level block as well.

I cannot build a wall on Android, and I have stopped trying. I can put the key in another room, and that turns out to be most of the benefit.

The change nobody targeting this question has written about yet

Here is the part that is new, and that will matter more over the next year than any of the routes above.

Almost every app blocker on Android works through the Accessibility Service API, because it is the only way the system tells an app that another app just came to the foreground. Google has been narrowing that API for years. Its Play policy reserves the isAccessibilityTool flag for services “designed to help people with disabilities access their device”, and explicitly names automation tools, monitoring apps, launchers, cleaners and password managers as apps that do not qualify. Blockers do not qualify either. Apps that use the API without that flag have to show a prominent in-app disclosure and get affirmative consent, which is why Lock explains the permission on screen before asking for it, and why that explanation also appears in the privacy policy.

In Android 17, that narrowing acquires teeth. Android Authority tested Beta 2 and found that with Advanced Protection Mode turned on, the system “prevents apps that aren’t officially classified as accessibility tools from receiving accessibility permissions”. If such an app already holds the permission, “the system automatically revokes it”, and you cannot grant it again while the mode is on. The only workaround they found was switching Advanced Protection off. Advanced Protection is opt-in, a single toggle in Settings, and it exists for good reason: the Accessibility API is also what Android malware abuses.

Blockers are already feeling it. AppBlock has published a page about exactly this, saying the feature “can restrict or disable Accessibility access for apps” and that “at the moment, Android does not provide us with another way to ensure the same level of reliable blocking”. I have no better answer. If you turn Advanced Protection on, Lock stops being able to block, and the fix is a system setting I do not control.

So there is now a one toggle, documented way to disable every Accessibility based blocker on a modern Android phone. Treat any article claiming an unbypassable Android blocker as out of date.

Why I think this is fine

Being unbreakable was never the mechanism. A study I went through in the Focus mode piece compared the same daily limit at three strengths and found the effect more than doubled as the exit got more expensive, while people’s stated preference moved the opposite way. Cost of exit is the variable. Impossibility is the far end of a scale, and not where most people want to live.

Which is why Lock has deliberate exits of its own, and I would rather list them than let you discover them: a grace period of up to two minutes to cancel a block you started by accident, a configurable number of emergency unlocks lasting 2, 5 or 10 minutes that regenerate with every new session, a session timeout of 2 to 8 hours so a lost tag does not strand you, and uninstall, always. You can set the session length to unlimited, and the app warns you plainly that uninstalling then becomes the only way out.

None of those is reachable from the app you are trying to avoid. That is the entire design target: expensive enough that it is not a habit, cheap enough that you are never trapped. A blocker you cannot escape is a blocker you will delete in week two, which I have written about from my own side of it.

What to do this week

Stop looking for the unbypassable one. Instead:

1. Work out which exit you personally use. If it is a snooze button, you need a blocker without one. If it is Settings, no app will save you and you should raise the cost another way, such as leaving the phone in another room. Willpower isn’t a feature covers the reasoning.
2. Check whether Advanced Protection is on, in Settings, under Security and privacy. If it is, decide which you want more: the security hardening or a working blocker. That is a real tradeoff now, not a bug to report.
3. Block the browser too, or at least the specific sites, if your pattern survives an app block.
4. Pick on honesty, not on the word “impossible”. Any blocker with a public page about its own limits beats one without. If you are weighing hardware, I compared the NFC options and their prices, and the setup guide covers the five euro version.

If you want to know where Lock’s limits sit on your phone, my email is on the support page. I answer those myself, and I would rather tell you something cannot be done than have you find out in week three.