{"id":137856,"date":"2021-09-29T00:00:00","date_gmt":"2021-09-29T00:00:00","guid":{"rendered":"https:\/\/adapty.io\/fr-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\/fr\/blog\/android-in-app-purchases-part-4-billing-library-error-codes-and-how-not-to-fail-testing\/","title":{"rendered":"Achats int\u00e9gr\u00e9s sous Android, partie 4 : facturation des codes d’erreur de la biblioth\u00e8que et comment ne pas se planter lors des tests"},"content":{"rendered":"\n
Aujourd’hui, nous allons parler des codes d’erreur<\/a> nous pouvons obtenir du service de facturation dans la m\u00e9thode getResponseCode()<\/a>.<\/p>\n\n\n\n Un exemple de la fa\u00e7on dont nous avons transmis les erreurs \u00e0 nos fonctions de rappel peut \u00eatre trouv\u00e9 dans cet article<\/a>. Nous avons d\u00e9j\u00e0 examin\u00e9 l’une des erreurs dans les articles pr\u00e9c\u00e9dents – il s’agit de USER_CANCELED<\/strong><\/a> lorsqu’un utilisateur ferme la bo\u00eete de dialogue d’achat sans rien acheter. Faisons connaissance avec les autres.<\/p>\n\n\n\n\n\n Commen\u00e7ons par les erreurs appel\u00e9es ERROR<\/strong><\/a> (responseCode 6) et DEVELOPER_ERROR<\/strong><\/a> (responseCode 5). Pour le premier cas, Google \u00e9crit dans la documentation \u00ab\u00a0Erreur fatale pendant l’action de l’API\u00a0\u00bb, pour le second – \u00ab\u00a0Arguments invalides fournis \u00e0 l’API\u00a0\u00bb. Par exemple, j’ai pu obtenir un DEVELOPER_ERROR lorsque j’ai pass\u00e9 une cha\u00eene vide au constructeur dans setType()<\/a> pour la requ\u00eate querySkuDetailsAsync()<\/a>.<\/p>\n\n\n\n Mais ce n’est pas si simple. Je suis all\u00e9 plus loin et dans la m\u00e9thode launchBillingFlow()<\/a> j’ai utilis\u00e9 le SkuDetails<\/a> modifi\u00e9 (j’ai tir\u00e9 le json du SkuDetails du produit r\u00e9el, chang\u00e9 le productID dedans et l’ai pass\u00e9 au nouveau constructeur SkuDetails). En fait, c’est un argument invalide, et je m’attendais \u00e0 obtenir un DEVELOPER_ERROR, mais … J’ai eu un ERROR.<\/p>\n\n\n\n Il s’agissait, bien s\u00fbr, d’un exemple artificiel. Le cas o\u00f9 Google a rejet\u00e9 le paiement est beaucoup plus proche de la r\u00e9alit\u00e9. Si vous s\u00e9lectionnez \u00ab\u00a0carte de test, toujours refus\u00e9e\u00a0\u00bb dans la bo\u00eete de dialogue d’achat lorsque vous testez des achats \u00e0 partir d’une carte de test, ce dont nous vous parlerons \u00e0 la fin de l’article, le ERROR reviendra \u00e9galement, mais avec un texte appropri\u00e9.<\/p>\n\n\n\n Dans le troisi\u00e8me article<\/a>, o\u00f9 la modification de l’abonnement \u00e9tait d\u00e9crite, nous avons augment\u00e9 le prix d’un abonnement annuel presque 3 fois pour l’un des modes de r\u00e9partition, mais nous n’avons pas dit quelle erreur aurait d\u00fb \u00eatre pr\u00e9sente si nous n’avions pas fait cela. Nous faisons amende honorable.<\/p>\n\n\n\n Puisqu’il s’av\u00e8re que le mauvais mode de proratisation est sp\u00e9cifi\u00e9 \u00e0 cet endroit, nous devrions logiquement obtenir le m\u00eame DEVELOPER_ERROR. Au lieu de cela, nous obtenons SERVICE_UNAVAILABLE<\/strong><\/a> (responseCode 2). Nous l’obtenons \u00e9galement si nous entrons un nombre inappropri\u00e9 comme mode de r\u00e9partition (il s’agit d’un int, pas d’un enum, personne ne nous arr\u00eatera), et si nous sp\u00e9cifions le mauvais purchaseToken. Nous examinons la documentation sur SERVICE_UNAVAILABLE et\u2026 attendez, quoi?! Nous constatons que la \u00ab\u00a0Connexion r\u00e9seau est en panne.\u00a0\u00bb.<\/p>\n\n\n\n En m\u00eame temps, nous constatons \u00e9galement un dialogue \u00e9trange :<\/p>\n\n\n\n Une autre chose int\u00e9ressante dans le cas de ERROR est que lorsque l’on ferme le dialogue PAS par le bouton \u00ab\u00a0OK\u00a0\u00bb (c’est-\u00e0-dire par des moyens qui sont interpr\u00e9t\u00e9s comme \u00ab\u00a0retourner \u00e0\u00a0\u00bb), le ERROR vient \u00e0 onPurchasesUpdated()<\/a>, et dans le cas de SERVICE_UNAVAILABLE dans une situation similaire vient USER_CANCELED (mais si vous cliquez sur \u00ab\u00a0OK\u00a0\u00bb dans le dialogue, nous recevrons SERVICE_UNAVAILABLE, comme pr\u00e9vu).<\/p>\n\n\n\n Et dans le cas d’une rupture de la connexion Internet, il y a effectivement SERVICE_UNAVAILABLE.<\/p>\n\n\n\n Voici d’autres codes d’erreur accompagn\u00e9s de petits commentaires, pour ainsi dire des mentions honorables.<\/p>\n\n\n\n La derni\u00e8re erreur, et probablement la plus courante, au d\u00e9but du chemin de mise en \u0153uvre des achats int\u00e9gr\u00e9s, est ITEM_UNAVAILABLE<\/strong><\/a> (responseCode 4). Il indique que le produit n’est pas disponible \u00e0 la vente, mais n’explique pas pourquoi. Les raisons peuvent \u00eatre tr\u00e8s diff\u00e9rentes : du test sur le mauvais compte ou appareil \u00e0 l’achat d’un produit inactif.<\/p>\n\n\n\n Voici une liste de contr\u00f4le de ce que vous devez faire pour \u00e9viter cette erreur pendant les tests :<\/p>\n\n\n\n 1. Envoyez une application avec le service de facturation sur votre chemin d’ex\u00e9cution. Il s’agit d’une condition obligatoire ; en m\u00eame temps, vous pouvez \u00e9galement tester sur des builds de d\u00e9bogage avec le m\u00eame applicationId, mais il est important que l’application avec le service de facturation soit t\u00e9l\u00e9charg\u00e9e sur la Play Console au moins une fois.<\/p>\n\n\n\n 2. Ajoutez les comptes Google des testeurs \u00e0 ce chemin d\u2019ex\u00e9cution, ce qui est particuli\u00e8rement important pour les tests internes ou les alpha\/b\u00eata ferm\u00e9s. Il y aura \u00e9galement un lien dans la section Comment les testeurs rejoignent votre test<\/em>, o\u00f9 les testeurs doivent accepter l’invitation.<\/p>\n\n\n\n 3. Vous ne pouvez acheter qu’un produit activ\u00e9. Apr\u00e8s avoir cr\u00e9\u00e9 un produit, il y a un bouton d’activation dans la console de jeu. Nous avons d\u00e9crit plus en d\u00e9tail le processus de cr\u00e9ation d’un produit dans le Premier article.<\/a><\/p>\n\n\n\n 4. Veillez \u00e0 ce que le test sur l’appareil ait lieu \u00e0 partir du compte Google d’un testeur (ce qui signifie qu’il doit \u00eatre inscrit en tant que testeur dans ce chemin d\u2019ex\u00e9cution et disposer de tous les acc\u00e8s techniques n\u00e9cessaires). Ce point semble \u00e9vident mais des choses arrivent, et vous devez \u00e9galement le v\u00e9rifier si vous avez re\u00e7u une telle erreur.<\/p>\n\n\n\n 5. L’applicationId de la version utilis\u00e9e pour les tests d’achat doit correspondre enti\u00e8rement \u00e0 l’applicationId de Play Console. Ceci est particuli\u00e8rement important pour ceux qui ont un suffixe ajout\u00e9 dans leurs constructions de d\u00e9bogage.<\/p>\n\n\n\n 6. Ajoutez les adresses \u00e9lectroniques des testeurs \u00e0 la section Setup \u2192 License Testing<\/em> dans le menu de gauche du compte (et non de l’application), afin qu’ils ach\u00e8tent des produits gratuitement \u00e0 partir d’une carte de test et non d’une carte r\u00e9elle. Un autre avantage est que, dans ce cas, les abonnements auront une dur\u00e9e d’essai<\/a>. Ce n’est pas li\u00e9 \u00e0 cette erreur, mais c’est aussi une connaissance utile.<\/p>\n\n\n\n Les erreurs peuvent compliquer consid\u00e9rablement le travail, il est donc toujours important de comprendre comment elles peuvent se produire. Compte tenu du nombre d’\u00e9tapes \u00e0 franchir pour avoir acc\u00e8s aux produits, le plus simple est d’attraper ITEM_UNAVAILABLE. J’esp\u00e8re donc que ma liste de contr\u00f4le vous sera utile.<\/p>\n\n\n\nERROR and DEVELOPER_ERROR<\/h2>\n\n\n\n
<\/figure>\n\n\n\nCodes d’erreur<\/h2>\n\n\n\n
\n
ITEM_UNAVAILABLE<\/h2>\n\n\n\n
Conclusion<\/h2>\n\n\n\n