Android In-App-Käufe, Teil 4: Billing Library Fehlercodes und wie Sie Fehler beim Testen vermeiden

Heute kommen wir auf die Fehlercodes zu sprechen, die wir von der Billing Library in der getResponseCode() Methode erhalten können.

Ein Beispiel dafür, wie wir Fehler zu unseren Callbacks geleitet haben, finden Sie in diesem Artikel. Wir haben bereits einen der Fehler in vorherigen Artikeln betrachtet, nämlich USER_CANCELED, der auftritt, wenn ein Nutzer den Kaufdialog schließt, ohne etwas zu kaufen. Lassen Sie uns weitere Fehler kennenlernen.

ERROR und DEVELOPER_ERROR

Lassen Sie uns mit den als ERROR (responseCode 6) und DEVELOPER_ERROR (responseCode 5) bezeichneten Fehlern beginnen. Im erst genannten Fall schreibt Google in der Dokumentation „Fatal error during the API action“. Im anderen genannten Fall erscheint „Invalid arguments provided to the API“. Ich habe beispielsweise einen DEVELOPER_ERROR erhalten, wenn ich einen leeren String zum Builder in setType() für die querySkuDetailsAsync() Anfrage geschickt habe.

Aber so einfach ist das nicht. Ich ging einen Schritt weiter und nutzte in der launchBillingFlow() Methode die modifizierten SkuDetails (die ich aus dem json der SkuDetails des echten Produkts erhalten, dann die productID darin geändert und sie zum SkuDetails Constructor geschickt habe). Das ist im Grunde ein Invalid Argument und ich erwartete einen DEVELOPER_ERROR, bekam aber…einen ERROR.

Das war natürlich ein künstlich herbeigeführtes Beispiel. Wenn Google die Zahlung ablehnt, ist dies deutlich realer. Wenn Sie im Kaufdialog beim Testen mit einer Testkarte „test card, always declined“ auswählen (worauf wir noch am Ende dieses Artikels zu sprechen kommen), kommt es ebenfalls zu einem ERROR, allerdings mit richtigem Text.

Im dritten Artikel, in dem es um die Abonnement-Änderung ging, haben wir den Preis eines Jahresabonnements für einen der Prorationsmodus fast verdreifacht, aber nicht erwähnt, welcher Fehler auftreten würde, hätten wir das nicht getan. Wir geloben Besserung.

Wir haben herausgefunden, dass der falsche Prorationsmodus angegeben ist und sollten logischerweise den gleichen DEVELOPER_ERROR erhalten. Stattdessen erhalten wir SERVICE_UNAVAILABLE (responseCode 2). Diesen erhalten wir auch, wenn wir unpassende Zahlen als Prorationsmodus eingeben (also int statt enum) und wenn wir den falschen purchaseToken bestimmen. Wir schauen in der Dokumentation SERVICE_UNAVAILABLE an und…was?! Wir sehen, dass die „Netzwerkverbindung abgebrochen sei.“.

Gleichzeitig erhalten wir dieses seltsame Dialogfenster:

Es gibt noch eine weitere interessante Sache im Falle des ERROR. Wenn wir nämlich den Dialog NICHT per „OK“ Button schließen (was als “zurückgehen” interpretiert wird), kommt der ERROR zu onPurchasesUpdated(). Im Falle von SERVICE_UNAVAILABLE in einer ähnlichen Situation kommt USER_CANCELED (wenn Sie aber im Dialog auf „OK“ klicken, erhalten wir SERVICE_UNAVAILABLE wie erwartet).

Im Falle einer verlorenen Internetverbindung kommt tatsächlich SERVICE_UNAVAILABLE.

Fehlercodes

Hier sind einige weitere Fehlercodes mit kurzen Kommentaren, um sie wenigstens einmal erwähnt zu haben.

