Android purchases run through Google Play and always require a foreground Activity at purchase time.

​
Preferred purchase surface

Use the package-based purchase API whenever possible. There is also a deprecated direct-target purchase path with AppActorPurchaseParams, but it is meant for explicit Play Store targets rather than normal server-driven offerings flows.

​
Recovery flows

Use the recovery method that matches the product behavior you want:
  • restorePurchases() for the user-facing restore action
  • syncPurchases() for quiet reconciliation against current Play purchases
  • drainReceiptQueueAndRefreshCustomer() for explicit receipt queue recovery and refresh

​
Wrapper parity note

Some hybrid layers expose quietSyncPurchases() for parity. On native Android app code, the core contract you should reason about is restore vs sync vs explicit queue drain.

​
Pending and retried receipts

AppActor keeps receipt posting state locally and can retry queued items. That means:
  • a purchase can succeed in Google Play but still need backend confirmation work
  • deferred or pending purchase resolution can arrive later
  • receipt pipeline callbacks are better diagnostics than inferring status from UI alone

​
Recommendations

  • keep restore on a clear user action, usually a settings or account screen
  • use sync after identity transitions or when you want a silent catch-up
  • reserve queue-drain calls for advanced repair flows, debug tooling, or explicit stale-queue recovery