In-App Billing Broadcasts von Google Play in falscher Reihenfolge? (statische Tests)

Question

Die Android-Dokumente für In-App Billing scheinen in der folgenden Angelegenheit ziemlich klar zu sein. Nach der REQUEST_PURCHASE zeigen Sie die Kasse mit der ausstehenden Absicht (in Ordnung, keine Probleme), dann interagiert der Benutzer mit der Kasse und drückt den Kauf-Button (in diesem Fall verwende ich die statische Produkt-ID android.test.purchased).

Jetzt sollte mein Broadcast-Empfänger eine RESPONSE_CODE und THEN eine IN_APP_NOTIFY erhalten. Nun, das passiert nicht. Manchmal bekomme ich die Antwort zuerst, aber oft bekomme ich es nach der Benachrichtigung.

Der zweite hervorgehobene Abschnitt aus dem Android Doc-Abschnitt unten zitiert ist, warum dies ein Problem ist. Wenn ich den Status in meiner App auf "Ausstehend" aktualisiere, wenn ich die asynchrone Antwort auf die Kaufanfrage erhalte, scheint die Dokumentation darauf hinzuweisen, dass meine App dann, wenn diese Antwort nach der Benachrichtigung erfolgt, in einem ausstehenden Status bleibt. Soll es "wenn Sie result_ok von der unmittelbaren Syncronus-Antwort erhalten" sagen?

Ist es ein Fehler mit Goole Play (die Google Play-Version auf meinem Handy ist 3.5.15 und die Android-Version ist 2.2)? Missverstehe ich die Dokumente? Sind die Docs einfach falsch? Ist es ein Problem mit den statischen Testprodukten? Kann etwas anderes schief gehen? Beachten Sie, dass auf meiner Seite alles im UI-Thread ausgeführt wird, sodass es kein Threading-Problem ist.

Die Protokollausgabe von einem typischen nicht arbeitenden Lauf wird im unteren Bereich angezeigt.

Relevante Abschnitt von Android-Dokumentation (Hervorhebung von mir):

Handhabung Broadcast Absichten

A REQUEST_PURCHASE Anfrage auch löst zwei asynchronen Antworten (Broadcast Absichten). Zunächst sendet die Google Play-Anwendung eine RESPONSE_CODE Broadcast Intent, die Fehlerinformationen über die Anfrage bietet. Wenn die Anforderung keinen Fehler generiert, gibt der Broadcast-Intent RESPONSE_CODE RESULT_OK zurück, der angibt, dass die Anforderung erfolgreich gesendet wurde, . (Um es klar, eine RESULT_OK Antwort bedeutet nicht, dass der angeforderte Kauf war erfolgreich, es zeigt an, dass die Anforderung gesendet wurde erfolgreich auf Google Play.)

Als nächstes, wenn die angeforderte Transaktion Zustand ändert (zum Beispiel die Kauf wird erfolgreich auf eine Kreditkarte belastet oder der Nutzer storniert den Kauf), sendet die Google Play-Anwendung eine IN_APP_NOTIFY Broadcast Intent. Diese Nachricht enthält eine Benachrichtigungs-ID, die Sie zum Abrufen der Transaktionsdetails für die Anforderung REQUEST_PURCHASE verwenden können, die Sie abrufen können.

Hinweis: Die Google Play-Anwendung sendet auch eine IN_APP_NOTIFY für Erstattungen. Weitere Informationen finden Sie unter Verarbeitung von IN_APP_NOTIFY-Nachrichten.

Da der Kaufprozess nicht sofort und kann mehrere Sekunden (oder mehr) nehmen, müssen Sie davon ausgehen, dass eine Kaufanfrage ab dem Zeitpunkt eine RESULT_OK Nachricht anhängig erhalten, bis Sie eine IN_APP_NOTIFY Nachricht für den Empfang Transaktion.Während die Transaktion ausstehend ist, wird auf der Google Play-Checkout-Benutzeroberfläche die Meldung "Autorisierung Kauf ..." angezeigt. Diese Benachrichtigung wird jedoch nach 60 Sekunden abgewiesen, und Sie sollten sich nicht auf diese Benachrichtigung verlassen, da Ihr primäres Mittel zur Übermittlung des Transaktionsstatus an die Benutzer ist. Stattdessen wir empfehlen, dass Sie Folgendes tun:

Beispiel aus meinen Protokollen der Dinge nicht in der erwarteten Reihenfolge gehen:

MAKING REQUEST: PurchaseRequest 
EXECUTING REQUEST: PurchaseRequest 
IMEDIATE RESPONSE IN: PurchaseRequest, IS RESULT_OK 
REQUEST ID: 1814990809059790249, PurchaseRequest 
Receiver: Notify 
Notify String in IN_APP_NOTIFY intent: android.test.purchased 
PROCESSING NOTIFICATION 
MAKING REQUEST: PurchaseInformationRequest 
EXECUTING REQUEST: PurchaseInformationRequest 
IMEDIATE RESPONSE IN: PurchaseInformationRequest, IS RESULT_OK 
REQUEST ID: 602248989635492868, PurchaseInformationRequest 
Receiver: purchase state changed 
PROCESSING PURCHASE_STATE_CHANGE 
newestMarketPurchaseState = PURCHASED 
SetState on product 'Enterprise'. Message: PURCHASED 
MAKING REQUEST: ConfirmNotificationsRequest 
EXECUTING REQUEST: ConfirmNotificationsRequest 
IMEDIATE RESPONSE IN: ConfirmNotificationsRequest, IS RESULT_OK 
REQUEST ID: 693394902887436727, ConfirmNotificationsRequest 
Receiver: Response Code = RESULT_OK 
Receiver: Response Code requestId = 602248989635492868 
PROCESSING RESPONSE 
ASYNCH RESPONSE IN: PurchaseInformationRequest, IS RESULT_OK 
Receiver: Response Code = RESULT_OK 
Receiver: Response Code requestId = 1814990809059790249 
PROCESSING RESPONSE 
ASYNCH RESPONSE IN: PurchaseRequest, IS RESULT_OK 
SetState on product 'Enterprise'. Message: PURCHASE PENDING 
Receiver: Response Code = RESULT_OK 
Receiver: Response Code requestId = 693394902887436727 
PROCESSING RESPONSE 
ASYNCH RESPONSE IN: ConfirmNotificationsRequest, IS RESULT_OK 
Confirm Notifications Request returned asynch OK 

Answer 1

mir dieses sehr gleiches Problem auch begegnet ist. Laut den Antworten in der Frage Are Android broadcasts received in order? gibt es keine absolute Garantie, dass die Absichten in der Reihenfolge empfangen werden, in der sie gesendet wurden. Das tun sie normalerweise, aber nicht unbedingt. Auch wenn Google Play sie korrekt bestellt, können sie trotzdem in einer anderen Reihenfolge ankommen.

Meiner Meinung nach ist die einzige Lösung, nichts über die Zeit zu erwarten, wenn RESPONSE_CODE ankommt. In dieser Hinsicht scheint die Android-Dokumentation wirklich falsch zu sein. Antwortcodes sollten wahrscheinlich durch einen Rückruf implementiert worden sein, nicht als Broadcasts. Ich muss zugeben, dass Google manchmal etwas nachlässig wird.