Achats intégrés sous Android, partie 4 : facturation des codes d’erreur de la bibliothèque et comment ne pas se planter lors des tests

Aujourd’hui, nous allons parler des codes d’erreur  nous pouvons obtenir du service de facturation dans la méthode getResponseCode().

Un exemple de la façon dont nous avons transmis les erreurs à nos fonctions de rappel peut être trouvé dans cet article. Nous avons déjà examiné l’une des erreurs dans les articles précédents – il s’agit de USER_CANCELED lorsqu’un utilisateur ferme la boîte de dialogue d’achat sans rien acheter. Faisons connaissance avec les autres.

ERROR and DEVELOPER_ERROR

Commençons par les erreurs appelées ERROR (responseCode 6) et DEVELOPER_ERROR (responseCode 5). Pour le premier cas, Google écrit dans la documentation « Erreur fatale pendant l’action de l’API », pour le second – « Arguments invalides fournis à l’API ». Par exemple, j’ai pu obtenir un DEVELOPER_ERROR lorsque j’ai passé une chaîne vide au constructeur dans setType() pour la requête  querySkuDetailsAsync().

Mais ce n’est pas si simple. Je suis allé plus loin et dans la méthode launchBillingFlow() j’ai utilisé le SkuDetails modifié (j’ai tiré le json du SkuDetails du produit réel, changé le productID dedans et l’ai passé au nouveau constructeur SkuDetails). En fait, c’est un argument invalide, et je m’attendais à obtenir un DEVELOPER_ERROR, mais … J’ai eu un ERROR.

Il s’agissait, bien sûr, d’un exemple artificiel. Le cas où Google a rejeté le paiement est beaucoup plus proche de la réalité. Si vous sélectionnez « carte de test, toujours refusée » dans la boîte de dialogue d’achat lorsque vous testez des achats à partir d’une carte de test, ce dont nous vous parlerons à la fin de l’article, le ERROR reviendra également, mais avec un texte approprié.

Dans le troisième article, où la modification de l’abonnement était décrite, nous avons augmenté le prix d’un abonnement annuel presque 3 fois pour l’un des modes de répartition, mais nous n’avons pas dit quelle erreur aurait dû être présente si nous n’avions pas fait cela. Nous faisons amende honorable.

Puisqu’il s’avère que le mauvais mode de proratisation est spécifié à cet endroit, nous devrions logiquement obtenir le même DEVELOPER_ERROR. Au lieu de cela, nous obtenons  SERVICE_UNAVAILABLE (responseCode 2). Nous l’obtenons également si nous entrons un nombre inapproprié comme mode de répartition (il s’agit d’un int, pas d’un enum, personne ne nous arrêtera), et si nous spécifions le mauvais purchaseToken. Nous examinons la documentation sur SERVICE_UNAVAILABLE et… attendez, quoi?! Nous constatons que la « Connexion réseau est en panne. ».

En même temps, nous constatons également un dialogue étrange :

Une autre chose intéressante dans le cas de ERROR est que lorsque l’on ferme le dialogue PAS par le bouton « OK » (c’est-à-dire par des moyens qui sont interprétés comme « retourner à »), le ERROR vient à onPurchasesUpdated(), et dans le cas de SERVICE_UNAVAILABLE dans une situation similaire vient USER_CANCELED (mais si vous cliquez sur « OK » dans le dialogue, nous recevrons SERVICE_UNAVAILABLE, comme prévu).

Et dans le cas d’une rupture de la connexion Internet, il y a effectivement SERVICE_UNAVAILABLE.

Codes d’erreur

Voici d’autres codes d’erreur accompagnés de petits commentaires, pour ainsi dire des mentions honorables.

