6

Which response status code(s) will the Google Play In-App Billing Serv{ice,er} V3 return upon a network timeout condition? Is this uniform amongst all of its functions?

class stacker
  • 5,357
  • 2
  • 32
  • 65
  • I also faced similar issue. Please Check my problem. http://stackoverflow.com/questions/16495510/iab-error-you-already-owned-this-item – John Nash May 11 '13 at 15:33
  • @YanLinAung I guess whether one sees your issue as a "similar issue" depends on the perspective. ;) – class stacker May 12 '13 at 14:39

1 Answers1

8

I will describe my findings here. I have tested this on an AVD with a fully featured GP installed (GP Store V3.10.10, GP Services 2.0.12, G Services Framework 4.1.2), by pulling the host's plug.

  • The getPurchases() method returns a cached result if possible (please note that we're not talking about a cache outside of the Service here but a direct call of getPurchases). Of course, this means that one will almost always get a cached result except when the Service is being re-initialized due to the loss of local data -- a case which is not very likely and often needs not be treated in special ways on the application level.
  • The consumePurchase() method will return the integer value 6 (BILLING_RESPONSE_RESULT_ERROR) after a presumed internal net timeout of 20 seconds (so add a bit of time until the result code is seen by the caller). I was suspecting this despite BILLING_RESPONSE_RESULT_ERROR being described as a Fatal error during the API action because no other error code would make sense here; unfortunately, the word fatal is still somewhat inappropriate for a temporary condition such as a timeout.
  • getSkuDetails() appears to behave just like consumePurchase(). Update: There's now evidence that getSkuDetails() can access cached information within the local service, too.
  • It looks as if getBuyIntent() works fine without connectivity if the item is already known to the service. This explains why Hartok sees a blank GP purchase screen: It's not a problem to get a buy intent from the IAB V3 without connectivity.

Conclusion: The In-App Billing Service V3 appears to work with an internal cache and a server connection timeout of 20 seconds. For server communication errors which the local cache cannot resolve, response code 6 is used.

class stacker
  • 5,357
  • 2
  • 32
  • 65
  • So what happens if my local cache and server are out of sync? For example, I consistently get the "You already own this item" dialog, even though getPurchases is not returning the item it says I own? – Vic Vuci Jul 15 '13 at 17:58
  • @Vee You are referring to an app ypu wrote yourself, right? If so, do you use the Google example code? (Hint: It is not robust.) I'm not sure where the "you already own this" dialogue comes from; if it is being displayed by the Google Play online part, then there's probably a problem with the Google Play Services cache on your device; erase the local data of that service. If the dialogue originates from Google Play IAB example code, then that would be a different story -- as far as I recall, it does an _additional_ caching based on the validity time stamps. Post more details if required. – class stacker Jul 20 '13 at 08:22
  • @Vee One [finding regarding the Google Play IAB example code not being robust](http://stackoverflow.com/a/14935976/1856738); it relates to another aspect but I wouldn't trust code which does not check for such an important error condition. – class stacker Jul 20 '13 at 08:27
  • Yes, I did not use Google's example code at all and mine is quite robust. I handle every single error, and even false errors (such as backgrounding DURING a purchase giving me a bad activity result) However, as you mentioned, its a problem with the google play services cache. The correct solution is to either wait or clear the local data of that service, _however_, I can't do that from within my app. – Vic Vuci Jul 23 '13 at 16:16
  • 1
    @Vee Yes. It's a bit sad that Google tries to protect their servers from this bit of load, or whatever the rationale may be. They could sync every once in a while despite time stamps while connectivity is good... it would improve user experience. – class stacker Jul 23 '13 at 18:36