Skip to main content

Hello,

 

We are experiencing consistent crash after a test subscription purchase in our Android app.

The purchase first seemed to be successful, but after a short time, the first crash occurs and the crash message appears every 30 to 50 seconds from the background.
Also, re-launching the app also crashes after the purchase(the purchase might have triggered something).

 

Here is the crash log:

23:38:39.533 26296-26521/? E/AndroidRuntime: FATAL EXCEPTION: Thread-12

    Process: com.company.app, PID: 26296

    java.lang.NoSuchMethodError: No virtual method getSku()Ljava/lang/String; in class Lcom/android/billingclient/api/Purchase; or its super classes (declaration of 'com.android.billingclient.api.Purchase' appears in base.apk)

        at com.revenuecat.purchases.google.PurchaseDetailsConversionsKt.toRevenueCatPurchaseDetails(purchaseDetailsConversions.kt:16)

        at com.revenuecat.purchases.google.BillingWrapper.toMapOfGooglePurchaseWrapper(BillingWrapper.kt:401)

        at com.revenuecat.purchases.google.BillingWrapper.access$toMapOfGooglePurchaseWrapper(BillingWrapper.kt:51)

        at com.revenuecat.purchases.google.BillingWrapper$queryPurchases$1.invoke(BillingWrapper.kt:387)

        at com.revenuecat.purchases.google.BillingWrapper$queryPurchases$1.invoke(BillingWrapper.kt:51)

        at com.revenuecat.purchases.google.BillingWrapper.withConnectedClient(BillingWrapper.kt:565)

        at com.revenuecat.purchases.google.BillingWrapper.queryPurchases(BillingWrapper.kt:363)

        at com.revenuecat.purchases.Purchases$updatePendingPurchaseQueue$1.run(Purchases.kt:1677)

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:459)

        at java.util.concurrent.FutureTask.run(FutureTask.java:266)

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:301)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)

        at java.lang.Thread.run(Thread.java:764)

 

Our test device is Galaxy S8 using Android version 9.

Could this be a backward compatibility issue from RevenueCat SDK?

 

Thanks.

Hello @Jinpyo Hong ,

What Purchases SDK + version are you currently running on? Are you using an emulator or a physical device? Are you able to reproduce this issue in our Native Android sample app? Crashes can also happen due to conflicts between RevenueCat and another plugin. If you are using other plugins, have you tried removing some to test if the crash still occurs?


Hello @Jinpyo Hong ,

What Purchases SDK + version are you currently running on? Are you using an emulator or a physical device? Are you able to reproduce this issue in our Native Android sample app? Crashes can also happen due to conflicts between RevenueCat and another plugin. If you are using other plugins, have you tried removing some to test if the crash still occurs?

 

Hello, thank you for your reply.

 

We are using the most recent SDK version 4.3.1 and ran it on physical devices.

As you have mentioned, it turned out that another dependency has caused the crash, so after removing the following, it works fine :)

dependencies {

    def billing_version = "4.0.0"

 

    implementation "com.android.billingclient:billing:$billing_version"

}

 

Thank you!


Hello @Jinpyo Hong ,

What Purchases SDK + version are you currently running on? Are you using an emulator or a physical device? Are you able to reproduce this issue in our Native Android sample app? Crashes can also happen due to conflicts between RevenueCat and another plugin. If you are using other plugins, have you tried removing some to test if the crash still occurs?

Hello Tina,

I got this issue when I migrated an old subscription that used flutter_inapp_purchase, 
I checked flutter_inapp_purchase uses billing version 3, and Revenuecat uses billing version 4
How can I resolve this issue?

Thank you


Hey @BG37 

Do you still have the flutter_inapp_purchase in your app alongside the RevenueCat SDK? Have you removed dependencies that may conflict with RevenueCat?


Hey @BG37 

Do you still have the flutter_inapp_purchase in your app alongside the RevenueCat SDK? Have you removed dependencies that may conflict with RevenueCat?

Hello @tina The problem is v4 have some changes with v3:

  • Added Purchase#getSkus() and PurchaseHistoryRecord#getSkus(). These replace Purchase#getSku and PurchaseHistoryRecord#getSku which have been removed.

  • Removed BillingFlowParams#getSkuBillingFlowParams#getSkuDetails and BillingFlowParams#getSkuType.

I have to keep flutter_inapp_purchase to migrate subscription info to revenue cat. 
But flutter_inapp_purchase use getsku, and revenuecat use getskus,
So I am afraid that if I remove one of the billing versions in grade.


It very helpful if RevenueCat have function that Get all purchases made by the user


Hey @BG37 

Got it, since you’re still relying on flutter_inapp_purchase, you would have to use an older version of the RevenueCat SDK that uses Billing Client version 3. We updated the SDK to use BillingClient 4.0.0 in Android SDK version 4.3.0.

 

We have a client side migration that’s in the docs, worth checking out if you haven’t seen it already: https://docs.revenuecat.com/docs/migrating-existing-subscriptions#client-side-migration If you’re able to keep track of customers opening the version of the app with RevenueCat for the very first time, you can remove flutter_inapp_purchase and call syncPurchases upon the very first app launch with the RevenueCat SDK. 


Hello @tina ,

Maybe I have to wait flutter_inapp_purchase update blling v4.

Or Can I Using the REST API to send my old subscription information to RevenueCat?

I read the document, but still don’t know to get "fetch_token": "MQABC...EFH1234="

Thank you


Hey @BG37 

Sorry for the delay. I was thinking through this a bit more and there could be issues using both RevenueCat and flutter_inapp_purchase since we both react from the transaction queue. Another option would be to put RevenueCat in observer mode to be access charts, webhooks, integrations, etc without affecting your current purchase code. Once you’re ready to sunset the old purchasing logic, you can switch over to a full implementation of RevenueCat. 

 

You can perform a migration through the POST /receipt endpoint in the API documentation. The fetch token is what Android delivers to the device when a purchase has been made. Unfortunately there doesn’t look like there’s an Android API to fetch these tokens, but they had to be stored when the purchase was made. 


I was facing the same issue and @tina ‘s answer did it. Specifically I had been using the official flutter in_app_purchase plugin. I had to block out the ff:

ChangeNotifierProvider<xxxxCounter>(create: (_) => xxxxCounter()),
ChangeNotifierProvider<IAPRepo>(
create: (context) => IAPRepo(context.read<FirebaseNotifier>()),
),
ChangeNotifierProvider<xxxxPurchases>(
create: (context) => xxxxPurchases(context.read<xxxxCounter>(),
context.read<FirebaseNotifier>(), context.read<IAPRepo>()),
lazy: false,
)
 
Note: the xxxx represents the initial part of the naming of my class. It can be anything in your case
 
 
 

Reply