You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There appears to be completely undocumented functionality by Google that the Google Play app will post status bar notifications for unconfirmed (all?) CANCELED, REFUNDED and EXPIRED messages. EXPIRED is particularly bad since it will never be autoconfirmed unless the same app instance has somehow stayed running for the subscription period. A notification might also be posted in the PURCHASE case when it's a user managed item or subscription and a different device from the purchase device.
When clicked these Google Play notifications will send a MAIN, LAUNCHER intent to the app with extras of "inapp_signed_data" and "inapp_signature" like a PURCHASE_STATE_CHANGED broadcast intent. In my case, it seems to make since that when the application is launched with these extras to call a method like BillingController.onPurchaseStateChanged(context, data, signature, confirm) and then show the "store" activity. Autoconfirming these by the BroadcastReceiver doesn't seem reasonable except for possibly the PURCHASED case. I'm not sure there's any scenario where a PURCHASED notification shouldn't be autoconfirmed.
At a minimum, the confirmed status of purchases needs to be stored in BillingDB and probably a method in BillingController like:
This version just adds every purchase to the confirmations List. However, this fails with "invalid nonce" because the nonce in the Google Play notification is from the last getPurchaseInformation call which has been removed.
I think this means that the nonce should only be removed from "known nonces" if all orders within the message have been confirmed.
My final solution was to change BillingController.onPurchaseStateChanged to always confirm. This is mentioned elsewhere. I'm not sure what the usage case for manual confirmations is. The purchase state info is stored in the BillingDB so there shouldn't be any reason for the Google Play app to continue sending notifications.
Even when auto-confirming CANCELED, REFUNDED and EXPIRED events the Google Play app generates the status bar notifications. I then added a check in my MAIN, LAUNCHER activity to launch the store activity if the intent includes the "inapp_signed_data" extra.
Maybe auto-confirming everything should be a setting. However, there seems to be very little harm in auto-confirming as if you're really interested in doing something manual with an event you can just use a app level BillingObserver.
There appears to be completely undocumented functionality by Google that the Google Play app will post status bar notifications for unconfirmed (all?) CANCELED, REFUNDED and EXPIRED messages. EXPIRED is particularly bad since it will never be autoconfirmed unless the same app instance has somehow stayed running for the subscription period. A notification might also be posted in the PURCHASE case when it's a user managed item or subscription and a different device from the purchase device.
When clicked these Google Play notifications will send a MAIN, LAUNCHER intent to the app with extras of "inapp_signed_data" and "inapp_signature" like a PURCHASE_STATE_CHANGED broadcast intent. In my case, it seems to make since that when the application is launched with these extras to call a method like BillingController.onPurchaseStateChanged(context, data, signature, confirm) and then show the "store" activity. Autoconfirming these by the BroadcastReceiver doesn't seem reasonable except for possibly the PURCHASED case. I'm not sure there's any scenario where a PURCHASED notification shouldn't be autoconfirmed.
At a minimum, the confirmed status of purchases needs to be stored in BillingDB and probably a method in BillingController like:
These issues are somewhat discussed in issues #28 and #49.
Handling of this seems dependent on the type of app, but some library support is needed.
Any thoughts?
The text was updated successfully, but these errors were encountered: