Back to Privacy Hub
MotionGuard: Motion Alarm Privacy Policy
Last Updated: August 18, 2026
Quick Summary
A local-first Android and Wear OS alerting utility that processes motion during an explicitly armed session, keeps settings and trigger history locally, and uses the Wear Data Layer only for paired phone/watch status and alerts.
App-Specific Details
Specific data handling practices for MotionGuard: Motion Alarm.
- Processes accelerometer samples in memory while a motion-enabled session is armed; the release app does not retain a continuous raw accelerometer trace.
- Stores arming preferences, last-session state, coarse trigger-history records, onboarding state, and paired-Wear metadata locally on the device.
- Can exchange limited session and trigger information between the user's paired phone and watch through Google Play services Wear Data Layer; MotionGuard does not operate a server that receives this data.
- The current source does not request location, camera, microphone, contacts, SMS/call logs, AccessibilityService, device-administrator access, or advertising identifiers.
- The current source contains no MotionGuard account, developer cloud backend, advertising, analytics, attribution, crash-reporting SDK, or billing integration.
- Local data can be removed through in-app history clearing where applicable, Android Clear data, or uninstalling the app.
Detailed Official Policy
Full technical and legal disclosure for MotionGuard: Motion Alarm.
# MotionGuard: Motion Alarm Privacy Policy
Last updated: August 18, 2026
## Overview
MotionGuard is an Android and Wear OS alerting utility. Monitoring begins only after the user explicitly arms a session.
MotionGuard is designed to work without an account or MotionGuard cloud service. The current source does not send user data to a MotionGuard server and does not include advertising, analytics, attribution, crash-reporting, or billing SDKs.
## Data Stored On Your Device
MotionGuard may store the following information locally:
- Arming preferences, including selected trigger types, sensitivity, and settle delay.
- Last-session state needed to explain whether monitoring stopped, was disarmed, or triggered.
- Trigger-history records containing session times, trigger type, sensitivity, a coarse movement summary, charger state at arm time, and the phone-side result of a best-effort Wear message attempt.
- Onboarding completion state.
- Local metadata needed for the paired Wear OS experience.
A successful phone-side Wear send result is not treated as proof that a watch displayed or delivered an alert.
## Motion Sensor Processing
While a motion-enabled session is active, MotionGuard processes accelerometer samples in memory to establish a baseline and detect configured movement.
The release app does not retain a continuous raw accelerometer trace in trigger history. Trigger history stores only a coarse movement summary needed to explain the event to the user.
## Wear OS Companion
If the optional Wear OS companion is used, MotionGuard can transfer limited status and trigger information between the user's paired phone and watch through Google Play services Wear Data Layer. This can include session state, enabled trigger types, sensitivity, timestamps, session identifiers, and a coarse trigger summary.
The Wear status Tile displays newest-known phone status and is read-only. Optional watch trigger alerts are best effort and depend on connectivity.
MotionGuard does not operate a server that receives the paired-device data.
## Permissions And Data The App Does Not Request
The current phone application uses permissions for the user-started foreground monitoring service, notifications where Android requires them, and vibration. Motion detection requires an accelerometer-capable device.
The current source does not request or use location, camera, microphone, contacts, SMS or call logs, an AccessibilityService, device-administrator access, storage access, or advertising identifiers.
## Third-Party Platform Services
MotionGuard uses Google Play services Wearable APIs for paired phone/watch communication. Google and the Android/Wear OS platform may process technical information according to their own policies when providing platform services.
The current application does not include advertising, analytics, attribution, or third-party crash-reporting SDKs.
## Retention And Deletion
Trigger-history records remain on the phone until the user chooses Clear trigger history, clears Android app data, or uninstalls the app.
The in-app Clear trigger history action deletes the local trigger-history records only. It does not silently change an active session, arming preferences, or onboarding state.
Clearing app data or uninstalling MotionGuard removes local application state. MotionGuard has no server-side account or user-data copy to request deletion from.
## Backup And Device Transfer
MotionGuard excludes session state from Android cloud backup and device transfer so stale armed state is not restored as if monitoring were still active.
## Children
MotionGuard is not directed to children and does not knowingly collect personal information from children through a developer-operated service.
## Changes To This Policy
If MotionGuard adds billing, analytics, crash reporting, accounts, cloud services, or any other functionality that changes data handling, this policy and the Google Play Data Safety declaration must be updated before that change is released.
## Contact
For privacy questions, contact Quazmoz@vivaldi.net.
General Privacy Terms
These terms apply across all our applications.
Questions or privacy requests? Contact us at Quazmoz@vivaldi.net