Skip to main content

I use com.android.billingclient:billing:4.0.0 on my application and purchases_flutter 3.10.0 for the revenuecat subscriptions.

From May 2022, users can't see the free trial or intro price options. Then, I messaged the GooglePlay and they replied as below:

Hello Google Play Developer, Due to a bug in our system, since May 3, 2022, you may be experiencing incorrect or missing subscription information in the results from the Google Play Billing library’s deprecated querySkuDetailsAsync() function. During this time the Google Play Billing library may not have returned information to your apps about free trial and intro price offers for one or more of your subscriptions, even if the user was eligible for these offers. In these cases, users only saw the subscription base plan in the purchase cart, without any free trials or intro prices.

Action Required

We recommend that you review all of your subscriptions with free trial and intro price offers in the Play Console, and ensure that the correct offers are active and marked as backward compatible. You can learn more about backwards compatibility here.

If your app uses the queryProductDetailsAsync() function instead, this is not impacted and you do not need to take any action.

 

Then, I wanted to try migrate blling library from 4.0.0 to 5.0.0. However, after the migration, I got the following error and app crashed.

E/AndroidRuntime( 4198): java.lang.NoSuchMethodError: No virtual method queryPurchases(Ljava/lang/String;)Lcom/android/billingclient/api/Purchase$PurchasesResult; in class Lcom/android/billingclient/api/BillingClient; or its super classes (declaration of 'com.android.billingclient.api.BillingClient'

Could anyone help with the solution?

We're working on updating our SDKs for compatibility with Billing Client 5.0. There have been some changes in the way Google subscriptions work so we still need to make some changes across our services.

In the meantime, our SDK currently uses Billing Client 4.0 and it’s not possible to use it alongside BillingClient 5.

We wrote a post about the Google I/O announcements and Billing Client 5 which might help provide more context here.

Everything that's marked as "Backwards Compatible" in the Play Console works with our SDK.

We were not aware of that Google’s bug so thanks for letting us know, we’ll keep an eye for more reports about it.


Hey @ALP KIZILTAN 

We're working on updating our SDKs for compatibility with Billing Client 5.0. 
 
In the meantime, our SDK currently uses Billing Client 4.0. The Billing Client is a transitive dependency on the SDK, so you should only need to install our SDK and don't need to manually manage the Billing Client version.


Hey @Cesar is there a timeline for this migration update or should I just revert my client to 4.0 and wait?


@Alberto Arciniegas  +1 . I alo wonder this update


We are actively working on it and we can’t provide an ETA yet. There have been a lot of changes on the way subscriptions work that require us to also change our backend and configuration dashboard in order to support BillingClient 5 and the new subscription system. I am sorry we can’t provide a more specific answer but we are still trying to figure some things out.

I would revert your client to 4 until further notice.

cc: @AnnaToro 


have you change build.gradle ,the billing version?

 


To clarify, in order to get this to work at all right now we need to use:

implementation 'com.revenuecat.purchases:purchases:4.6.1'

… instead of any of the 5.x.x implementations?

Is that correct?


To clarify: our SDK version 5.x.x still depends on `com.android.billingclient:billing:` version 4. This dependency is automatically added to your project when including `com.revenuecat.purchases:purchases:` in your project and you don’t have to also declare a dependency on the billingclient. Including our SDK will download the correct dependency that should be used along with it.

As of today, version 5.x.x of `com.revenuecat.purchases:purchases:` still depends on version 4 of `com.android.billingclient:billing:`. Version 5.x.x of our SDK is the one you should be using. We are working on updating our SDK version 5.x.x to depend on billingclient 5.


Removed


Is there any news on an ETA for billing v5 support since the last post a month ago?  
We use an SDK which uses a billing plugin created by a 3rd party, and they have just updated it to support billing v5. 
This means that we will not be able to use RevenueCat at all in our next update, so we’re eager to know when it is likely to be supported again.


Is there any news on an ETA for billing v5 support since the last post a month ago?  
We use an SDK which uses a billing plugin created by a 3rd party, and they have just updated it to support billing v5. 
This means that we will not be able to use RevenueCat at all in our next update, so we’re eager to know when it is likely to be supported again.

Hey @FlickGames, 

Unfortunately we can’t provide a specific target on the full implementation yet. However, it’s likely there will be an intermediary state where we can ship the SDK with billing v5 as the dependency version without full support of the new features. The team will have to discuss any potential side effects and risks of releasing in such a way -- I’ll post back here when we are done with that. If we can do such a release, it should be within a few weeks. 


@Maddie That would be great if it’s possible. We’re actually using the SDK in observer mode, so in our particular case we actually only need a handful of features:

  • configure
  • collectDeviceIdentifiers
  • logIn
  • logOut
  • syncPurchases

Perhaps that would make it easier to support an intermediary version.

Incidentally the docs for observer mode appear to be outdated, as they still show the old config function:

Purchases.configure(this, "my_api_key", "my_app_user_id", true);

rather than
 

PurchasesConfiguration config = new PurchasesConfiguration.Builder(final_context, appKey)
.observerMode(true)
.appUserID(userID)
.build();
Purchases.configure(config);

 


@FlickGames thanks for alerting us, will get those docs updated! And will keep you posted about the intermediate build. If you need to release in the meantime, one option is to use an older version of the other billing plugin that depends on billing client 4...but I understand that’s not always possible.


If you need to release in the meantime, one option is to use an older version of the other billing plugin that depends on billing client 4...but I understand that’s not always possible.

Unfortunately this is not an option for us. The other plugin updated straight from billing client v3 to billing client v5. 
If there’s no intermediate build by November 1st we will unfortunately be forced to drop RevenueCat as we would be unable to update the app until it supports v5.


If you need to release in the meantime, one option is to use an older version of the other billing plugin that depends on billing client 4...but I understand that’s not always possible.

Unfortunately this is not an option for us. The other plugin updated straight from billing client v3 to billing client v5. 
If there’s no intermediate build by November 1st we will unfortunately be forced to drop RevenueCat as we would be unable to update the app until it supports v5.

Hey @FlickGames just wanted to let you know we haven’t forgotten about this. We’ve been running through tests to understand how this could work..unfortunately, because of the changes on Google’s side with the BillingClient 5 update, we can’t do a quick “patch” to support everything in observer mode right away. 

What we probably can do (and this is pending confirmation in testing this week) is release a version that won’t support the new billing features. This means that if you have non-backwards-compatible subscriptions set up in the Play console (multiple offers, pre-paid plans), pricing will not be reported properly in observer mode.

This would be a temporary workaround to alleviate the dependency version issue, with full support coming at a later date. To be clear, the current implementation doesn’t support the new subscription features, anyway…

Out of curiosity, are you willing to share which plugin updated?


We don’t require any of the new subscription features at the moment anyway, so that wouldn’t be an issue for us.  
We use Solar2D (formerly Corona SDK) to build our apps, and the updated plugin was actually a migration from:  
https://docs.coronalabs.com/plugin/google-iap-billing/index.html
to 
https://docs.coronalabs.com/plugin/google-iap-billing-v2/index.html

(source https://github.com/solar2d/com.solar2d-plugin.google.iap.billing.v2)

Edit: If you need any help testing the intermediary SDK please send me a direct message and I’ll send any contact info you need. Thanks.


@FlickGames is there any chance on your side of dropping the google billing plugin from Solar2D? Does it cover anything our SDK doesn’t? 

A BC5-compatible version of RevenueCat is not easy to do, even if it doesn’t include the new features sadly. 

So there might end up being a gap between the time where Google stops accepting billing client 3 builds and RevenueCat releases a billing client 5 version. 

 


@Andy Honestly - I’m not sure it’s practical from our point of view, and I don’t think it’s unreasonable to expect a paid tool which is specifically designed for tracking billing information to support the latest public versions of the SDKs that provide that information. 

Surely a BC5 version was already in the pipeline, no? It’s the latest public release and has been since May, I wouldn’t class that as bleeding edge. Even if it was, this issue was initially raised over 3 months ago. Given that RevenueCat’s entire business model is “In-App Subscriptions Made Easy” it seems odd not to support the latest version in any way yet. 
The current status means that someone developing a new app which wishes to use RC is forced to use the previous version of the Billing Client, meaning they will have to update it in future. That seems to go against one of the reasons RC gives for using the service: “For Engineering: Simplify your codebase and never worry about updates or platform changes again”

The Solar 2D billing plugin is used by every Solar2D dev that has In-App Purchases, and so has a reliable base for testing and identifying issues in Solar2D apps which means it’s very reliable for us. Switching over to using the full RevenueCat SDK would mean rewriting the observer mode plugin that we previously made to include all of the transaction functionality, and most likely having to adapt our Lua code too to handle any differences in callbacks.   


We use (and in this case pay to use) 3rd party SDKs to save ourselves time and effort. Having to rewrite and test a critical part of our app’s functionality because RevenueCat doesn’t support the latest public release of the billing client doesn’t fit that remit. 


@FlickGames I agree with you, and BillingClient 5.0 support is our #1 item in the pipeline right now. I definitely feel your pain here, especially since you built your own plugin for observer mode support. 

 

There are a few factors in the way that BC5 is designed that have made implementing support for it rather difficult on our side, and we’re currently working through the issues to have something ready as soon as we possibly can. This year’s update was essentially a full redesign in BillingClient, with some choices that put barriers around revenue tracking that weren’t there in BC4. Not trying to make excuses here, just being transparent about the reasons we don’t have support out yet. 

 

We aim to have a version out as soon as humanly possible, but I can’t guarantee that we’ll have it out before Nov 1st.


Hey @Andy, do you have any update on this? We have a bunch of apps that we are planning to move to a subscription based model. Now it seems like RevenueCat is a blocker as new updates won’t be accepted as soon as we are introducing RC. Getting some pressure from stakeholders to sort that out but I can only point fingers towards you guys. Since I was a pretty big fan of your product so far it’s pretty disappointing and actually questions the reliability of RC for future projects and development...


@Patrick We’re still working on supporting Billing Client 5.0. I don’t have an ETA that I can share yet, sadly, we have quite a few people dedicated to this full time to try to deliver it as soon as possible. 

 

Do your apps also use Solar2D? If not, could you tell us more about why using Billing Client 4 for the time being would cause issues? I would like to understand every use case as much as possible. 

 

 


@Andy We are currently using the official Flutter in_app_purchases plugin for most of our apps using regular IAPs. We decided a while ago to move them towards subscriptions and moved our first app to RevenueCat some time ago. Now, with the code being in place, we would like to replace the regular one-time IAPs with subscriptions and that’s where the bottleneck ist. We are not using Solar2D to answer your question.


Hey there, is there any update regarding this matter or at least an estimate of how this is going? Would help me massively to manage internal pressure regarding this topic.


Hello Patrick, 

We are currently in beta with the native Android SDK and Hybrids will only come after our initial native release. We can put you down as a potential beta customer for Flutter for when we get there? 

Hopefully we can get there by the end of Q1. We are doing everything we can to provide you with a solution as quick as possible. 

Hopefully this helps a bit, let us know if there is anything else we might be able to help with. 

Anna

 


Hello Patrick, 

We are currently in beta with the native Android SDK and Hybrids will only come after our initial native release. We can put you down as a potential beta customer for Flutter for when we get there? 

Hopefully we can get there by the end of Q1. We are doing everything we can to provide you with a solution as quick as possible. 

Hopefully this helps a bit, let us know if there is anything else we might be able to help with. 

Anna

 

 

Hey Anna, if you have anything to help us here to get unblocked I would really appreciate that 🙂 So beta testing would be great!


Reply