• BILLING_UNAVAILABLE (responseCode 3). Google erklärt, dass „die Billing API Version nicht für den angefragten Typ unterstützt wird“. Ich konnte diesen Fehler reproduzieren, wenn ich mich mit meinem Google Konto abgemeldet habe oder wenn ich ein Huawei-Gerät ohne Google Play Unterstützung nutzte. Er kann auch auf älteren Smartphones reproduziert werden, auf denen Google Play nicht aktualisiert wurde.
• SERVICE_DISCONNECTED (responseCode -1). Die App ist manchmal vom Google Play Service getrennt. Dies kann passieren, wenn der Play Store unerwarteterweise aktualisiert wird. Ich empfehle Ihnen daher, auf Nummer sicher zu gehen und vor jedem Call der Billing Library Methoden eine Verbindung herzustellen (siehe vorherige Artikel). Sowohl Google als auch wir empfehlen Ihnen, eine Erneut-Versuchen-Richtlinie hinzuzufügen, falls der Fehler weiterhin als Antwort erfolgt.
• SERVICE_TIMEOUT (responseCode -3). Der Name sagt schon alles. Wir haben zu lange auf eine Antwort von Google Play gewartet.
• FEATURE NOT SUPPORTED. Es gibt fünf FeatureType Konstanten in der BillingClient class. Ihre Verfügbarkeit auf diesem Gerät kann mit der Methode BillingClient.isFeatureSupported(BillingClient.FeatureType.A_NECESSARY_FEATURE) überprüft werden. Auf meinem Smartphone (Xiaomi Mi A2 Lite) erschien FEATURE_NOT_SUPPORTED nur für SUBSCRIPTIONS_ON_VR. Gleichzeitig erschien für IN_APP_ITEMS_ON_VR und alle anderen Features ein OK.
• ITEM_NOT_OWNED (responseCode 8). Dies tritt auf, wenn versucht wird, einen Kauf zu verbrauchen, den wir nicht haben. Eventuell sogar mehrfach nach einem erfolgreichen Verbrauch.
• ITEM_ALREADY_OWNED (responseCode 7). Im Gegensatz dazu tritt dieser Fehler auf, wenn wir versuchen, ein Produkt zu kaufen, das wir bereits haben. In diesem Fall müssen Sie nur die UI aktualisieren und den Kauf-Button nicht anklickbar machen.

ITEM_UNAVAILABLE

Der letzte und vermutlich häufigste Fehler zu Beginn der Implementierung von In-App-Käufen ist ITEM_UNAVAILABLE (responseCode 4). Dieser besagt, dass das Produkt nicht zum Kauf zur Verfügung steht, erklärt aber nicht, warum. Dies kann verschiedene Gründe haben: vom Testen im falschen Konto oder Gerät bis zum Kauf eines inaktiven Produkts.

Überprüfen Sie folgende Punkte, um diesen Fehler beim Testen zu vermeiden:

1.   Senden Sie eine App mit der Billing Library an Ihren Test Track. Dies ist eine zwingende Bedingung. Gleichzeitig können Sie auch mit derselben ApplicationID auf Debug Builds testen. Es ist aber wichtig, dass die App mit der Billing Library mindestens einmal in die Play Console hochgeladen wurde.

2.   Fügen Sie diesem Test Track Google Konten der Tester hinzu, was besonders für das interne Testen oder in der Closed Alpha/Beta wichtig ist. Es wird auch einen Link in Wie Tester Ihren Testbereich beitreten geben. Die Tester sollten diese Einladung annehmen.

3.   Sie können nur ein aktiviertes Produkt kaufen. Nach der Erstellung eines Produkt gibt es einen Aktivieren Button in der Play Console. Wir haben den Vorgang der Produkterstellung im ersten Artikel genauer beschrieben.

4.   Achten Sie darauf, dass das Testen am Gerät über ein Google Konto eines Testers erfolgt (was bedeutet, dass es als Tester in diesem Test Track angemeldet ist und den nötigen technischen Zugang hat). Dieser Punkt scheint offensichtlich, wird aber immer wieder gerne übersehen.

5.   Die ApplicationID des Builds, das für den Kauftest genutzt wird, muss zur ApplicionID aus der Play Console passen. Dies ist besonders dann wichtig, wenn Sie in Ihren Debug Builds Suffixe hinzugefügt haben.

6.   Fügen Sie die E-Mail-Adressen der Tester über Setup → License Testing im linken Menü des Kontos hinzu (nicht die App), sodass sie die Produkte kostenlos von einer Testkarte kaufen und nicht mit einer echten. Ein weiterer Vorteil besteht darin, dass die Abonnements in diesem Fall eine Testdauer haben. Dies hat nichts mit diesem Fehler zu tun, ist aber gut zu wissen.

Fazit

Fehler können die Arbeit erheblich erschweren. Es ist wichtig, sie zu kennen und zu verstehen, warum sie auftreten. Wenn man bedenkt, wie viele Schritte Sie durchlaufen müssen, um Zugriff auf Produkte zu erhalten, ist es am einfachsten, ITEM_UNAVAILABLE abzufangen. Ich hoffe sehr, dass Ihnen meine Checkliste weiterhilft.

The Adapty SDK erleichtert die Lösung der Fehler und bietet Ihnen viele weitere Vorteile wie grundlegende Abonnement-Analysen, Kohorten-Analysen, ein einfaches Testen von Paywalls, die Integration mit Analysediensten oder auch eine Serverfehlervalidierung. Probieren Sie es aus!