Summary
I'd like AppLock to be able to relax protection in a trusted context — specifically when connected to my home Wi-Fi — and re-enable it automatically everywhere else.
I notice "Scheduled protection periods" is already on the roadmap in the v1.0 release notes. This request is the same idea with a different condition: instead of when, it's where.
Use case
I live somewhere with a high street-robbery rate. Locking social and messaging apps matters a lot when I'm out, and matters very little at home. Right now it's all-or-nothing: either I authenticate dozens of times a day in my own house, or I turn protection off and forget to turn it back on before leaving — which is exactly when I need it.
A trusted-network condition would make the protection something I never have to think about, which is the difference between a feature people keep enabled and one they disable out of friction.
Option A — built-in trusted networks
A settings screen where I can add one or more SSIDs. While connected to any of them, protected apps open without authentication. Any other network, or no network, and normal protection applies.
Fail-closed matters here: unknown state should mean protected, never unprotected. Same for the moments after boot, before Wi-Fi has connected.
This could sit naturally alongside the planned scheduled periods as a general "conditions" section.
Option B — exported intents (probably much cheaper to implement)
If built-in conditions are out of scope, exporting two intents would let automation apps handle it:
dev.pranav.applock.action.ENABLE_PROTECTION
dev.pranav.applock.action.DISABLE_PROTECTION
Two notes on design, from having tried to automate another locker that only exposed a toggle:
- Please make them setters, not a toggle. A toggle forces the automation app to track state it can't read, and that state inevitably drifts out of sync. Explicit enable/disable is idempotent and cannot desync.
- A way to read current state would help — a broadcast on change, or a content provider — so automation can verify rather than assume.
If exposing these unguarded is a security concern, gating them behind a permission the user grants explicitly, or a token set in AppLock's own settings, would still be far better than nothing.
Why this is worth considering
As far as I can tell, no third-party app locker on Android offers location-conditional protection. The only implementations are Samsung's Secure Folder and Identity Check, which are vendor-locked. There's a real gap here, and AppLock is well placed to fill it.
Happy to test builds. Thanks for the app and for keeping it open source.
Summary
I'd like AppLock to be able to relax protection in a trusted context — specifically when connected to my home Wi-Fi — and re-enable it automatically everywhere else.
I notice "Scheduled protection periods" is already on the roadmap in the v1.0 release notes. This request is the same idea with a different condition: instead of when, it's where.
Use case
I live somewhere with a high street-robbery rate. Locking social and messaging apps matters a lot when I'm out, and matters very little at home. Right now it's all-or-nothing: either I authenticate dozens of times a day in my own house, or I turn protection off and forget to turn it back on before leaving — which is exactly when I need it.
A trusted-network condition would make the protection something I never have to think about, which is the difference between a feature people keep enabled and one they disable out of friction.
Option A — built-in trusted networks
A settings screen where I can add one or more SSIDs. While connected to any of them, protected apps open without authentication. Any other network, or no network, and normal protection applies.
Fail-closed matters here: unknown state should mean protected, never unprotected. Same for the moments after boot, before Wi-Fi has connected.
This could sit naturally alongside the planned scheduled periods as a general "conditions" section.
Option B — exported intents (probably much cheaper to implement)
If built-in conditions are out of scope, exporting two intents would let automation apps handle it:
Two notes on design, from having tried to automate another locker that only exposed a toggle:
If exposing these unguarded is a security concern, gating them behind a permission the user grants explicitly, or a token set in AppLock's own settings, would still be far better than nothing.
Why this is worth considering
As far as I can tell, no third-party app locker on Android offers location-conditional protection. The only implementations are Samsung's Secure Folder and Identity Check, which are vendor-locked. There's a real gap here, and AppLock is well placed to fill it.
Happy to test builds. Thanks for the app and for keeping it open source.