WristRevive: Battery Tests Privacy Policy

WristRevive Privacy Policy

Effective date: 6 October 2026

WristRevive is a Wear OS battery diagnostics application with an optional Android phone companion, published by Quinn Favo. This policy explains what information WristRevive processes and how it moves between the user's paired devices.

Information processed on the watch

When Android exposes the information, WristRevive may process and store:

• battery percentage, charging state, plug source, and charging status
• battery temperature, voltage, current, charge counter, and energy counter
• interactive/screen context and Battery Saver state
• wall-clock timestamps and elapsed realtime
• watch manufacturer, model, Android/Wear OS version, security patch, and build fingerprint
• app version, boot-session identifiers, collection source, and diagnostic quality flags
• Revive Scan state/results
• Idle Drain Test state/results
• Everyday Lite profile/checklist/restoration state

This information is used to show battery history, estimate observed runtime, evaluate data quality, identify elevated-drain correlations, compare controlled tests, and provide reversible battery-saving guidance.

Optional app-activity evidence

If the user enables Android Usage Access for WristRevive on the watch, WristRevive can query a bounded recent history of application activity after an explicit diagnostic request. The watch reduces that history to package-level 15-minute aggregates such as foreground duration, foreground-service duration, and event count.

WristRevive does not persist raw UsageEvents and does not claim these aggregates measure the electrical consumption of an app. They are used only to compare activity patterns with watch-observed elevated-drain periods. Core battery diagnostics continue to work when Usage Access is not enabled.

WristRevive does not request broad installed-app visibility through `QUERY_ALL_PACKAGES`.

Paired-phone synchronization

If the Android phone companion is installed, WristRevive transfers a bounded mirror of watch-observed diagnostic information to the matching WristRevive app on the user's paired Android phone through the Wear OS Data Layer API provided by Google Play services.

The phone may receive:

• retained battery samples and their watch observation context
• retained Revive Scan and Idle Drain Test records/results
• recent software/build epochs needed to interpret evidence
• current Everyday Lite profile state
• a random WristRevive watch-install identifier and monotonic sync revision used to prevent stale or previous-install records from being merged incorrectly

The phone is a visualization/export mirror and contextual-analysis surface. It does not claim to have measured watch battery telemetry itself. Phone-local notification and connection evidence remains separate from the watch-authoritative battery mirror.

Optional phone notification evidence

If the user explicitly enables Notification Access for WristRevive on the Android phone, WristRevive processes posted-notification metadata to create bounded diagnostic context. Product code reads only the source package name and post timestamp, then uses and exports only package/count/time buckets from the most recent seven days. Expired buckets are pruned whenever WristRevive next processes relevant phone context, opens the companion, or prepares an export; WristRevive does not keep a periodic background timer running solely for retention cleanup.

WristRevive does not read or store notification title, text, people, actions, extras, remote-input content, message bodies, or other notification content.

Notification evidence remains local to the phone unless the user explicitly includes it in a diagnostic export. It is compared with watch-observed drain periods as contextual association only and cannot prove that a notification or source app caused battery drain.

Wear Data Layer transport

Wear Data Layer can use Bluetooth or an available network. Google documents that when Bluetooth is unavailable, Data Layer may route data through Google-owned cloud infrastructure. Google states that cloud-routed Data Layer traffic is end-to-end encrypted; direct Bluetooth Data Layer traffic uses an encrypted Bluetooth channel managed by Google Play services.

Google Play services also restricts Data Layer communication so the package name and app signature must match between the watch and phone apps. Other apps do not receive WristRevive Data Layer records through this channel.

WristRevive does not operate the Data Layer transport infrastructure. Google's handling of Google Play services and its infrastructure is governed by Google's own terms and privacy policies.

No WristRevive cloud account or diagnostic backend

WristRevive has no developer-operated diagnostic server, cloud database, user account, advertising SDK, or analytics SDK. The developer does not receive a copy of the user's diagnostic history through WristRevive.

WristRevive does not sell diagnostic information.

User-controlled export

The phone companion can create a diagnostic JSON export or timeline CSV. JSON schema 2 can include bounded app-activity, notification-count, connection-state, and diagnostic-command context alongside watch-authoritative records only after the user explicitly chooses an Android Storage Access Framework destination.

WristRevive does not automatically upload exports. The destination chosen by the user may itself be provided by another app or cloud storage service; handling after that explicit choice is controlled by that destination provider and the user.

Exports exclude Google Play purchase tokens.

Bug reports and support

The Android phone companion includes a user-initiated Report a bug action that opens the public WristRevive support page in the user's browser. The support URL contains only the report type, Android source, a safe watch-support context, and the WristRevive version name.

WristRevive does not automatically attach or upload battery history, detailed usage evidence, Revive Scan history, Idle Drain Test records, software/build fingerprints, exported diagnostics, purchase tokens, logs, or other diagnostic state. The Wear OS Settings screen provides a clear handoff to the phone companion instead of transmitting diagnostic data for support.

Any information the user deliberately enters on the external support page is governed by that site's disclosed form and privacy behavior.

Google Play purchases

Optional WristRevive Pro purchases are processed by Google Play. The Wear app receives purchase state, product identifier, purchase token, acknowledgement state, and entitlement information so it can unlock purchased features and acknowledge the transaction.

WristRevive does not receive payment-card or bank-account details. Purchase tokens are not synchronized to the phone diagnostic mirror or included in diagnostic exports. Google Play's processing is governed by Google's policies and terms.

Retention

Watch

• raw samples: bounded to the most recent 1,024 persisted observations
• Revive Scans: normally the latest 20, subject to the retained conclusive free-scan accounting sentinel
• controlled tests: latest 20
• profile and cached entitlement state: until changed, app storage is cleared, or the app is uninstalled

Phone

The phone stores a durable mirror of the watch's currently retained diagnostic history and current profile/build state. Watch retention/tombstones are applied to the phone mirror during synchronization.

The phone mirror is not a cloud backup. Data older than the watch's retained source history cannot be recreated after the phone mirror is deleted or rebuilt. Time-correlated phone context is reset when a different watch-install authority is accepted so evidence from two watches is not blended. Notification package/count/time buckets are limited to the most recent seven-day evidence window and expired buckets are removed on the next relevant app/context activation or export.

Android cloud backup and device transfer are disabled for both WristRevive application artifacts.

Deletion

WristRevive does not create an account.

Users can delete local data independently on each device by clearing WristRevive app storage or uninstalling WristRevive. Clearing the phone companion does not delete authoritative watch data; if the watch app remains installed, later reconciliation can restore only the history still retained on the watch.

Clearing/uninstalling the watch removes its authoritative local WristRevive history. A fresh watch installation receives a new app-install synchronization identity so an old phone mirror cannot silently claim to represent the new installation.

Security

• Android application sandboxing is used on both devices.
• cleartext traffic is disabled in both release manifests.
• Android backup/device transfer is disabled for diagnostic state.
• Wear Data Layer requires matching package/signature identity and uses encrypted transport as described above.
• sync payloads are size-bounded and protocol-versioned.
• malformed, stale, duplicate, or incompatible sync state cannot destructively replace the phone mirror.
• no broad storage permission is used for export.

Children

WristRevive is a general battery utility and is not directed to children.

Changes

This policy must be updated before WristRevive adds a developer-operated cloud backend, account system, advertising, analytics, benchmark upload, or any materially different diagnostic transfer.

Contact

Questions can be sent to quazmoz@vivaldi.net.

Developer website: https://consultant.quinnfavo.com