Concepts¶

These definitions are shared across the end-user guide and engineering articles. Each named anchor is stable for links from either language edition.

Bank credit¶

A time bank stores credit for one configured app group on one phone. Apps assigned to that group share its balance. A session begins only after the person chooses Use banked time. The ledger spends measured foreground use of the group’s apps; Home, other apps, screen-off, and locked time pause spending. Ending a session retains unused credit.

Refill, capacity, and daily-minimum values are policy settings. For example, a configuration may add 3 minutes after 30 allowed minutes outside the protected sleep schedule, with a 30-minute cap. This is an example only. Credit is local to the phone and is not a synced multi-device balance.

Partner allowance¶

A partner allowance is a signed, temporary authorization for a specific app and request scope. Its fixed deadline starts when the server commits the approval, even if the phone receives it later or the person is away. It preserves bank credit. A policy refresh does not extend an already accepted allowance; current restrictions continue to apply.

Sleep¶

Sleep is a local policy restriction that blocks bank access during configured periods. A normal partner allowance does not bypass sleep. Only an allowance explicitly bound to a sleep exception can permit access during sleep, and only when the current policy enables that exception. The exception must be selected deliberately and approved by the partner.

Policy¶

Policy is the signed configuration that identifies managed app groups, unrestricted essentials, time-bank rules, and sleep schedules. The operator publishes policy; the phone verifies and saves it before using it. Android applies current local rules to access decisions. A historical approval receipt does not replace current policy.

The 3-minute refill, 30-minute interval, and 30-minute cap are example values, not product-wide constants. An administrator may publish different supported values.

Requests¶

A request asks the partner for a bounded allowance. The server records the request and decision durably. Pending, approved, denied, and expired are distinct states; an approved request’s allowance can later expire. Retrying an uncertain submission reuses the saved request ID and exact content, which avoids creating a second request. A changed request requires a new deliberate submission after the prior state is known.

Approval is not inferred from a notification, a live update, a local button state, or a missing response. The phone verifies the signed grant and its context before accepting the allowance.

Offline behavior¶

After successful policy activation, local Android enforcement can continue without contacting the server on each app check. Bank sessions, saved balances, and accepted allowance deadlines are handled locally. Offline, the phone cannot receive a newer policy, learn a server revocation, or resolve a pending request. A request without a confirmed receipt does not grant access.