Refactor lifecycle seams for reward verification locator

[polmiro]

Checklist

• If applicable, unit tests
• If applicable, create follow-up issues for purchases-ios and hybrids

Motivation

Provide the lifecycle infrastructure needed by the AdMob reward verification locator while keeping reward verification behavior implementation out of scope for this PR.

Description

• add PurchasesLifecycleListener and PurchasesLifecycleEventBus in :purchases to publish configure/close lifecycle events
• add PurchasesLifecycleListeners to centralize default lifecycle forwarding
• wire both defaults and custom-entitlement Purchases variants to notify lifecycle events on configure/close
• add RewardVerificationServiceLocator lifecycle hook registration/dispatch plumbing in feature:admob
• update locator dispatch to snapshot hooks under synchronization and invoke callbacks outside the lock
• add focused tests for lifecycle bus behavior, lifecycle wiring (defaults + custom entitlement), and service locator registration/dispatch + concurrency regression behavior
• keep reward verification setup/dispatcher/poller implementation out of scope for this PR

---

Note

Medium Risk
Touches core Purchases.configure/close wiring (defaults + custom entitlement modes), so mistakes could cause missed callbacks or ordering/concurrency issues, though behavior is covered by new unit tests and scoped to internal APIs.

Overview
Adds an internal lifecycle notification seam to purchases by introducing PurchasesLifecycleListener plus a synchronized PurchasesLifecycleEventBus that broadcasts configure and close events (including replaying the latest configured instance to newly-registered listeners).

Wires both Purchases.configure(...) and Purchases.configureInCustomEntitlementsComputationMode(...) to emit onPurchasesConfigured, and both Purchases.close() implementations to emit onPurchasesClosed before delegating to the orchestrator.

In feature:admob, introduces RewardVerificationServiceLocator that registers exactly once to the lifecycle listener and fan-outs lifecycle callbacks to a snapshot of registered hooks to avoid deadlocks/reentrancy issues. Adds focused unit tests for the event bus semantics, Purchases wiring, and locator concurrency/registration behavior.

^{Reviewed by Cursor Bugbot for commit 2b0b876. Bugbot is set up for automated code reviews on this repo. Configure here.}

[polmiro]

@tonidero this is a preliminary PR that implements the service locator in order to do clean ups for reward verifications. Let me know what do you think, hopefully its in the lines of what you were thinking about!

[cursor]

Event bus invokes listener callbacks inside synchronized block

Medium Severity

PurchasesLifecycleEventBus.onConfigured and onClosed are fully @Synchronized, invoking all listener callbacks while holding the event bus lock. This contradicts the PR's stated "snapshot under synchronization and invoke callbacks outside the lock" pattern applied to RewardVerificationServiceLocator. If any listener's callback blocks on cross-thread work that needs to call register/unregister on the event bus, a deadlock will occur — the exact scenario the locator's own test validates against.

Additional Locations (1)

• purchases/src/main/kotlin/com/revenuecat/purchases/PurchasesLifecycleEventBus.kt#L35-L45

 

^{Reviewed by Cursor Bugbot for commit 10bf442. Configure here.}

[polmiro]

If we want both properties (strict ordering + non-locking callbacks), that likely needs a larger redesign rather than local synchronization tweaks. Wondering how big of a concern is this and what are some possible lightweight ways to address it.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit ac9f91e. Configure here.}

[tonidero]

Hmm the part that I'm failing to see is how RewardVerificationServiceLocator is actually used/registered... I think this is indeed pretty close to what I meant, but to make it clearer, this is what I thought:

• The purchases SDK would add a Service interface and a "Purchase.registerService" static method (both marked as @InternalRevenueCatAPI). The Service interface would have initialize and close methods of some kind, possibly passing in the context, or whatever dependency is needed. I think what we're missing in this PR is the registerService-like method? In this PR, the Service is equivalent to the PurchasesLifecycleListener.
• The admob SDK can implement an instance of this Service with an initialize/close implementations that would actually perform the initialization/cleanup. We have this part mostly I think.
• The purchases SDK would call initialize/close where appropriate.

So basically what you have here is pretty close, but I'm just missing the part where this is actually "registered". Lmk if I'm missing something though! Just want to make sure we're on the same page.