WearRelay Privacy Policy

WearRelay Privacy Policy

Last updated: November 3, 2026

Canonical published location: <https://consultant.quinnfavo.com/privacy/wearrelay>

WearRelay is a Wear OS application developed by Quinn Favo / Quazmoz. It is being developed to display supported iPhone notifications on a Wear OS watch through Apple's Bluetooth-based Apple Notification Center Service (ANCS). This policy describes the app's current development implementation, not a guarantee that every planned feature or device combination has completed release testing.

What WearRelay processes

After you select an iPhone that is already paired in the watch's Bluetooth settings, start the relay, and grant the relevant permissions, WearRelay can receive and process notification information that your iPhone makes available through ANCS, including:

• notification titles, subtitles, message/body text, and other preview content;
• the notification's sending app or source identifier;
• notification category, event state, identifiers, and supported action metadata;
• connection, authorization, and delivery state needed to render and manage notifications on the watch.

Notification information can be sensitive, including message text and sender names. WearRelay uses it to display notifications on the watch. The current implementation handles notification content in active session memory and Android's local notification display surface; it does not intentionally persist a searchable message-history database.

Local settings and technical data

WearRelay saves relay-enabled intent and related settings in app-private watch preferences. It identifies the selected iPhone by a salted SHA-256 fingerprint of its Bluetooth address (using a per-install random salt) and re-matches that fingerprint against the watch's current paired-device list. WearRelay does not save the raw phone address or name. Some earlier platform-supported companion associations may still exist, but current Wear OS 6 setup selects a phone already paired in system Bluetooth settings; it does not rely on Companion Device Manager association.

On-device app-source filters store bounded, derived SHA-256 mute-preference keys, not the source label, raw app identifier, notification title or message. These keys are not anonymous identifiers against dictionary attacks. Notification groups may temporarily hold limited title snippets and app labels in active watch memory for display; they are not persisted as a WearRelay history or included in diagnostics.

The code also supports a seven-day evaluation record containing local timing values, boot count and status flags. The evaluation is disabled in the current release build. If enabled in a later release, that record stays in app-private preferences and contains no notification text, phone name or address. Google Play Billing 9.1.0 is included even while Pro checkout remains disabled; the app may query Google Play purchase status when brought to the foreground. For an eligible purchase, the app can temporarily cache a SHA-256 purchase-token fingerprint for offline entitlement continuity, but not the raw token.

WearRelay may calculate content-free technical diagnostics such as connection transitions, Bluetooth/GATT result categories, retry and timeout counts, permission state, and coarse device or paired-phone status. These diagnostics are meant for reliability troubleshooting, not for recording message contents. Users can optionally share a content-free diagnostic report through the Android share sheet with a destination they select; no report is automatically sent to the developer.

Bluetooth, foreground service, and watch notifications

The Wear OS app requests or uses:

• `BLUETOOTH_CONNECT` (or legacy Bluetooth permissions on older supported OS versions) to inspect paired devices and maintain the iPhone connection;
• `BLUETOOTH_ADVERTISE` for an optional in-app pairing/discoverability flow, which has not completed physical-hardware release qualification and is not required when selecting a previously paired phone;
• `POST_NOTIFICATIONS` to display supported alerts and the relay's ongoing service notification when Android requires it;
• `FOREGROUND_SERVICE` and `FOREGROUND_SERVICE_CONNECTED_DEVICE` for an Android `connectedDevice` foreground service while the relay runs;
• `RECEIVE_BOOT_COMPLETED` to attempt relay restoration after a watch reboot or app update, but only when the user previously left the relay enabled and the required permissions and paired phone remain available.

The foreground service posts a status-only notification and a Stop relay action; it does not include relayed message text, sender names or phone identifiers. Stopping the relay ends that service. Recovery depends on Bluetooth and iOS availability, and successful reconnection is not guaranteed.

The current release manifest does not request `BLUETOOTH_SCAN`, an Android location permission, `INTERNET`, or `ACCESS_NETWORK_STATE`. The app does not pair arbitrary nearby phones silently; the supported selection path begins with a phone paired in Wear OS Bluetooth settings.

Paired-phone status and Google Play services

An optional, foreground-only diagnostic recheck can query the Google Play services Wearable API for whether an Android Wear network node appears reachable. The app uses only a temporary coarse status; it does not persist node names, node IDs, Bluetooth addresses, or Android phone notification content as part of that check. AndroidX paired-phone type information may also be shown as a temporary status.

This status check does not read or relay notifications from an Android phone and does not prove that any Android phone notifications were delivered. Google Play services may independently process technical information under Google's privacy terms, even though the WearRelay app manifest does not request Internet access.

Collection, sharing, ads, and accounts

WearRelay does not include a developer-operated account service, cloud notification relay, advertising SDK, or in-app analytics SDK. Google Play Billing 9.1.0 is included for an optional one-time Lifetime Pro purchase, but checkout remains disabled in the current build pending testing. The app can receive purchase history and purchase status from Google Play to recognize or restore an entitlement; when a purchase exists, the local entitlement cache can retain a purchase-token fingerprint. Google Play handles purchases and may process information under its own policies. WearRelay does not send purchase records or notification content to a developer-operated backend. The developer does not sell or share relayed notification content.

Notifications travel from the authorized iPhone to the watch through the local Bluetooth relationship. Android, Wear OS, device manufacturers, Google Play, and Google Play services may separately process limited device or service information as part of operating the platform, distributing the app, and supporting Bluetooth/companion services. Their processing is governed by their applicable terms and privacy policies.

If you choose to email support or submit information through an external support form, the information you intentionally provide is handled through that communication service and, where applicable, the website's privacy policy. The WearRelay app does not automatically attach message content to support communications.

Retention, deletion, and backup

Notification content is processed for the active relay/display workflow, rather than stored as a WearRelay message archive. Android may temporarily display relayed notifications in its own notification interface until they are dismissed or cleared.

Local settings, the salted selected-iPhone fingerprint, derived source-filter mute keys, optional evaluation timing flags and an optional Pro purchase-token fingerprint remain in app-private storage as needed for operation until replaced, reset, cleared or uninstalled. Content-free connection diagnostics may also be retained locally. Google Play may retain its own purchase records subject to Google's policies. The current application configuration disables Android cloud backup and device-to-device transfer of WearRelay app data.

You can stop relaying in the app, revoke Bluetooth or notification permissions, clear WearRelay app storage, or uninstall WearRelay. Clearing storage or uninstalling removes locally retained WearRelay data, but does not remove an iPhone Bluetooth pairing; unpair it separately in the watch's Bluetooth settings. Where an older companion association exists, remove it separately in system settings. WearRelay does not operate a server-side user account or notification archive requiring an account-deletion request.

Security

WearRelay relies on the Android application sandbox, watch Bluetooth pairing and app permission controls, bounded parsing of untrusted notification payloads, and local notification rendering. Notification contents should not be included in normal production logs or diagnostic exports. As with any software, no device or communication method can be guaranteed entirely secure.

Children

WearRelay is a general utility app, not directed to children. The developer does not knowingly collect children's personal information through a WearRelay account service.

Changes to this policy

WearRelay is under active development. Before a public production release, enabling Pro checkout, or material changes such as adding analytics, advertisements, cloud services, or a new data-transfer feature, we will review the actual app dependencies and behavior, update this policy as needed, and reconcile Google Play Data Safety disclosures.

Contact

For privacy questions or data requests, email consultant@quinnfavo.com.

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