WristCapture: Phone Screenshot Privacy Policy

WristCapture Privacy Policy

Last updated: October 5, 2026

WristCapture is an Android and Wear OS utility that lets you deliberately request the paired Android phone's normal system screenshot action from a Wear OS watch. The Android phone app also offers an optional rewarded-ad flow that can add finite capture credits.

Screenshot and AccessibilityService privacy

Android creates and stores screenshots. WristCapture does not receive, inspect, upload, analyze, edit, retain, or index screenshot images, thumbnails, filenames, paths, gallery contents, visible screen text, foreground-app content, accessibility node contents, accessibility event contents, or typed text.

WristCapture uses Android AccessibilityService only to request Android's built-in Take screenshot global action after a deliberate WristCapture capture request or the phone compatibility test. The service is configured not to retrieve window content. Accessibility data is not used for advertising, analytics, profiling, or any unrelated purpose.

Before opening Android Accessibility settings, WristCapture presents a prominent disclosure and asks for affirmative consent. You can decline or later disable the service in Android settings.

Capture credits and Lifetime Pro

Every installation starts with 10 included capture credits. Users who do not have unlimited access may optionally watch a rewarded ad on the phone to add capture credits. A completed server-verified reward adds 10 credits. The finite spendable bank is capped at 50.

Lifetime Pro is a separate one-time Google Play purchase and remains unlimited and ad-free while the purchase is valid. Google Play Billing is the authority for permanent ownership. Rewarded advertising, RevenueCat, AdMob, UMP, or network failure cannot revoke or shorten a valid Lifetime Pro purchase.

Only a screenshot command accepted by Android consumes one finite credit. Failed, blocked, stale, duplicate, disconnected, or rejected attempts do not consume one.

Optional rewarded advertising

Advertising exists only on the Android phone app and only after the user explicitly chooses the rewarded-credit option. There are no banner, interstitial, app-open, automatic, forced, Tile, complication, or Wear OS ads.

The rewarded flow uses:

• Google Mobile Ads SDK to load and show the rewarded ad;
• Google User Messaging Platform (UMP) to manage applicable consent/privacy choices;
• RevenueCat's Android SDK and AdMob adapter to associate the rewarded transaction with an anonymous RevenueCat customer, perform server-side reward verification, and expose the verified in-app-currency balance.

WristCapture does not supply RevenueCat with your name or email address as an app user ID. The RevenueCat SDK creates an anonymous identifier when configured without a custom app user ID.

Google Mobile Ads can process service data such as IP address/general-location signals, user-product interactions, diagnostics, and device/account identifiers for advertising, analytics, and fraud-prevention purposes according to Google's SDK configuration, platform settings, consent state, and policies. RevenueCat processes the anonymous customer identity and data needed to track/verify rewarded-ad transactions and virtual currency. Google and RevenueCat handle their service data under their own terms and privacy policies.

WristCapture does not operate its own ad-tracking or analytics backend.

Reward verification and local accounting

The local AdMob "earned reward" callback does not authorize capture credits. RevenueCat must verify the reward server-side. WristCapture then refreshes RevenueCat virtual currency `CAP` and converts only valid new cumulative server evidence into the local finite credit bank.

The phone stores locally:

• the original included captures already consumed;
• rewarded capture credits available;
• the cumulative RevenueCat `CAP` balance already applied locally;
• an allowance revision used to keep phone/watch credit state ordered.

If a verified +10 reward cannot fully fit under the 50-credit cap, WristCapture does not partially credit it or mark it consumed. The reward remains pending against the server balance until enough local capacity exists.

Authority-bearing credit state is excluded from Android cloud/device-transfer backup by WristCapture's extraction rules. Clearing app data or uninstalling can remove local finite-credit state. Do not rely on rewarded credits as cross-install account currency.

Consent and privacy choices

Before requesting a rewarded ad, WristCapture refreshes UMP consent information, displays required consent UI, and proceeds only when UMP reports that ads may be requested. When UMP requires a privacy-options entry point, the reward screen exposes Ad privacy choices.

If consent information, ad loading, networking, or reward verification fails, WristCapture grants no fallback credits. Existing finite credits and valid Lifetime Pro ownership are not removed.

Phone and watch communication

WristCapture uses Wear OS Data Layer / Google Play services for paired-device communication. Operational messages can include protocol/app-version information, random request identifiers, timestamps, capture source, capture result/reason, reduced unlimited-access state, finite capture-credit count, allowance revision, compatibility state, and watch behavior settings.

These messages do not contain screenshot images, visible screen content, gallery data, payment details, purchase tokens, RevenueCat secret keys, reviewer secrets, advertising payloads, or copied diagnostics. Advertising SDKs are not included in the Wear module.

Other local operational data

Depending on features used, WristCapture can store setup/disclosure acknowledgement, compatibility-test state, reduced paid-entitlement state, finite capture-credit accounting, reviewer-access state, watch preferences, paired-device selection state, recent random capture request IDs for replay prevention, and short-lived throttle/quick-action state.

WristCapture has no developer-operated user-account system and no developer-operated screenshot backend.

Purchases

Lifetime Pro purchases are processed by Google Play Billing on the phone. WristCapture uses Google Play product/ownership information to display localized pricing, launch the purchase flow, acknowledge completed purchases, restore ownership, and reconcile entitlement state.

WristCapture does not store payment-card details. Purchase tokens, order identifiers, payment details, reviewer secrets, and Google account information are not sent to Wear OS or included in support diagnostics.

Help, feedback, and diagnostics

Help & Feedback opens the WristCapture support page only after a user action. Diagnostics are generated locally and never uploaded automatically. Choosing Copy diagnostics places a sanitized allowlisted summary on the clipboard; you decide whether to paste or submit it.

Diagnostics exclude screenshot pixels/files/paths, gallery information, accessibility node/event content, foreground/private content, purchase tokens, payment details, reviewer plaintext/hash, ad payloads, secret material, sensitive raw Data Layer payloads, and arbitrary logcat output.

Permissions and SDK manifests

The phone app uses AccessibilityService for the narrow screenshot-command purpose described above. The phone-only Mobile Ads/UMP/RevenueCat SDKs require network access and can contribute manifest permissions/metadata. WristCapture does not request photo, broad storage, camera, microphone, contacts, or location permission for its core capture or rewarded-credit flow.

Release builds must be audited using the exact merged manifest and current third-party SDK documentation before publication.

Google Play Data Safety and ads declaration

Google Play Data Safety answers must be completed against the exact submitted phone and Wear bundles, merged manifests, runtime traffic, current Google definitions, and current SDK disclosures. Repository guidance is maintained in `docs/DATA_SAFETY.md`.

A production release containing this rewarded-credit feature must set Google Play Contains ads = Yes.

Security controls

WristCapture validates protocol version, freshness, replay, phone state, AccessibilityService readiness, effective access, cooldown, and transaction admission before requesting Android's screenshot action. Rewarded ads never bypass those checks.

Production verification rejects missing rewarded configuration and Google's sample AdMob identifiers. RevenueCat secret API keys, service-account material, AdMob credentials, signing secrets, purchase tokens, and reviewer plaintext must never be committed to the app or repository.

Changes and contact

If WristCapture changes permissions, SDKs, advertising behavior, account handling, screenshot-content access, telemetry, or external data processing, this policy and Play declarations must be reviewed before release.

For privacy or support questions, use WristCapture's Help & Feedback flow, the support page linked from the app/Play listing, or the developer contact information in Google Play.