Haven Docs

Tamper protection

Everything in this section exists to make one specific thing hard: dismantling the protection in the ninety seconds of a craving.

The design constraint is just as important as the goal. Haven raises friction; it never fights the operating system. No root, no hiding, no exploiting platform gaps, no disabling of Android's own controls. Every mechanism here is a documented API the user granted and can revoke. If a user genuinely wants Haven gone, they can always get there — it just is never one impulsive tap.

The settings lock (PIN)#

A PIN gates the actions that would weaken protection: starting a disable, changing the cooldown, and removing the lock itself.

  • The PIN is stored only as a salted PBKDF2 hash. The raw PIN is never written down.
  • Biometric unlock is optional and is an accelerator for the same gate, not a replacement. Removing the PIN removes biometric unlock with it.
  • Where the cooldown adds time friction, the lock adds access friction: only the PIN holder can even begin a disable. It is also the foundation for a partner who holds the code.

The PIN is mandatory while protection runs#

This is a deliberate exception to Haven's otherwise skippable setup.

Protection that is on but unlocked looks safe while it is not, which is worse than being honestly off — without a PIN, switching protection off is four taps and no pause, and the cooldown means nothing.

So the obligation is attached to the state "protected", not to one screen moment. On every app open, Haven re-checks whether protection is running without a PIN and, if so, raises a prompt that has no dismiss path. That closes the two ways around it that no single dialog can defend against: killing the app while the prompt is up, and enabling protection from a flow that never ran the setup steps.

Restart after reboot#

Turning the phone off and on must not silently disable the block. A boot receiver re-arms protection when the user had it enabled.

The VPN can only be restarted if consent was previously granted; Android requires a foreground consent dialog that a boot receiver cannot show, so if consent is missing Haven skips silently rather than pretending.

Self-healing on launch#

If protection is enabled but the tunnel is not actually running — after a reinstall, a process kill, a crash, or an aggressive battery optimiser — Haven restarts it silently on the next launch, consent permitting.

A gambling blocker must not stay quietly disabled.

Delete protection (device admin)#

Opt-in. While Haven is registered as an active device administrator, Android itself refuses to uninstall the app.

The important detail, and the one a reviewer should check first: Haven's device-admin policy file is deliberately empty.

xml
<!-- res/xml/device_admin_policies.xml -->
<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
    <uses-policies />
</device-admin>

No screen lock control, no wipe, no password rules, no camera control, no storage encryption control, nothing. Being an active admin is the entire feature. Haven asks for no administrator power at all beyond the platform's built-in consequence of that status.

Deactivating stays possible along two routes, and both are honest:

  • In the app — behind the PIN-gated Extra Guard screen, plus a confirmation.
  • In system settings — Android shows Haven's own warning first, and if the user proceeds anyway the weakening is recorded in the transparency log.

Both routes are logged. The in-app route also notifies a paired accountability partner. The settings route cannot compose an email from the background, so it is logged locally and shows up in the partner's next view of the history.

See Device admin for the permission detail.

Sticky protection service#

The protection service is declared sticky, so the system restarts it if the process is killed, and the ongoing notification stays visible the entire time protection is active. The user is never in a state where Haven is silently doing something they cannot see.

Escalation#

Repeated disable attempts lengthen the waiting period, and the interface says so. This is the only place in Haven where doing something more often makes it harder — everywhere else, repetition is treated as a neutral fact.

What tamper protection deliberately does not do#

Not doneWhy
Hide the app icon or disguise the appDeceiving the user is not protection
Block Android's Settings app, or the accessibility settings screenTrapping someone in an OS they cannot administer
Prevent Safe Mode, factory reset, or ADBFighting the platform, and futile
Take device-admin powers "just in case"Every power taken must be justified by a feature
Silently uninstall other appsThe user's tap in Android's own dialog, always
Re-enable itself after the user turned it offOnce the cooldown is honoured, the user's decision stands