Device admin

Haven's optional delete protection uses Android's device-administration API. This is the most powerful-sounding thing in the app and the one that deserves the most precision, so here is the whole of it.

Haven requests zero device-admin policies#

That is not a summary. It is literally the contents of the policy file:

xml

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

The element is empty. Haven takes no administrative power over the device:

Policy Haven does not request
Force lock / lock the screen
Wipe the device or the work profile
Set or reset the password
Set password quality, length, expiry or history rules
Limit failed password attempts
Disable the camera
Disable keyguard features
Set global proxies
Require storage encryption
Watch login attempts

Haven has no access to the user's data, screen, camera or password through this API, and cannot lock, wipe or reset anything.

So what does it actually do?#

Being an active administrator is the entire feature.

Android refuses to uninstall an app while it is an active device administrator. That platform behaviour is the whole mechanism. Haven does not need — and does not take — any policy to obtain it.

That is exactly the friction uninstall protection needs: someone in a bad moment cannot delete the thing that is protecting them in two taps, but the door is never locked.

Deactivating is always possible#

Two routes, and both are honest:

In the app. Behind the PIN-gated Extra Guard screen, plus a confirmation.

In system settings. Android's own device-admin list, where deactivation always works. Android shows Haven's warning text first:

This only stops Haven from being deleted on impulse. Haven uses no other admin power: no access to your data, your screen or your password.

If the user proceeds anyway, that is their decision and it takes effect immediately. Haven does not attempt to re-activate itself, does not nag, and does not interfere.

What is recorded#

Deactivation is a weakening of protection, so it is written to the local transparency log and appears in the accountability history.

There is a deliberate asymmetry between the two routes, and Haven does not paper over it:

The in-app route can notify a paired accountability partner, because the app is in the foreground and can hand a message to the user's mail app.
The system-settings route cannot. A broadcast receiver cannot launch a mail app from the background. So it is logged locally and shows up in the partner's next view of the history.

Haven does not create a background email path to close that gap, because doing so would mean holding partner addresses on a server. See Accountability partner.

The activation dialog#

Activation goes through Android's own "activate device admin?" screen, which Haven cannot skip or style. Haven supplies an explanation that the system displays:

Haven uses this only to stop the app being deleted in an impulsive moment. No other administrator rights are used: no access to your data, your screen or your password.

That explanation is rendered outside any Haven activity, so the app's chosen language is applied explicitly — otherwise an English-speaking user on a Dutch phone would be shown Dutch.

Some device manufacturers' builds do not honour the direct activation intent. When the system dialog returns without activating, Haven offers the system's device-admin list instead, where the toggle always works. It resolves that destination before offering it and falls back to the security settings root if it is unavailable, so the user is never sent to a dead end.

It is opt-in and skippable#

Delete protection is offered as one step in the short setup that follows switching protection on, and that step is skippable. Protection works fully without it.

Pushing harder on a permission this significant would only teach people to grant things they do not understand.

Play policy position#

Requirement	Haven
Device-admin use must be justified by a core feature	Blocking impulsive self-uninstall, which is the core anti-relapse mechanism of a gambling blocker
Only the necessary policies may be requested	Zero policies are requested
The user must be able to deactivate	Two documented routes, both always available, neither obstructed
The user must be told what it does before granting	Stated in the app before the request, in Android's own dialog during it, and in the deactivation warning
No use for device takeover, lockout or ransom behaviour	Haven cannot lock, wipe, or change a password — it has no such policy