NullPointerException in transaction() on iOS roboVM

Issue details, reproduction steps/code

The game crashes during startup on a few devices. There's no pattern of whether certain versions of iOS or devices are impacted.

Version of gdx-pay and/or relevant dependencies

    gdxVersion = '1.9.11'
    roboVMVersion = '2.3.10-SNAPSHOT'
    gdxPayVersion = '1.2.0'
    robopodsVersion = '2.2.3'

Stacktrace

java.lang.NullPointerException
	at com.badlogic.gdx.pay.ios.apple.PurchaseManageriOSApple.transaction(PurchaseManageriOSApple.java:211)
	at com.badlogic.gdx.pay.ios.apple.PurchaseManageriOSApple$AppleTransactionObserver.updatedTransactions(PurchaseManageriOSApple.java:368)
	at com.badlogic.gdx.pay.ios.apple.PurchaseManageriOSApple$IosFetchProductsAndInstallDelegate.didReceiveResponse(PurchaseManageriOSApple.java:318)
	at com.badlogic.gdx.pay.ios.apple.PurchaseManageriOSApple$IosFetchProductsAndInstallDelegate.$cb$productsRequest$didReceiveResponse$(PurchaseManageriOSApple.java)

java.lang.NullPointerException
	at com.badlogic.gdx.pay.ios.apple.PurchaseManageriOSApple.transaction(PurchaseManageriOSApple.java:211)
	at com.badlogic.gdx.pay.ios.apple.PurchaseManageriOSApple$AppleTransactionObserver.updatedTransactions(PurchaseManageriOSApple.java:368)
	at com.badlogic.gdx.pay.ios.apple.PurchaseManageriOSApple$AppleTransactionObserver.$cb$paymentQueue$updatedTransactions$(PurchaseManageriOSApple.java)
	at org.robovm.apple.uikit.UIApplication.main(Native Method)
	at org.robovm.apple.uikit.UIApplication.main(UIApplication.java:446)
	at my.package.IOSLauncher.main(IOSLauncher.java:317)

Please select the affected platforms and payment service implementation

It looks like getTransActionDate() returns null

gdx-pay/gdx-pay-iosrobovm-apple/src/main/java/com/badlogic/gdx/pay/ios/apple/PurchaseManageriOSApple.java

Line 211 in 6841e4d

transaction.setPurchaseTime(t.getTransactionDate().toDate());

A Nullcheck is easy to implement, however, this is the only access to SKPaymentTransaction t (without error catch phrase) instead of using fields from SKPayment payment. Maybe the information is stored there, too?

Even more interesting is the fact that I know from at least one person with that issue that did not do any purchases. The crash happened after downloading the app for the first time.

I will test whether considering getTransactionDate() returning null as invalid transaction does the trick.

Stumbled across this related issue: robovm/robovm-robopods#101

Interesting link. Maybe you get some "fake transaction" that is not purchased or something like that. I know that Apple changed the behaviour what is returned last month, which would explain why this problem pops up now.

Strange enough, I tracked down one of those transactions and it actually is in state Purchased (it's a consumable one). However, since it has no date I wonder whether you could be right about the fake transaction idea.

I wasn't aware of that hackers could be an issue on iOS as well. Beside that, I wonder if hackers would fail to set a valid date if they are able to add an artificial transaction in the first place.

I've never had this problem. We are using both subscriptions and in-app purchase.

Does it happen on non-developer devices too, e.g. from customers who downloaded from App Store?

Are you using Sandbox testing of In-App Purchases?

Are you using iTunes Connect Beta testing? They can do 'fake purchases', e.g. they don't have to pay for purchases.

I

So far it only happened on non-developer devices, that is people who get it from the AppStore directly.

Yes, I do sandbox testing for IAPs and had no issues so far on my devices (also didn't receive feedback from customers like "game stopped working after purchase" which I'd expect to get if those with crashes would be legit customers).

No, I don't use iTunes Connect Beta testing.

So far all of these suspicious transactions contain only the most expensive item in the shop. Furthermore, I couldn't match these with the real purchase data that I get from the AppStore. Therefore I'm convinced that these are indeed fake purchases and that considering them as invalid is the way to go.

However, not feeling confident enough about that yet to make a PR for it. The reason for caring at all about them is that although these are hackers they can still complain about the app crashing in the reviews.

Closed because seems not to occur for other people. Please comment on this issue otherwise.