{"id":137878,"date":"2021-09-29T00:00:00","date_gmt":"2021-09-29T00:00:00","guid":{"rendered":"https:\/\/adapty.io\/de-android-in-app-purchases-part-4-billing-library-error-codes-and-how-not-to-fail-testing\/"},"modified":"2021-09-29T00:00:00","modified_gmt":"2021-09-29T00:00:00","slug":"android-in-app-purchases-part-4-billing-library-error-codes-and-how-not-to-fail-testing","status":"publish","type":"post","link":"https:\/\/adapty.io\/de\/blog\/android-in-app-purchases-part-4-billing-library-error-codes-and-how-not-to-fail-testing\/","title":{"rendered":"Android In-App-K\u00e4ufe, Teil 4: Billing Library Fehlercodes und wie Sie Fehler beim Testen vermeiden"},"content":{"rendered":"\n
Heute kommen wir auf die Fehlercodes<\/a> zu sprechen, die wir von der Billing Library in der getResponseCode()<\/a> Methode erhalten k\u00f6nnen.<\/p>\n\n\n\n Ein Beispiel daf\u00fcr, wie wir Fehler zu unseren Callbacks geleitet haben, finden Sie in diesem Artikel<\/a>. Wir haben bereits einen der Fehler in vorherigen Artikeln betrachtet, n\u00e4mlich USER_CANCELED<\/strong><\/a>, der auftritt, wenn ein Nutzer den Kaufdialog schlie\u00dft, ohne etwas zu kaufen. Lassen Sie uns weitere Fehler kennenlernen.<\/p>\n\n\n\n\n\n Lassen Sie uns mit den als ERROR<\/strong><\/a> (responseCode 6) und DEVELOPER_ERROR<\/strong><\/a> (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()<\/a> f\u00fcr die querySkuDetailsAsync()<\/a> Anfrage geschickt habe.<\/p>\n\n\n\n Aber so einfach ist das nicht. Ich ging einen Schritt weiter und nutzte in der launchBillingFlow()<\/a> Methode die modifizierten SkuDetails<\/a> (die ich aus dem json der SkuDetails des echten Produkts erhalten, dann die productID darin ge\u00e4ndert und sie zum SkuDetails Constructor geschickt habe). Das ist im Grunde ein Invalid Argument und ich erwartete einen DEVELOPER_ERROR<\/strong>, bekam aber…einen ERROR<\/strong>.<\/p>\n\n\n\n Das war nat\u00fcrlich ein k\u00fcnstlich herbeigef\u00fchrtes Beispiel. Wenn Google die Zahlung ablehnt, ist dies deutlich realer. Wenn Sie im Kaufdialog beim Testen mit einer Testkarte „test card, always declined“ ausw\u00e4hlen (worauf wir noch am Ende dieses Artikels zu sprechen kommen), kommt es ebenfalls zu einem ERROR<\/strong>, allerdings mit richtigem Text.<\/p>\n\n\n\n Im dritten Artikel<\/a>, in dem es um die Abonnement-\u00c4nderung ging, haben wir den Preis eines Jahresabonnements f\u00fcr einen der Prorationsmodus fast verdreifacht, aber nicht erw\u00e4hnt, welcher Fehler auftreten w\u00fcrde, h\u00e4tten wir das nicht getan. Wir geloben Besserung.<\/p>\n\n\n\n Wir haben herausgefunden, dass der falsche Prorationsmodus angegeben ist und sollten logischerweise den gleichen DEVELOPER_ERROR<\/strong> erhalten. Stattdessen erhalten wir SERVICE_UNAVAILABLE<\/strong><\/a> (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<\/strong> an und\u2026was?! Wir sehen, dass die „Netzwerkverbindung abgebrochen sei.“.<\/p>\n\n\n\n Gleichzeitig erhalten wir dieses seltsame Dialogfenster:<\/p>\n\n\n\n Es gibt noch eine weitere interessante Sache im Falle des ERROR<\/strong>. Wenn wir n\u00e4mlich den Dialog NICHT<\/strong> per „OK“ Button schlie\u00dfen (was als \u201czur\u00fcckgehen\u201d interpretiert wird), kommt der ERROR <\/strong>zu onPurchasesUpdated()<\/a>. Im Falle von SERVICE_UNAVAILABLE<\/strong> in einer \u00e4hnlichen Situation kommt USER_CANCELED<\/strong> (wenn Sie aber im Dialog auf „OK“ klicken, erhalten wir SERVICE_UNAVAILABLE<\/strong> wie erwartet).<\/p>\n\n\n\n Im Falle einer verlorenen Internetverbindung kommt tats\u00e4chlich SERVICE_UNAVAILABLE<\/strong>.<\/p>\n\n\n\n Hier sind einige weitere Fehlercodes mit kurzen Kommentaren, um sie wenigstens einmal erw\u00e4hnt zu haben.<\/p>\n\n\n\n Der letzte und vermutlich h\u00e4ufigste Fehler zu Beginn der Implementierung von In-App-K\u00e4ufen ist ITEM_UNAVAILABLE<\/strong><\/a> (responseCode 4). Dieser besagt, dass das Produkt nicht zum Kauf zur Verf\u00fcgung steht, erkl\u00e4rt aber nicht, warum. Dies kann verschiedene Gr\u00fcnde haben: vom Testen im falschen Konto oder Ger\u00e4t bis zum Kauf eines inaktiven Produkts.<\/p>\n\n\n\n \u00dcberpr\u00fcfen Sie folgende Punkte, um diesen Fehler beim Testen zu vermeiden:<\/p>\n\n\n\n 1. Senden Sie eine App mit der Billing Library an Ihren Test Track. Dies ist eine zwingende Bedingung. Gleichzeitig k\u00f6nnen 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.<\/p>\n\n\n\n 2. F\u00fcgen Sie diesem Test Track Google Konten der Tester hinzu, was besonders f\u00fcr das interne Testen oder in der Closed Alpha\/Beta wichtig ist. Es wird auch einen Link in Wie Tester Ihren Testbereich beitreten<\/em> geben. Die Tester sollten diese Einladung annehmen.<\/p>\n\n\n\n 3. Sie k\u00f6nnen nur ein aktiviertes Produkt kaufen. Nach der Erstellung eines Produkt gibt es einen Aktivieren<\/em><\/strong> Button in der Play Console. Wir haben den Vorgang der Produkterstellung im ersten Artikel<\/a> genauer beschrieben.<\/p>\n\n\n\n 4. Achten Sie darauf, dass das Testen am Ger\u00e4t \u00fcber ein Google Konto eines Testers erfolgt (was bedeutet, dass es als Tester in diesem Test Track angemeldet ist und den n\u00f6tigen technischen Zugang hat). Dieser Punkt scheint offensichtlich, wird aber immer wieder gerne \u00fcbersehen.<\/p>\n\n\n\n 5. Die ApplicationID des Builds, das f\u00fcr 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\u00fcgt haben.<\/p>\n\n\n\n 6. F\u00fcgen Sie die E-Mail-Adressen der Tester \u00fcber Setup \u2192 License Testing <\/em>im linken Men\u00fc 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<\/a> haben. Dies hat nichts mit diesem Fehler zu tun, ist aber gut zu wissen.<\/p>\n\n\n\n Fehler k\u00f6nnen 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\u00fcssen, um Zugriff auf Produkte zu erhalten, ist es am einfachsten, ITEM_UNAVAILABLE abzufangen. Ich hoffe sehr, dass Ihnen meine Checkliste weiterhilft.<\/p>\n\n\n\nERROR und DEVELOPER_ERROR<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
Fehlercodes<\/h2>\n\n\n\n
\n
ITEM_UNAVAILABLE<\/h2>\n\n\n\n
Fazit<\/h2>\n\n\n\n