Acknowledge Galaxy Subscription Purchases by fire-at-will · Pull Request #2939 · RevenueCat/purchases-android

fire-at-will · 2025-12-15T19:47:53Z

Description

Adds support for acknowledging Galaxy subscription purchases.

fire-at-will · 2025-12-15T20:07:48Z

-        """.trimIndent()
-
-        return ProductVo(json)
+        return mockk<ProductVo>(relaxed = true).also { productVo ->


I started having some issues instantiating ProductVo and PurchaseVo directly, so I decided to mock them out instead

tonidero

Looking good! Just some comments but almost there!

tonidero · 2025-12-16T07:41:04Z

+            clearInFlightRequest()
+            onError?.invoke(purchasesError)
+            return
+        } else if (acknowledgementResults.count() > 1) {


Hmm so I guess you can acknowledge multiple purchases simultaneously? Interesting... but yeah I think it's fine to do one per request as we're doing now, so I imagine this should never happen indeed 👍

Yeah, you can acknowledge/consume multiple purchases at once. In fact, their docs even strongly recommend that you don't acknowledge them serially:

We recommend reporting purchased consumable items immediately after verifying their purchase and reporting all unreported products in one consumePurchasedItems() or acknowledgePurchases() method call in order to avoid system overload or malfuction.

However, our system is only architected today to handle acknowleding/consuming one purchase at a time - see the BillingAbstract.consumeAndSave function's signature:

abstract fun consumeAndSave( finishTransactions: Boolean, purchase: StoreTransaction, shouldConsume: Boolean, initiationSource: PostReceiptInitiationSource, )

I think that this is okay for the purchase scenario - the Galaxy Store doesn't have multi-line subscriptions, so only one purchase should go through at a time. The only case I can think of where we might have multiple to do at once is in a restore scenario, or maybe when multiple distinct POST /receipt requests have failed, and the SDK needs to re-POST receipts. Even in that scenario though, we'll be calling this endpoint serially, so I think it should be fine, what do you think?

Yeah, I think it should be fine... probably worth seeing how it behaves in the wild though, hopefully it's not rate limited on their side 😬

cc @MarkVillacampa this might be a good thing to ask the Samsung team

tonidero · 2025-12-16T07:45:12Z

        initiationSource: PostReceiptInitiationSource,
    ) {
-        warnLog { "Unimplemented: GalaxyBillingWrapper.consumeAndSave" }
+        if (!finishTransactions || purchase.type == ProductType.UNKNOWN) return


In these cases, I think we should still call addSuccessfullyPostedToken so we're not posting the same tokens over and over? As long as it's not in a pending state though.

It looks like we aren't calling addSuccessfullyPostedToken for UNKNOWN product types on the the Amazon or Play Store today:

Google:

purchases-android/purchases/src/main/kotlin/com/revenuecat/purchases/google/BillingWrapper.kt

Line 469 in d67337a

if (purchase.type == ProductType.UNKNOWN || purchase.purchaseState == PurchaseState.PENDING) {

Amazon:

purchases-android/purchases/src/main/kotlin/com/revenuecat/purchases/amazon/AmazonBilling.kt

Line 227 in d67337a

if (!shouldFinishTransactions() || purchase.type == RevenueCatProductType.UNKNOWN) return

Where those two stores differ is whether they call addSuccessfullyPostedToken in observer mode 😅

We don't for Amazon

We do for the Play Store

I think Amazon is wrong in this case... If we don't add it, we will be posting the token on every app open I think?

Yep, I believe you're correct 😅 I'll add the token for the Galaxy Store for both UNKNOWN product types and when observer mode is enabled

Updated in 7dbaab9 to store the token when the product type is Unknown or when observer mode is enabled 👍

tonidero · 2025-12-16T07:53:58Z


+    @Test
+    fun `consumeAndSave does nothing when finishTransactions is false`() {
+        val wrapper = spyk(createWrapper())


Hmm not a super fan of creating a spy just to verify that a method of the class we're testing is not called... I think the proper thing to do would be to verify whether the expected side effects (in this case, calling the IAPHelper consume/acknowledge methods are not called)

Removed the spies from the tests here! 🚫🕵️‍♂️

d45f206

…known

fire-at-will · 2025-12-16T20:32:06Z

@tonidero Since your last review, I've made the following changes to this PR:

GalaxyBillingWrapper.consumeAndSave only handles acknowledging subscriptions. OTPs are no longer consumed or acknowledged. I kept a backup of the old code so implementing this behavior will be easier in the future :)
- This includes removing the ConsumePurchaseHandler and associated code
GalaxyBillingWrapper.consumeAndSave adds the purchase token to the cache's list of successfully posted tokens when finishTransactions is false or when the purchase's product type is UNKNOWN
Fixed the bug where we wouldn't call the onError closure in AcknowledgePurchaseHandler. Added a unit test to ensure that it gets called :)
Reworked those GalaxyBillingWrapper tests to not use a spy

tonidero

This looks good to me!

tonidero · 2025-12-17T08:25:05Z

+    private val deviceCache: DeviceCache,
    val billingMode: GalaxyBillingMode,
-    private val iapHelperProvider: IAPHelperProvider = DefaultIAPHelperProvider(
+    private val iapHelper: IAPHelperProvider = DefaultIAPHelperProvider(


I'm wondering if we should call it IAPHelperWrapper instead of Provider... but that should probably be in a separate PR.

tonidero · 2025-12-17T08:48:30Z

    }

-    override fun onGetProducts(error: ErrorVo, products: ArrayList<ProductVo>) {
+    override fun onGetProducts(error: ErrorVo, products: ArrayList<ProductVo?>) {


It's quite interesting this can return a nullable product list... Any idea in what scenarios this would return a list with null elements?

I cant' think of any scenarios where this list should contain null elements, but because of the way that the function's signature is written in Java, it's a scenario that is allowed by the API. The signature in Java looks like this:

public interface OnGetProductsDetailsListener { void onGetProducts(@NotNull ErrorVo var1, @NotNull ArrayList<ProductVo> var2); }

var2 is marked as @NotNull, which means that var2 itself is not null, but it doesn't guarantee that the objects inside the list are non-null. In fact, when we use Android Studio's auto complete to write the function, it includes the ? on the ProductVo. If we didn't mark ProductVo as optional in this signature, I think that we would get a crash when the code bridges from Java to Kotlin if there are any null elements in the list 😬

I realized this while working on the acknowledgement listener, which also receives an ArrayList of nullable objects, so I went back and fixed it here before I forgot about it :)

Oh right 😓 Makes sense. thanks for explaining!!

fire-at-will added 2 commits December 15, 2025 13:38

consume/acknowledge purchases

3c7f905

remove import

5c3a572

fire-at-will requested a review from a team as a code owner December 15, 2025 19:47

fire-at-will added the pr:feat A new feature label Dec 15, 2025

fire-at-will added 7 commits December 15, 2025 13:50

rename

44abcee

rename

c739ccb

GalaxyConsumeOrAcknowledgeStatusCodeTest

6a8cbd2

string update

65957bf

string update

3c42330

string update

8cb5f4e

comment update

5934621

fire-at-will commented Dec 15, 2025

View reviewed changes

Delete kotlin-compiler-13423068704887426175.salive

3019082

fire-at-will requested review from MarkVillacampa and tonidero December 15, 2025 20:09

tonidero reviewed Dec 16, 2025

View reviewed changes

fire-at-will added 3 commits December 16, 2025 10:36

dont consume/ack OTPs

b8f795a

call onError when acknowledging is unavailable

2a37f1d

removed spies from test

d45f206

fire-at-will changed the title ~~Acknowledge & Consume Galaxy IAPs~~ Acknowledge Galaxy Subscription Purchases Dec 16, 2025

fire-at-will added 2 commits December 16, 2025 14:24

cache purchase token when in observer mode or when product type is un…

7dbaab9

…known

detekt

e46c946

fire-at-will requested a review from tonidero December 16, 2025 20:29

tonidero approved these changes Dec 17, 2025

View reviewed changes

Merge branch 'samsung-dev' into acknowledge-purchases

96a875f

fire-at-will merged commit 62f6c26 into samsung-dev Dec 17, 2025
0 of 2 checks passed

fire-at-will deleted the acknowledge-purchases branch December 17, 2025 13:58

Conversation

fire-at-will commented Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tonidero left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fire-at-will commented Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tonidero left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fire-at-will Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

fire-at-will commented Dec 15, 2025 •

edited

Loading

fire-at-will commented Dec 16, 2025 •

edited

Loading

fire-at-will Dec 17, 2025 •

edited

Loading