Cove Pro Installation and Entitlement Evidence

Direct answer

Treat Pro access as an evidence chain, not as a single “installed” or “paid” flag. First establish whether the exact application and product are publicly offered in the user’s region and account context. Then identify the purchase state returned by Google Play, distinguish that state from a locally cached entitlement, and test how the application restores and applies it after reinstall, device change, refund, pending payment, loss of network, or Billing connection failure. A repository containing a billing flow proves only that code exists; it does not prove that a store listing is public or that a particular user owns a purchase. The repository code snapshot reviewed on 2026-10-04 contains Android BillingManager and ProState code for specific applications. The sample flow connects to Google Play, queries product details and existing purchases, updates a local boolean entitlement, and uses that state to gate application features. That implementation is useful evidence for a verification plan, but it is not evidence of current public sale, configured production products, localized prices, store rollout, or entitlement backend validation. Product availability and terms must be checked in the current official store and release configuration before any user-facing sales claim. This draft intentionally omits prices and promises. Model the states separately. “App installed” means Android has a package. “Product details loaded” means the Billing client returned offering information for that account and region. “Purchase pending” is not “purchased.” A completed purchase may require acknowledgement and a local entitlement update. A cached local entitlement is a convenient state for UI responsiveness and may be stale until the app synchronizes with Play. “Feature unlocked” is an app behavior that should follow a well-defined policy. On reconnect, the app should query current purchases and handle revoked, refunded, or absent purchase state according to the chosen implementation. Never infer entitlement from a paywall dismissal, a local preference alone, or the user’s statement without an appropriate evidence path. Purchase restoration should be intentional and testable. A fresh install can start with local entitlement false and then restore a prior purchase after Play connectivity returns. A device switch can expose an account mismatch. A pending purchase may still be waiting for payment and should not be treated as complete. A purchase can be refunded or revoked, so the app must decide how stale local access is corrected. Offline behavior needs a separately defined policy: a cached grant may allow temporary local access, but the product must not promise permanent offline entitlement or claim current status if it cannot refresh. Tell the user whether the app is checking the store, using a last-known state, or unable to verify right now. The UI should avoid a false binary. Use states such as checking, active based on last confirmed purchase, not owned, pending, product unavailable, store disconnected, and needs attention only when the implementation can distinguish them. Every user action should have an outcome: retry connection, restore, open official product page when one exists, wait for pending payment, or contact support with a redacted record. If there is no verified official listing, do not make a “Buy Pro” button point to an invented destination. If the local state and Play response disagree, show that the entitlement is being reconciled and avoid silently discarding user data or purchase history. Keep privacy boundaries clear. Google Play purchase verification is not the same as model inference, and a local AI claim does not mean there are no other network requests. Explain which store service is queried and what happens when unavailable. Support diagnostics should include app/build identifier, product identifier only if confirmed from current configuration, Billing response category, purchase state, entitlement state timestamp, and restore result; do not log full purchase tokens or unrelated user content. Do not claim a secure server-side verification system unless that path exists and has been verified.

A Pro feature appears locked after reinstall

After reinstalling a Cove app, a user finds a Pro feature locked. Their phone is offline and the local entitlement flag is false; they remember a prior purchase but have not reconnected to Google Play. Support must show how to restore later without assuming public sale or treating a cached flag as current ownership.

Decision

Explain that restoration depends on the official store service, preserve the user’s ability to retry, and reconcile current purchase records when connectivity returns.

Expected outcome

The app reports a restored entitlement or a verifiable error without falsely denying a purchase, granting from a screenshot, or implying current public sales.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Public plan and listing snapshot
• Entitlement state matrix
• Purchase, restore, and offline tests

A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.

Implementation workflow

1. Check product availability separately. Inspect the current official listing, region and account context, product type, and release configuration. A BillingManager constant, paywall screen, test product, or repository note does not prove public sales.
2. Define entitlement states. Separate app installation, product details available, pending transaction, purchased, acknowledged, cached local entitlement, revoked or refunded state, and unable to verify. Document which state unlocks each feature.
3. Restore using purchase records. Test reinstall, same-account device change, account mismatch, pending payment, refund or revocation, disconnected Billing service, and no purchase result. Reconcile local cache with query results instead of trusting it indefinitely.
4. Respect purchase lifecycle. Grant only at the implemented verified state and acknowledge eligible purchases as required by current Play guidance. Keep pending, cancellation, unavailability, and verification error distinct from purchase success.
5. Specify offline policy. Define whether last-known local entitlement is honored without a connection and under what policy. If ownership cannot be refreshed, report unable to verify now rather than permanent access or purchase loss.
6. Review copy and diagnostics. Ensure buttons reach only a verified official purchase or restore route. Redact purchase tokens and user content while retaining the response category, purchase state, timestamp, and reconciliation outcome needed for support.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• Availability, purchase status, local cached entitlement, restored status, and feature access are separate states with explicit transitions.
• Pending, canceled, unavailable, or failed verification never appears as a completed purchase.
• Reinstall, account change, refund/revocation, and reconnection tests document local reconciliation behavior.
• No price, public-sale, or permanent offline entitlement claim appears without current official evidence and matching code.

Decision table

Failure patterns to prevent

• Calling a planned tier purchasable
• Packaging Pro as an unverified APK

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Cove download status
• Cove network audit
• Integrate the Google Play Billing Library
• Google Play Billing overview
• Google Play Billing test purchases

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions