Guard – Privacy Policy & Terms of Use

Last updated: 2026

1. General description

Guard is a digital wellbeing and focus app for Android. The app helps users enforce their own focus rules, time limits and app blocks in order to reduce impulsive app use and distractions.

Guard was built as a local-first application. Its core, protection and usage functions fundamentally operate locally on the device.

2. Android AccessibilityService

Guard uses the Android AccessibilityService API for essential focus, blocking, friction and self-defense functions. Data processed through AccessibilityService is processed exclusively on the device and is not transmitted to Guard servers or Firebase Analytics.

As part of these functions, Guard may process the following information via AccessibilityService in particular:

• Package and window information of the currently open app, to detect which app is currently active and whether a user-defined block or time rule applies to it.
• Window and screen changes as well as relevant interaction events, to correctly execute blocks, friction and other protection features activated by the user.
• Visible text, labels, content descriptions and UI controls within relevant Android system and settings screens, to the extent this information is required to detect states and actions relevant to Guard, particularly in connection with self-defense.
• When website blocking is enabled: visible information from the address bar of supported browsers, to the extent required to match a visited web address against the website block rules defined by the user.

Information read from the address bar for website blocking is used exclusively for the immediate check against the block rule and is then discarded. It is not stored permanently by Guard and is not transmitted to Guard servers or Firebase Analytics.

Accessibility content such as text, content descriptions and UI elements is processed exclusively on-device to execute the relevant Guard function. Guard does not read, store or transmit private messages, emails, passwords, photos or other private content via the AccessibilityService interface.

Guard does not use the AccessibilityService API for advertising, marketing or personalized ads.

The Accessibility permission is activated by the user themselves via the Android system settings. Before activation, Guard informs the user within the app about the use of the AccessibilityService API and the associated local data processing.

3. Installed apps and local usage data

Guard reads information about installed apps via Android APIs so users can choose which apps should be protected or restricted. The list of installed apps is not determined via the AccessibilityService API.

Package names of active apps may be processed and stored locally to provide app usage sessions, statistics, focus rules, blocking and the local Guard timeline.

Individual app usage times, app names or package names, and local timeline data are not transmitted by Guard as Firebase Analytics custom events.

4. Local storage

Depending on use, the following data may be stored locally, among other things:

• Focus, Bedtime and app rules,
• App block lists,
• Friction and protection status,
• local usage statistics and timeline data,
• settings,
• tasks, appointments and reminders,
• custom alternatives,
• Guardzilla-related local data,
• report preferences,
• PIN configuration.

The Guard PIN is not stored in plain text. Guard uses a local cryptographic check value to verify the entered PIN.

5. Android backup and device transfer

Guard does not use its own Google Drive backup, Firebase Storage or Firestore for personal Guard data.

Android Auto Backup / Android Device Transfer is configured as a strict allowlist. Only the following Guard data can be backed up or transferred through it:

• Tasks,
• calendar data, appointments and reminders,
• self-created alternatives,
• report preferences.

In particular, the following are not part of this backup allowlist:

• PIN or PIN check value,
• trial status,
• Pro/Ultimate entitlement,
• self-defense data,
• block rules,
• friction data,
• app usage and timeline data,
• Focus and Bedtime data,
• Guardzilla history,
• Ultra/reward status.

Backup or device transfer is handled through the backup infrastructure provided by the user or by Android, not through a cloud service operated by Guard.

6. Biometric features

Guard may use Android system functions for biometric or device authentication.

Raw biometric data such as fingerprint or face data is not stored by Guard. Authentication is handled via the Android system mechanisms provided for this purpose.

7. Optional usage diagnostics with Firebase Analytics

Guard uses Google Analytics for Firebase for optional technical usage diagnostics.

Analytics data collection is disabled by default. It is only enabled if the user explicitly consents to anonymous usage diagnostics, and can be disabled again at any time afterwards.

Guard does not use a Firebase User-ID. Collection of the Advertising ID by Firebase Analytics is disabled in Guard. However, Firebase Installations is part of the Firebase components used; when analytics collection is enabled, an installation-related technical identifier may therefore be processed.

When analytics is enabled, Guard may record technical function events, for example:

• start and completion of onboarding,
• consent to the Accessibility notice and activation of the service,
• triggering of a Guard block,
• start, completion or cancellation of an unlock,
• start and completion of a friction challenge and its type,
• opening and using Guardzilla,
• tasks becoming due or completed,
• reminders and appointments becoming due,
• changes to the Guard plan.

For certain events, only limited categories are transmitted, such as friction type, presentation type, or plan status (free, trial, pro, ultimate).

Through its own analytics events, Guard does not transmit:

• names or package names of other apps,
• PINs or PIN check values,
• task, appointment or reminder text,
• Guardzilla input or dialog text,
• Focus app lists,
• personal alternatives,
• individual app usage times,
• Accessibility text or UI nodes,
• free-text input,
• email addresses,
• purchase tokens or prices.

When analytics is enabled, Firebase Analytics may additionally process its own automatic SDK events and technical metadata.

The optional usage diagnostics serve the technical analysis and further development of Guard, not personalized advertising.

8. Advertising and profiling

Guard contains no advertising and uses no external ad networks.

Guard does not sell personal data and does not use locally collected app usage or Accessibility data for advertising profiles.

The optional Firebase usage diagnostics serve exclusively the analysis and improvement of Guard.

9. Feedback and problem reports

Guard offers a voluntary, email-based feedback and problem-report flow.

Depending on the type of report, this may include:

• free text entered by the user,
• for problem reports, the name of an affected app as entered by the user,
• expected behavior,
• additional information,
• manufacturer and device model,
• Android version and API level.

Logcat, stack traces, crash logs, the Guard timeline, PIN, block list, screenshots or usage statistics are not attached automatically.

The user must deliberately fill out the form, choose "Send", and then actually send the message in their external email client. Guard does not send this email on its own in the background.

10. Google Play Billing and Guard plans

Guard may offer a time-limited trial as well as free and paid feature tiers.

Guard Pro is offered as a one-time in-app purchase. Guard Ultimate is offered as a subscription. Purchases and subscriptions are handled exclusively through Google Play Billing.

As part of the technical purchase process via Google Play Billing, Guard temporarily receives purchase-related information such as product ID, purchase status, purchase token, acknowledgement status and product details.

Guard itself does not store credit card, bank, billing or full Google account data. Purchase token, price and transaction details are not stored permanently by Guard.

11. Focus, Bedtime, friction and self-defense features

Guard was designed to make impulsive access to apps selected by the user more difficult, and to enforce focus rules set by the user themselves.

Depending on configuration, this may use app blocks, time limits, Focus and Bedtime modes, and various friction mechanisms, among others.

Self-defense features can detect and make more difficult certain actions within the Android system UI that are relevant to Guard's protection.

All protection rules are set up or activated by the user themselves.

12. Device compatibility

Guard's functionality can be affected by Android versions as well as manufacturer-specific power, background and security mechanisms.

On certain devices, additional system permissions or battery exemptions may be required.

Full compatibility with all Android devices and manufacturer customizations cannot be guaranteed.

13. Changes

Guard continues to be developed. This privacy policy and these terms of use may be adjusted if features, technical data processing, or legal requirements change.

The current version is made available on the official Guard website and/or within the app.

14. Liability and availability

Despite careful development, no guarantee can be given for uninterrupted availability, full device compatibility, fully error-free operation, or protection against every conceivable method of circumvention.

Use of Guard is subject to the settings chosen by the user themselves.

Contact

Simplinox
Email: simplinox.guard@gmail.com