• BILLING_UNAVAILABLE (responseCode 3). Google explique que « la version de l’API de facturation n’est pas prise en charge pour le type demandé ». J’ai pu reproduire cette erreur lorsque j’étais déconnecté de mon compte Google, ainsi qu’en utilisant un appareil Huawei sans Google Play Services. Il peut également être reproduit sur des téléphones plus anciens où Google Play n’a pas été mis à jour.
• SERVICE_DISCONNECTED (responseCode -1). L’application est parfois déconnectée du service Google Play. Cela peut se produire si le Play Store se met à jour de façon inattendue. Je vous conseille donc de jouer la sécurité et de vous connecter avant chaque appel des méthodes du service de facturation, comme dans les articles précédents. En outre, Google et nous vous conseillons d’ajouter une politique de réessai si cette erreur apparaît toujours dans la réponse.
• SERVICE_TIMEOUT (responseCode -3). Le nom parle de lui-même – nous attendons une réponse de Google Play depuis trop longtemps.
• FEATURE NOT SUPPORTED. Il existe cinq constantes  FeatureType dans la classe BillingClient. Leur disponibilité sur cet appareil peut être vérifiée à l’aide de la méthode   BillingClient.isFeatureSupported(BillingClient.FeatureType.A_NECESSARY_FEATURE). Sur mon téléphone (Xiaomi Mi A2 Lite), FEATURE_NOT_SUPPORTED est revenu uniquement pour SUBSCRIPTIONS_ON_VR. Dans le même temps, pour IN_APP_ITEMS_ON_VR, ainsi que pour toutes les autres fonctionnalités, OK est rétabli.
• ITEM_NOT_OWNED (responseCode 8). Elle se produit en essayant de consommer un achat que l’on n’a pas. Possiblement, même à plusieurs reprises après une consommation réussie.
• ITEM_ALREADY_OWNED (responseCode 7). Et ici, au contraire, l’erreur se produit en essayant d’acheter un produit que l’on possède déjà. Dans ce cas, il suffit de mettre à jour l’interface utilisateur et de rendre le bouton d’achat non cliquable.

ITEM_UNAVAILABLE

La dernière erreur, et probablement la plus courante, au début du chemin de mise en œuvre des achats intégrés, est  ITEM_UNAVAILABLE (responseCode 4). Il indique que le produit n’est pas disponible à la vente, mais n’explique pas pourquoi. Les raisons peuvent être très différentes : du test sur le mauvais compte ou appareil à l’achat d’un produit inactif.

Voici une liste de contrôle de ce que vous devez faire pour éviter cette erreur pendant les tests :

1.   Envoyez une application avec le service de facturation sur votre chemin d’exécution. Il s’agit d’une condition obligatoire ; en même temps, vous pouvez également tester sur des builds de débogage avec le même applicationId, mais il est important que l’application avec le service de facturation soit téléchargée sur la Play Console au moins une fois.

2.   Ajoutez les comptes Google des testeurs à ce chemin d’exécution, ce qui est particulièrement important pour les tests internes ou les alpha/bêta fermés. Il y aura également un lien dans la section Comment les testeurs rejoignent votre test, où les testeurs doivent accepter l’invitation.

3.   Vous ne pouvez acheter qu’un produit activé. Après avoir créé un produit, il y a un bouton d’activation dans la console de jeu. Nous avons décrit plus en détail le processus de création d’un produit dans le Premier article.

4.   Veillez à ce que le test sur l’appareil ait lieu à partir du compte Google d’un  testeur (ce qui signifie qu’il doit être inscrit en tant que testeur dans ce chemin d’exécution et disposer de tous les accès techniques nécessaires). Ce point semble évident mais des choses arrivent, et vous devez également le vérifier si vous avez reçu une telle erreur.

5.   L’applicationId de la version utilisée pour les tests d’achat doit correspondre entièrement à l’applicationId de Play Console. Ceci est particulièrement important pour ceux qui ont un suffixe ajouté dans leurs constructions de débogage.

6.   Ajoutez les adresses électroniques des testeurs à la section Setup → License Testing dans le menu de gauche du compte (et non de l’application), afin qu’ils achètent des produits gratuitement à partir d’une carte de test et non d’une carte réelle. Un autre avantage est que, dans ce cas, les abonnements auront une  durée d’essai. Ce n’est pas lié à cette erreur, mais c’est aussi une connaissance utile.

Conclusion

Les erreurs peuvent compliquer considérablement le travail, il est donc toujours important de comprendre comment elles peuvent se produire. Compte tenu du nombre d’étapes à franchir pour avoir accès aux produits, le plus simple est d’attraper ITEM_UNAVAILABLE. J’espère donc que ma liste de contrôle vous sera utile.

Le Adapty SDK facilitera la gestion des erreurs et offrira de nombreux autres avantages : analyse de base des abonnements, analyse des cohortes (cohort analysis), test simple des paywalls, intégration avec des services d’analyse, validation des erreurs de serveur. Essayez-le maintenant !