I have an app that uses in-app purchasses. I have integrated all the code from the Dungeons example except for the UI components. I have submitted my draft apk, activated it, created my in-app purchases, all of which are managed, and published them.
I am successfully able to purchase my in-app items and unlock the corresponding content without issue. The problem I am running into is that whenever I call to restore transactions, I get back the error code RESULT_SERVICE_UNAVAILABLE. I know that the result code means that the app can't access the store, but that makes no sense seeing as I can purchase items just fine.
I am running on an HTC Nexus One with Android v2.3.6 and Google Play v3.5.16. I am connecting over WiFi because there is no data plan for the device. The apk installed is exactly the same as the draft apk submitted. I am installing the apk via adb -d install command.
Any suggestions of what might cause this or where to look would be greatly appreciated.
Thanks
if you find similar message in the log:
05-30 09:28:23.760: E/Volley(4636): [13] BasicNetwork.performRequest: Unexpected response code 429 for https://android.clients.google.com/vending/api/ApiRequest
it can mean that you've send too much RESTORE_TRANSACTIONS request in certain amount of time. Google has clearly some throttling on request. It happened to me during testing in-app billing, approx. 20-30 restore transactions request went ok, and then - exactly the same problem - service unavailable response.
Check logcat output, maybe there are some warnings there. Other than that, not 100% sure that RESTORE_TRANSACTIONS works with unpublished apps and test accounts. Maybe 'service unavailable' simply means 'not supported' in this case?
I had this same problem, and it turned out that the password on the primary gmail account on the device was wrong. So when I checked if billing was supported, I got RESULT_OK, but for restore purchases, I got RESULT_SERVICE_UNAVAILABLE.
Go into your gmail or any google apps and refresh. Double check that the account password is correct and try again.
This problem also shows up in logcat as
NotifyingErrorListener.onErrorResponse: Server error on InAppPurchaseInformationRequest: com.android.AuthFailureError: User needs to (re)enter credentials
This does mean that you've done too many RESTORE_TRANSACTIONS and the service won't be available for X number of days unfortunately, as I hit the same issue.
BUT... It is device specific, so if you start testing again on another device or factory reset your device, you should be able to avoid it.
Related
I just went live with my android app (Xamarin) -- and all my users are getting a -504 error when they try to install the application. Please help!
The app name is 'ControlTower' (the one with a tick symbol); can you tell me what I might have done wrong
Seems to download fine here. So I don't know who "all your users" are, but they might want to check this link: http://appslova.com/fix-android-504-error/
The error 504 code appears while attempting to download apps or games
in the Google Play Store. This is a gateway timeout error and is
generally associated with slower internet connections or mobile data
networks. Simple fix that worked for some is turning your mobile data
off and then back on. You can try it now by turning your Airplane mode
on and then off or by going to settings >> data usage>> turn off
Mobile data and turn it back on. Now try to download or update the app
via Google Play. If that didn’t work, some users have even solved the
Google Play Store error 504 by freeing some space in their android
device by uninstalling unwanted apps or games. If these Android fixes
didn’t work there are more to go in this post for “App” could not be
downloaded due to an error. (504)
Has more to do with the user's device than anything else. You say it just went live. It might have to fall through to all proxies and servers etc. So it might just be a small hiccup while going live on the app store.
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.
I am implementing realtime multiplayer game using Google Play Game Services. I am experiencing weird issues. My Google Account I am using for login gets randomly "banned" and is unable to communicate with Google servers for approx. 30-40 minutes. After that, everything is working well again. In the meantime I can use other accounts.
The response error I get from LogCat is this:
Unexpected response code 403 for
https://www.googleapis.com/games/v1/players/102515671693140579145
Access Not Configured
Unable to sign in - application does not have a registered client ID
This message is very misleading since everything is set up well. It works most of the time.
I have tried publishing the game and using test as well as non-test accounts. All of them get banned at some point.
Thanks for any help !
This behavior will occur if:
Current user is connected into any room and:
the app is restarted such that it tries to login to Google Services without having gone through the disconnect portion as required by Google Play Services.
I found this happened to me quite regularly (unfortunately for me) as I was figuring out how to pass messages between my Android code and LibGDX code side (my app would just Lock up due to synchronization issues). I also setup some test accounts that I could "cycle" through to avoid being completely locked out of logging in. However, I found out that if I used Task Manager to Kill the process before restarting the app, 90+ percent of the time, I could continue to use the same account.
If you are updating your code, and load to the device while you are in a Room, this will also earn you the server wrath for approximately 30 minutes for that account.
In short, to keep your account viable:
1) ensure you LeaveRoom prior to updating your code (I have found logging out of PS is not required)
2) If your app locks up... Killing the process via Task Manager (I use Samsung devices) will most likely let your account continue (you can see in the logcat where it calls the disconnect when you do that) when you start up the app again.
Hello and thanks in advance for your response.
I have my licensed app uploaded to the Play Store. I can test and get expected results with all of the static test license responses (Licensed, Not Licensed, etc). So far so good.
But if my test device has no internet connection, the license check ALWAYS fails. This is not how I understand the ServerManaged policy to work. If an install is found to have been licensed sometime in the recent past, the policy is supposed to cache information in a shared prefs file and use it if there is no internet connection.
So I temporarily commented-out the obfuscation of the data in the prefs file that the license system creates. When I look at the data, I see that the retry count and other stuff is set to zero. This is not what I expect. With data like this, it is behaving for me as if I were using a Strict policy (and I am not).
I am presuming that this is an artifact of using the test response system and that "real" users will get actual data in their obfuscated shared prefs that permits them to operate in the absence of an internet connection.
So I have tried setting the server response to "Respond Normally". When I do this, I ALWAYS get a NOT LICENSED response. And I guess this makes some sense because I have not purchased the app and downloaded it.
So how can I, as the developer, experience exactly what my end-users experience? I want to be able to test how this all works without an internet connection, for example. I cannot seem to figure out how to do this? I guess I could purchase my own app but I am not sure that will even work since the test device is logged into the test account. And it makes no sense for a developer to have to purchase their own app.
Thanks for any suggestions.
I think I found a possible solution to your problem.
What I have done:
first, I created a google group for alpha/beta testers of my app (after uploading the app, of course). Then, I ivited myself in this google group and accept the invitation. After this, I inserted my gmail developer account in the list of the users for the license test and set the server response to "RESPOND_NORMALLY".
In this way, the response of the server will be always "LICENSED" for my account, and the validity time will not expire in 2 minutes. It's as I had bought the app!
The only limitation to this trick is that you have to upload your app in a beta or alpha slot of your google developer console but, after this, you can also get a "LICENSED" answer using a debug app uploaded on your device using the usual Eclipse IDE! You don't have to wait for the generation of the link to download the test app (that is very slow to generate... Up to 24 hours!).
I too have experienced this frustration. I too want to have the same experience as my customers. As soon as I set 'Respond Normally' I always see the 'NOT LICENSED' response -- which seems VERY SUBOPTIMAL. I BELIEVE what Google needs to added is a setting of **'RESPOND_NORMALLY_AND_LICENSED'**. That would do what's needed.
The heart of the difficulty: if I leave my app as 'LICENSED' that works fine when I have an internet connection, then after 2 minutes with no connection, my app stops working as licensed (since the cache is set on the Google Play Server to 2 minutes). Thus if I want to use my own app day-in and day-out, I need to produce an app with licensing disabled --- something my customers never see. That's a VERY bad idea.
We all learned a long time ago: "You must eat your own 'dog food' as a developer."
I have reported this as a 'Developer Console' Bug, but it is perhaps instead of a 'Bug,' a very strong suggestion--and it would be seemingly be simple to implement.
As a work around, I have now added code in ServerManagedPolicy.processServerResponse() to simply add two months of time the licensed time and call setValidityTimestamp(). I hope this helps someone else. Now I am content ---
I'm testing out the billing sample application provided by google:
http://developer.android.com/guide/market/billing/index.html
Everything is going ok, I got up to the part where I wanted to try buying an actual item (one that I had listed myself). I gave it an id of "com.me.sword" for example. I'm logged in as one of my approved test accounts after a factory reset. The app is signed, everything else is good.
I go to purchase, and move into the marketplace app. I get prompted to add a new credit card, makes sense. After entering a real credit card, the purchase tries going through, but it then fails on the marketplace side. I get a dialog saying "Error retrieving Checkout information from server". DDMS shows:
D/Finsky(884): [1] CarrierProvisioningAction.shouldFetchProvisioning: Required CarrierBillingParams missing. Shouldn't fetch provisioning.
D/Finsky(884): [1] CarrierProvisioningAction.run: No need to fetch provisioning from carrier.
E/Volley(884): [13] BasicNetwork.performRequest: Unexpected response code 500 for https://android.clients.google.com/fdfe/purchase
W/Finsky(884): [1] CheckoutPurchase.onErrorResponse: DisplayErrorMessage[Error retrieving Checkout information from server.]
E/Finsky(884): [1] CheckoutPurchase.setError: type=UNKNOWN, code=-1, message=Error retrieving Checkout information from server.
I dismiss the dialog, then try to purchase again, and it goes through ok.
There was probably an error where the new credit card hadn't been validated yet? I'm wondering if this is common with marketplace, and if other bugs such as these:
http://groups.google.com/a/googleproductforums.com/forum/#!category-topic/android-market/technical-help/eVUoYEaUwSc
are still plaguing developers? It's kind of terrifying to go with google's billing system with these bugs - surely the average user is just going to blame us, the application developers, and we don't want to get any ratings/emails claiming that I charged their credit cards and the purchased items were never delivered.
Thanks
In-app billing has gotten better, but it is still not particularly reliable (almost a year since initial release). You should be ready to handle errors in your app. There is no way to know what the actual cause of this particular error is, but 'Unexpected response' hints at an unexpected error :) Presumably, handling (errors in) card validation should be expected and part of the purchase flow. Some other issues you may
encounter (this is not an official Market/Play bugtracker):
http://code.google.com/p/marketbilling/issues/list
Good luck :)