PRIVACY POLICY

Welcome to GuardAlert Anti-Theft Alarm ("GuardAlert", "we", "us", or "our"). GuardAlert is engineered with a strict local-first privacy architecture. We believe that your device's security data should belong solely to you. This Privacy Policy details exactly how we handle system permissions, localized telemetry, and data storage on your device.

1. Local-First Data Commitment

GuardAlert is designed to be fully self-contained and operates securely without requiring any active internet connection to perform its core monitoring functions. We do not host cloud servers, and we do not collect, transmit, upload, or sell any of your personal details, biometric tokens, photos, or location telemetry.

2. Device System Permissions Usage

To provide advanced sensor-based monitoring and theft deterrence, GuardAlert requires specific system permissions. These are used strictly locally:

• Biometric Credentials: GuardAlert uses standard Android `BiometricPrompt` and cryptographic APIs to verify your identity before disarming the alarm. We have absolutely no access to your physical fingerprints, face scans, or screen lock PINs. Authentication is handled entirely by the secure hardware enclave of the Android OS.
• Camera Permission: Used only when you enable the Intruder Photo feature. When the alarm triggers, the application captures a front-camera snapshot of the unauthorized handler. Photos are saved directly into the application's secure sandboxed directory and are not indexed by public galleries unless explicitly configured.
• Microphone Permission: Required solely to run Door Guard Mode. GuardAlert checks the ambient noise amplitude (decibels) to trigger an alarm if an intrusion is detected. Raw audio is analyzed purely in volatile memory in real-time; no audio recording is ever written to disk or transmitted.
• Device Administrator Permission: An optional security barrier used to prevent malicious uninstallation of the application by a thief. When active, it displays standard security alerts and enables dynamic tamper defense protocols.
• Background Foreground Service: GuardAlert runs a persistent `ForegroundService` during active arming to ensure the operating system does not kill the monitoring sensors when the screen turns off. This displays a visible status notification.

3. Local Storage and Event Retention

All recorded alarm history events (sensor trigger source, active duration, timestamp, and resolved disarm status) are written to a lightweight local SQLite database (using Room library) and DataStore Preferences.

You maintain full control over this data. You can manually delete any event details or wipe the entire database directly within the settings screen at any time. The application also supports automatic local pruning of logs older than a configurable amount of time.

4. Third-Party Libraries and SDKs

GuardAlert does not load any third-party ads networks or behavior trackers. We utilize standard, verified Google Play Services libraries for basic device operation. To monitor stability, the application contains Firebase Crashlytics. All crash logs generated are stripped of personally identifiable information and are strictly limited to anonymized hardware profiles and stack traces.

5. Children's Privacy

Because GuardAlert does not collect or transmit any data online, our services are naturally fully compliant with the Children's Online Privacy Protection Act (COPPA) and General Data Protection Regulation (GDPR) frameworks. We do not gather or maintain information from anyone, regardless of age.

6. Changes to This Privacy Policy

We may update our Privacy Policy periodically to reflect app updates. Any changes will be published in the application's settings and updated inside our documentation folders. Your continued use of the application following updates constitutes your acceptance of the localized changes.

7. Contact Information

If you have any questions, security inquiries, or suggestions regarding our local-first privacy commitment, please reach out to us at: