I'm new to flutter. I want to check if user already has active GP subscription when my app starts.
In native I could use 'queryPurchasesAsync' for that, and I could check sub status even in offline-mode (Google Play cache).
But in Flutter I have only purchaseStream with purchaseDetailsList. It works after making purchase, but after restarting the app (even if I use InAppPurchase.instance.restorePurchases()) purchaseDetailsList length is 0 even though the subscription is active.
The package documentation lists all the examples except this one, although this is needed for any application with subscriptions.
How can I fix it?
Related
I'm developing a react-native app that targets Android TV and tvOS. Using react-native-iap I've have successfully added support for Google Play inapp products and latest subscription model (billing API 5.0.0).
Purchase updates are received and handled perfectly well in all test scenarious except when I'm testing the "More payment options" flow, which expects the user to continue the purchase flow an another device. In this scenario the user is able to pick up the purchase flow from a desktop browser, or on an Android mobile device, and then choose to pay with "Slow test card approved after a few minutes". However, after completing the payment I can't see that we ever receive updates on PurchasesUpdatedListener. Calling RNiap.getAvailablePurchases() (equivalent to BillingClient.queryPurchasesAsync()) also returns an empty list!
Has anybody come across this issue before? Is it a development environment problem or does it happen for real/end users as well?
Worth mentioning is that meanwhile the "slow card payment" is being processed I'm also exiting the purchase UI on Android TV (by pressing back button), in order to re-activate the app so it can check for purchase updates.
I was able to reproduce this problem with Google's sample app TrivialDriver, https://github.com/android/play-billing-samples/tree/main/TrivialDriveKotlin, so I don't think there's an issue with react-native-iap.
Thanks!
I had published an app on Google Play. According to me I need to change the versioncode in the gradle file everytime I upload the new APK and from there, Google Play does the job of notifying the users about an available update. I am in touch with many real world users who say they never got a notification about app update despite the several updates I had published to the original app. I know that there are certain device level play-store settings such as "Update app only on wi-fi" etc. and I've verified all such combinations of scenarios. I still believe that all the users are not notified about the new version available. So my questions are
1) Am I missing anything in the first place?
2) What are my options to make sure the user gets notified about the available update?
When you publish you app it takes some time(may be hours) to update world wide. So User's will not get immediately notified as soon as you publish.
It will also depend on the settings of playstore in user's phone and also the network user is using(i.e. wifi or data).
I have also faced this issue. When I checked for updated version, I did't get it but when I cleared data of playstore from my application settings and force stopped app and then reopened it and I was able to see the updated version.
So from your side you are not doing anything wrong. It's job of playstore plateform.
Only the thing which sometimes happens with the developers is that we continuously use our device to run app by using USB debugging and then we publish our app to playstore. And then we wait for update notification but we will not get notified as the versions in our device and on playstore are same.
I'm stuck with Google In App v3 - I tested a purchase without consumption (e.g. when app crashes between buying and consuming) - now I don't find a way out.
If I try to buy again, it says 'you already own that item'. But when I test for ownership, it says I don't own it:
Inventory inv = mHelper.queryInventory(false, null);
inv.getPurchase(sku); // null
inv.hasPurchase(sku); // false
I can't consume something either, as I don't have a purchase to consume. How to proceed here?
EDIT
Reproduce it like the following: purchase in-app consumable, then disable internet connection. After that, you're not able to purchase the product again for some hours. Just tested with a popular app from the play store (Diamond Digger Saga), I had the exact same behaviour. Is there really no possibility to avoid/solve this?
I ran into this exact problem. I had two Google accounts on the phone, one which was the developer account (which I foolishly used my personal account for) and another which was the test account I registered in the developer console. I had removed and re-added the developer account from my accounts on the phone, which allowed me to make test-purchases from my app, thinking if the developer account was the second on this list it would use the first for purchases.
Alas, after a couple of runs of the app I ran into your issue. I gave up trying to have both and removed the developer account from my phone. While incredibly inconvenient, this got rid of this problem and allowed me to test purchase, consume, query, etc.
If you are doing everything correctly and your code is ok - most likely the problem is in cached Google Play Services data.
For example when you make a test purchase on your device A - on your device B (with the same Google account logged in) you will keep receiving inventory without your purchase for some time. And your inventory.getPurchase(sku) will return null and inventory.hasPurchase(sku) will return false;
To fix this try to open Google Play and close it using Recent Apps button (click it and then swipe the app away) this will terminate the app faster than usual "back" button. Then turn your device off for couple of minutes.
Our goal here is to make Google Play to update it's cache.
Be sure that you're on wifi because it may update rarely if you're on mobile data.
Eventually data will be updated and you will get your purchase.
In my case it happened after 5 minutes or smth.
On Android I think that you can 'unpublish' an application so that no new users can download the application but that the user who already have the application will recieve new versions that are uploaded to google play (or so it seems to say here: https://support.google.com/googleplay/android-developer/answer/113476?hl=en&ref_topic=3450986 )
However I can't find any information on iOS. Can I remove the app but still update existing customers with a new version?
Just for context the update I want to issue for both OS is basically an app which displays a 'app is now closed' message.
Any help would be gratefully received.
Can I remove the app but still update existing customers with a new version?
As far as I am concerned, you can't do this in the App Store.
No, this isn't possible. Once you remove the app, nobody will see it in the app store. Existing users of the app won't see any updates that you may have published before removing it that they never installed. It's just gone if you remove it from the app store.
You could publish an app update that includes some kind of notification system within the app, and keep that in the store long enough for most users to upgrade. Then after you pull the app from the store, you could update this message (presumably it would retrieve this message from your server) to state that the app is no longer available, and maybe direct them to whatever you have that you're replacing it with (assuming you're replacing it). Otherwise, I don't see why you necessarily need to inform existing users that you've removed the app. If there are server-side components that it accesses, and you're shutting those down, I guess the app will simply cease to function for existing users.
I also don't think there is a way to offer updates without new customers being able to buy the app.
Why not increase the price of the app to the highest price allowed in the app store, so that no one will buy it? That way you can offer an update for your existing customers, but effectively stop new sales. If the new price is $1999.00 US, I doubt if you will get any takers...
Some people trying to do in-app purchase within my Android game report that they can never complete the purchase -- that they always get an error message. (I.e., The market app reports an error to my application, and I show the user this error.)
Unfortunately, I don't have any real log data for this one, because it only happens for certain customers of my game, not for me.
What's strange is that after updating to a new version of the app, for some users the problem goes away, and for some users the problem starts. So user A might have the problem in version 1 of the app, but it clears up when they update to version 2. User B might not have the problem in version 1, but it appears when they update to version 2.
I say "intermittent" above, but by that I mean that it only seems to affect a small number of users. But for any given user, once they get in this state, they seem to get the message all the time. HOWEVER, I have had some cases where the problem does clear up suddenly, without an app update. I'm not sure if, for instance, power cycling, or, say, making an in-app-purchase in another app is away to "break out" of this state.
I realize that without a specific error message or API call to name/blame, this question is difficult to answer. I'm just trying to understand if this pattern -- of some users mysteriously getting stuck in a state where they are unable to make any in-app-purchase within a given app -- sounds familiar to anyone for Google Play in-app-purchase.
Also, I build my apps on top of Marmalade, so it's possible that the problem is in the Marmalade layer, not in my app or in the Google Play market itself.
The same problem here: a lot of users can buy items in my app but some users send me emails complaining why they can't buy considering that they can successful purchase items in other apps. I think it occurs because of a temporary problem on the Google Play server or is something to do with the service on Android. I am still looking for an answer to this weird problem...