Skip to content

Show Android paywalls in-window so C# purchase controllers work - #15

Merged
ianrumac merged 4 commits into
mainfrom
ir/feat/android-in-window-paywalls
Oct 20, 2026
Merged

ianrumac merged 4 commits into
mainfrom
ir/feat/android-in-window-paywalls

Conversation

@ianrumac

@ianrumac ianrumac commented Oct 19, 2026 •

Copy link
Copy Markdown
Collaborator

Uses superwall-android 2.8.7, which ships the in-window host from superwall/Superwall-Android#481, and Google Play Billing 9.1.0 to match it (up from 2.7.23 / 8.0.0 on main).

Problem

On Android, a Unity game with a C# purchase controller hangs on the purchase spinner. SuperwallPaywallActivity covers UnityPlayerActivity / UnityPlayerGameActivity, and Unity pauses its player loop. The native SDK sends purchaseFromGooglePlay through UnitySendMessage, which only runs on Unity's main loop, so C# never receives it. X and back are blocked while the purchase is pending. Every other delegate callback (didPresent, TransactionStart, …) is also held until the paywall closes.

Changes

Paywalls in the game's window (default)

  • New SuperwallOptions.Paywalls.AndroidPresentation: InWindow (default) or Activity. The bridge maps it to superwall-android's PaywallOptions.presentationHost, and Configure without options also uses in-window.
  • Store.CUSTOM is mapped to "other" in the bridge.

Bridge hardening (separate commit)

  • If a purchase or restore request can't be sent to Unity, it fails at once instead of awaiting a reply that can never come.
  • When the native side gives up on a request, C# gets purchaseCancelled/restoreCancelled. isPurchaseControllerRequestPending lets C# skip a request that sat in Unity's queue after native abandoned it, rather than starting a store transaction with no paywall on screen.
  • A purchase controller that throws replies Failed, and each request is answered at most once. Late replies for unknown ids are logged instead of silently dropped.
  • No purchase timeout: store transactions can legitimately take minutes (pending payments, SCA).

Testing

Unity 6000.4, Android emulator API 30, Play test account. Report with screenshots and event timings.

  • Reproduced the hang in Activity mode: transaction_start, then nothing.
  • In-window, a real Google Play purchase through a Unity IAP 5 controller completes: C# gets the request 10 ms after TransactionStart, Unity IAP confirms the order, and the paywall closes with the game running. Verified on UnityPlayerGameActivity and UnityPlayerActivity.
  • Same events in both modes. In Activity mode C# gets them all on one frame after close (36 s late in one run); in-window, within a frame.
  • Fullscreen, Drawer, Modal and Popup; X, back, backdrop tap and drag-down.
  • BridgeContractTests cover the hardening paths.

…ests

- Native: if a purchase/restore request can't be sent to Unity, fail it
  immediately instead of awaiting a reply that can never come.
- Native: when the awaiting coroutine is cancelled, record the callbackId
  (bounded) and send purchaseCancelled/restoreCancelled to C#. Late replies
  for abandoned or unknown ids are logged instead of silently dropped.
- Native: expose isPurchaseControllerRequestPending so C# can skip a request
  that sat in Unity's message queue after native gave up on it, rather than
  starting a real store transaction with no paywall on screen.
- C#: reply Failed when the purchase controller throws, reply at most once,
  and don't report results for cancelled requests.

No purchase timeout is added: store transactions can legitimately take
minutes (pending payments, SCA).
Adds SuperwallOptions.Paywalls.AndroidPresentation (InWindow by default, or
Activity) and passes it to superwall-android's presentationHost. Configure
without options also uses in-window. Store.CUSTOM maps to "other".

Temporarily pins superwall-android 2.8.5-inwindow.4 from mavenLocal (also
added to the CI harness) until the in-window host is released.
@ianrumac
ianrumac marked this pull request as ready for review October 20, 2026 08:17
2.8.7 ships the in-window paywall host, so the mavenLocal() pin and the
CI harness repository are no longer needed.
@ianrumac
ianrumac merged commit 428cc85 into main Oct 20, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant