Bug- restore purchases android (could lead to app suspension)

BigDave

The Restore behaviour does not seem to connect to the Google Play Account of the user.

Test case:
1. The player has bought the non-consumable In-app.
2. The player uninstalls the App.
3. The player comes back and hits the restore button.
4. Nothing happens.
5. The player hits the in-app option again.
6. The player is told he can buy the in-app.
7. the player hits buy.
7. Google play tells him that he already has this item and that he can restore it for free.

Problem:
Most player will not try to re-buy the item to find out they can restore it.
The restore behaviour itself is none-responsive.

BigDave

@adent42
could you please look into that that could get all our android apps using in-apps, suspended

BigDave

And here you go:

http://bugs.gamesalad.com/show_bug.cgi?id=1860

gingagaming

How are you restoring the purchases Dave? By this I mean do you just have the restore purchase behaviour in a button (thats the clear bit) but also do you have the rules stating that if column 5 is purchased, award the purchase for free? I believe the restore purchase button just calls the store to get the data (and fills in column 5 for each ID). You still have to award the player for having column 5 populated as purchased like you did in the original purchase.

Personally I don't use the pre-made restore purchase behaviour. I simply put a Get Store Data behaviour in a restore button and when it returns a callback of 1, run the purchase rules looking for "purchase" in column 5 and award the purchase for free if present. This works perfectly fine.

BigDave

Thanks buddy
So if the Get store data behaviour would really do what you mentioned there, the in-apps would be unlocked immediately after opening the store section ( triggering get store data)

I do have the rule if column 5 is "purchased" outside of any other rule.
So if this would be the case through the get store data it should trigger this rule.

But that doesn't happen

BigDave

BigDave

You mentioned you wait for the result of the callback.

gingagaming

Make a build so you can see the contents of column 5 of the IAP in question and see how its populated when doing a "get purchase data" and see what its populated with.

Then make 2 buttons, one with get purchase data in and the other restore purchases in.

Then test in ad hoc and see which one populates the 5th column.

In previous tests, column 5 used to populate when triggering the purchase data. If its not now, then something may have changed. It maybe that you need to trigger purchase data first and when you get a callback of 1 then trigger the restore behaviour. But even then, you would needs rules to look for column 5 to then reward the user again. The store won't do this, it will just repopulate the column 5 as purchased. (but I can see you are already doing that)

BigDave

in any case these are work arounds and the behaviour itself is broken.

Armelline

I've successfully used the Restore behaviour many times on Android. There's definitely the possibility that Google changed something on their end, and the behaviour is indeed broken, but more testing definitely needs to be done to confirm that. What happens when you put the Restore button in a separate actor, triggered by Touch is Pressed?

DigiChain

I use the restore behaviour in a separate button as Armelline suggested, it all seems to working fine for me on android.

BigDave

ok sry. I close the bug it works also now.
it didnt work since I am the publisher...

BigDave

my bad..