Androidアプリ内購入、パート 4: Billing Libraryエラ ーコードとテストで失敗しない方法

今回は、getResponseCode()メソッドでBilling Libraryから返されるエラーコードについて説明します。

この記事では、エラーをコールバックに渡す方法の例を取り上げています。すでに以前の記事で、エラーの1つについて学びました。ユーザーが何も購入せずに購入ダイアログを閉じた場合のUSER_CANCELEDです。その他のエラーを見ていきましょう。

ERROR と DEVELOPER_ERROR

ERROR (responseCode 6) およびDEVELOPER_ERROR (responseCode 5) というエラーから始めましょう。最初のケースについて、Googleの参照資料では「API アクション中の致命的なエラー」、2 番目のケースについては「API に無効な引数が提供されました」と記されています。たとえば、querySkuDetailsAsync()リクエストのsetType()で空の文字列をビルダーに渡すと、DEVELOPER_ERRORが表示されました。

ただし、それほど単純ではありません。さらに進み、launchBillingFlow()メソッドで、変更されたSkuDetailsを使用しました (実際のアイテムのSkuDetailsからjsonを取得し、その中のproductIDを変更して、新しいSkuDetailsコンストラクタに渡しました)。実際、これは無効な引数であり、DEVELOPER_ERROR が返されると予想していましたが、ERROR が発生しました。

もちろん、これは故意の例です。 Googleが支払いを拒否したケースは、もっと現実的です。テストカードからの購入をテストするときに購入ダイアログで「テストカード、常に不承認」を選択すると、記事の最後で説明するようにエラーも返されますが、適切なテキストが表示されます.

定期購入 (subscription) の変更について説明した3番目の記事では、日割り計算方式のいずれかで年間定期購入の料金をほぼ3倍に引き上げましたが、それを行わなかった場合にどのような間違いがあったかについては言及しませんでした。現在、修正を行っています。

誤った日割り計算方式が指定されていることが判明したため、論理的には同じDEVELOPER_ERRORが表示される必要があります。代わりに、SERVICE_UNAVAILABLE (responseCode 2) を取得します。また、日割り計算方式として不適切な数値を入力した場合 (enumではなく、さらに便利なintとなります)、および誤ったpurchaseTokenを指定した場合にも発生します。 SERVICE_UNAVAILABLEに関する参照資料を確認すると、「ネットワーク接続がダウンしています」と表示されます。

同時に、このようなダイアログも表示されます。

ERRORの場合の興味深い点は他にも、「OK」ボタンを使用せずに (「戻る」ボタンを使用する方法) ダイアログを閉じると、onPurchasesUpdated()にERRORが発生することです。また、SERVICE_UNAVAILABLEの場合には、同様の状況でUSER_CANCELEDが発生します (ただし、ダイアログで [OK] をクリックすると、想定どおりSERVICE_UNAVAILABLEが返されます)。

インターネット接続が失われた場合、実際にSERVICE_UNAVAILABLEが発生します。

エラーコード

短いコメント付きのエラーコードであり、特別賞のようなものです。

● BILLING_UNAVAILABLE (responseCode 3)：Googleでは、「リクエストされたタイプのBilling APIバージョンはサポートされていません」と説明されています。 Googleアカウントからログアウトしたとき、およびGoogle Playサービスを利用せずにHuaweiデバイスを使用したときに、このエラーを再現できました。また、Google Playがアップデートされていない旧型のスマートフォンでも再現できる可能性があります。

● SERVICE_DISCONNECTED (responseCode -1) ：アプリケーションと Google Play サービスとの接続が解除される場合があります。これは、Playストアが予期せずアップデートされた場合に発生する可能性があります。そのため、前回の記事のように、Billing Libraryメソッドの各呼び出しの前に、安全にプレーして接続することをお勧めします。また、当社とGoogleのいずれも、このエラーが引き続き応答に含まれる場合は、再試行ポリシーを追加することをお勧めします。

● SERVICE_TIMEOUT (responseCode -3)；名前のとおり、Google Playからの応答を待機していたものの、タイムアウトになりました。

● FEATURE NOT SUPPORTED：BillingClientクラスには5つのFeatureType定数があります。このデバイスでの可用性は、BillingClient.isFeatureSupported(BillingClient.FeatureType.A_NECESSARY_FEATURE)のメソッドを使用して確認できます。私のスマートフォン (Xiaomi Mi A2 Lite) では、FEATURE_NOT_SUPPORTEDがSUBSCRIPTIONS_ON_VRに対してのみ返されました。同時に、IN_APP_ITEMS_ON_VRなどのすべての機能について、OKが返されました。

● ITEM_NOT_OWNED (responseCode 8)：所有していないアイテムを使用しようとするときに発生します。おそらく、使用できた後でも繰り返し発生します。

● ITEM_ALREADY_OWNED (responseCode 7)：ここでは逆に、すでに所有しているアイテムを購入しようとしているときにエラーが発生します。そのような場合は、UIを更新して購入ボタンをクリックできないようにすればよいだけです。

ITEM_UNAVAILABLE

アプリ内購入の実装パスの最初にある、最後の、そしておそらく最も一般的なエラーはITEM_UNAVAILABLE (responseCode 4)です。アイテムは購入できないと表示されていますが、その理由は説明されていません。間違ったアカウントやデバイスでのテストから、非有効なアイテムの購入まで、理由は大きく異なります。

テスト中にこのエラーを回避するために必要なチェックリストを次に示します。

1. Billing Libraryを含むアプリをテストトラックに送信します。これは必須条件です。同時に、同じapplicationIdを使用してデバッグビルドをテストすることもできますが、Billing Libraryを使用するアプリを少なくとも1回はPlay Consoleにアップロードすることが重要です。

2. このテストトラックに、テスターのGoogleアカウントを追加します。これは、内部テストまたはクローズドアルファ/ベータにおいて特に重要です。テスターが招待を受け入れる必要がある「テスターがテストに参加する方法」セクションにも、リンクが記載されています。

3. 有効化されたアイテムのみを購入できます。アイテムを作成すると、Play Consoleに有効化ボタンが表示されます。アイテムを作成するプロセスについては、最初の記事で詳しく説明しました。

4. デバイスでのテストが、テスターのGoogleアカウントから行われていることを確認します (つまり、このテストトラックにテスターとして登録され、必要なすべての技術的アクセス権を持っている必要があります)。当たり前のようですが、実際に起こることです。このようなエラーが発生した場合は、この点も確認する必要があります。

5. 購入テストに使用されるビルドのapplicationIdは、Play ConsoleのapplicationIdと完全に一致する必要があります。これは、デバッグビルドにサフィックスが追加されている場合に特に重要です。

6. テスターのメールアドレスをアカウント (アプリケーションではなく) の左側のメニューにある [設定] → [ライセンステスト] セクションに追加して、実際のカードではなくテストカードから無料でアイテムを購入できるようにします。もう一つのメリットは、この場合の定期購入にはテスト期間があることです。このエラーとは関係ありませんが、知っておくと便利です。

まとめ

エラーによって作業が非常に複雑になる可能性があるため、エラーがどのように発生するかを理解することが常に重要です。アイテムにアクセスするために必要な手順の数を考慮すると、最も簡単な方法はITEM_UNAVAILABLEを検出することです。チェックリストがお役に立てば幸いです。

Adapty SDKは、エラー処理を効率化するほか、基本的な定期購入分析、コホート分析 (cohort analysis)、ペイウォール (paywall) の簡単なテスト、分析サービスとの統合、サーバーエラーの検証など、多くのメリットを提供しています。今すぐお試しください。