I'm experiencing a weird problem after we've submitted our first app on the Android Market. The app has a in-app purchasing feature which have been fully tested before the release (or at least I thought so).
I'm aware that similar questions might already exists, but I haven't found them and it's quite difficult to describe my problem with only a few words.
The problem appears when a user:
a) downloads our app from Android Market
b) opens the app after download through the OPEN link in Android Market
c) starts a purchase which takes the user back to Android Market.
d) either cancels or completes the purchase
Then:
Instead of returning to our app, the user returns to Android Market (which displays an description of our app with a button to open the app etc). In the LogCat an Response Code is sent from Android Market to the Purchase Observer, but our app (now being in the background) doesn't receive the code and therefor stalls, forever waiting for a response from Android Market. So it's actually two problems, because it's not intentional that the user should return to the Android Market screen after purchasing - our app should be before Market in the history.
Everything works correctly if the user opens our app outside Android Market (e.g. the Home screen). The observer receives either the cancel or complete Response Code.
We've used Google's own In-App Billing example as our foundation.
I hope this is somewhat understandable.
Thanks in advance
All right, I finally found the answer myself.
I'll try to explain the solution without using any code :)
The PurchaseObserver instance is only available when my activity is active - but it's not active, in the example described above. I made the mistake to think that the PurchaseObserver is where the order should be saved in the database - only to find out that you cannot be certain that the PurchaseObserver exists when a purchase is made. Instead, I now only use the Observer to change the UI and then handle the order information and the database through the ResponseHandler, which always gets called when an purchase has been made in Android Market.
I still think it's odd the user gets thrown back to Android Market instead of our app when an purchase is made (only when the user starts the app through Android Market), but I cannot seem to find an solution or explanation for this.
This is btw impossible to test or reproduce the problem, without having the app on Android Market - so I hope this explanation can help you guys not make the same mistake I've made ;)
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 have an Android app and I also offer 1 inapp purchase to unlock such app to the Pro version.
I know how to do use the inapp purchase API and such but I found discordant ways on how to check if the app should start as Free or Pro.
Many people suggest that after a successful purchase the app should store the Google Play receipt or other information in a local database and let the app check the presence of that information at startup (in order to start properly as Free or Pro)
My question is, instead of bothering saving the purchase information and retrieving it from a local database why not calling the restore purchase API RestorePurchases(), have a look at the returned object if the InApp item is present and unlock the app accordingly?
As far as I know the call doesn't require internet connection, it's just a local call to the local Google Play authority... am I missing something?
Let me explain how we manage it at QuitNow!, an app with the same behavior than yours.
We only have one SKU called unlock_all_pro_features. If the user has it, it means that the user bought the PRO features before.
So, in the Android side, everytime the app is started we try connecting to IInAppBillingService. When onServiceConnected() is called, we ask it for all the user owned SKU's. If it has our lovely SKU, we store in a SharedPreference that the user was a PRO one. And then, if it wasn't PRO before doing all this magic, we update the screen to show the brand new features.
Bad things there: the user can return the SKU!
To face that, when we consider that a user was a PRO one, we also ask if the user has the needed SKU. If that check fails 20 times, we reset the features to the FREE version.
Why checking it 20 times instead of just one time? Sometimes, we found that the service said that the user had any SKU, while he actually had the PRO one. Why? Don't know. So, checking it 20 times is a simple way to assure that we don't kick PRO users when unneded.
I have created a test build of a GDK Glass app that I want to deliver to a few test users. However the app disappears after a reboot. Logcat shows this:
08-19 18:18:18.256: I/GlasswareSyncAdapter(978): Uninstalling Glassware ID #6DBADA7634397F00 (com.example.demo).
A look at the issue tracker explains that this is caused due to the fact that the MyGlass app didn't install this app and that the app thus isn't linked to the user's account.
Are there any workarounds? With a submission process of over a month how can we get our app tested properly?
The submission process should be less than a month at this point. I suggest that once you think you have things working, you submit the app.
Once submitted, you'll be working with the Review Process Team. They are able to create a whitelist (certainly of accounts, and possibly based on a list you can control through a Google Group) of who will be able to see the app on their MyGlass page. This will also allow you to test the app, including the auth flow, using the actual installation process.
It seems like this issue only occurs when the application you are side loading has been submitted to Google for approval. Just change change the package name of the APK you want to sideload and your problem should be solved.
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...
My app is having success in Google Play with several million downloads. However, almost 50% of users have uninstalled it already.
I don't think that's a critical number but I'd like to find out why users uninstalls it, so I'd like to ask it to users using a simple form, only to the ones who want to answer of course.
Now problem is when to show that optional form. I've seen I can't use ACTION_PACKAGE_REMOVED because app that's being uninstalled won't receive that broadcast.
Of course I don't want to ever forbid the user to uninstall my app, but I do want to know when to start my optional form. Can you think of any idea how to do this?
Also, I've seen that Google Play asks the user why he's uninstalling any app and gives a few options (missing space, don't need it, ...). Is there any way to get those responses from Google, regarding my app?
If you can give me any other ideas how to investigate main reasons why users uninstall my app, to improve it, I'd be really thankful.
Once the user uninstalls the app, there's nothing you can do. 50% retention rate isn't actually that bad..
I would propose you look at how the users are using the app, whether it's crashing and how often it's being used: these can then lead as indicators to make an educated guess why they might be uninstalling your app.
Crashes:
These aren't always reported - it's only if the user elects to report it you'll see it in Google Play. Try Crashlytics for a more detailed analysis of how/when/why your app crashes.
Analytics:
I use Flurry to log events and work out what my users are doing. You could also look in to some A/B testing.