Google Play 請求サービスをテストする

Google Play 請求サービスの実装後は、アプリ内アイテムの購入をテストできます。このドキュメントには、次の 5 つの章があります。

テストの準備をする

Google Play 請求サービスの実装に関するテストの準備をするには、次の手順を行います。

  1. アプリを Google Play のクローズド テスト版トラックまたはオープンテスト版トラックに公開します。テスト版トラックにアプリを公開した後、テスターがアプリを利用できるまでに数時間かかることがあります。
  2. 各テスターはアプリのテストにオプトインする必要があります。テスト用オプトイン URL には、テスター向けの注意事項とオプトイン確認のリンクが表示されます。

Android 1.6 以降を搭載したハードウェア デバイスであればテスト可能ですが、Google Play アプリの最新バージョンがインストールされている必要があります。Android 向けアプリの開発に使うデバイスの設定方法に関する一般情報は、ハードウェア デバイスの使用についてのページをご覧ください。

Google Play 請求サービス アプリを単独テストする

静的なレスポンスでテストする

Google Play 請求サービスでは、予約済みアイテム ID および関連する静的なレスポンスの組み合わせが提供されるので、それらを使って Google Play 請求サービスの実装をテストできます。これらのレスポンスにより、アプリでメインの Google Play のレスポンスが適切に処理されていることを確認できます。テスターの参加前や、アプリが公開前の状態であっても、これらの静的なレスポンスを使用して Google Play 請求サービスの実装をテストできます。

静的なレスポンスを使って実装をテストするには、予約済みアイテム ID を持つ特別なアイテムを使い、Google Play 請求サービスをリクエストします。予約済みアイテム ID は、それぞれ Google Play から固有の静的なレスポンスを返します。予約済みアイテム ID を使った Google Play 請求サービス リクエストの場合、送金処理は発生しません。また、この場合はお支払い方法の指定はできません。

注: 静的なレスポンスは定期購入のテストには使用できません。

アプリのアイテムリストに、予約済みアイテムを含める必要はありません。Google Play では、すでに予約済みアイテム ID が認識されています。また、予約済みアイテム ID を使った静的なレスポンス テストを実施するために、Play Console にアプリをアップロードする必要もありません。アプリをデバイスにインストールし、デバイスにログインして予約済みアイテム ID を使って課金をリクエストするだけです。

注: 以前は、公開前のドラフト版をアップロードしてアプリをテストできました。この機能は今後サポートされません。ただし、Google Play ストアにアップロードする前に、静的なレスポンスを利用してアプリをテストできます。詳細については、静的なレスポンスでテストするをご覧ください。

Google Play 請求サービスの静的なレスポンスをテストするために、次の 3 つの予約済みアイテム ID を利用できます。

  • android.test.purchased

    このアイテム ID を使って Google Play 請求サービスをリクエストすると、Google Play はアイテムの購入ができたとみなしてレスポンスを返します。レスポンスには JSON 文字列が含まれており、疑似購入情報(例: 疑似購入 ID)が書き込まれています。

  • android.test.canceled

    このアイテム ID を使って Google Play 請求サービスをリクエストすると、Google Play は購入がキャンセルされたとみなしてレスポンスを返します。クレジット カードが無効、または課金前にデベロッパーがユーザーからの購入をキャンセルしたなど、注文プロセス内でエラーが発生したケースに相当します。

  • android.test.item_unavailable

    このアイテム ID を使って Google Play 請求サービスをリクエストすると、Google Play は購入済みアイテムがアプリのアイテムリストに含まれていないとみなしてレスポンスを返します。

予約済みアイテム ID を使って Google Play 請求サービスをリクエストするには、通常の REQUEST_PURCHASE リクエストを作成し、アプリのアイテムリストにある実際のアイテム ID を使う代わりに、予約済みアイテム ID を使います。

予約済みアイテム ID を使ったアプリのテストは、次の手順で行います。

  1. 購入フローの中で 3 つの予約済みアイテム ID のいずれかを使用するようにアプリを変更します。アイテム ID を使用して購入する方法について詳しくは、アプリ内アイテムの購入を有効にするをご覧ください。
  2. Android デバイスにアプリをインストールします。

    エミュレータでは Google Play 請求サービスのテストを実施できません。Google Play 請求サービスをテストするデバイス上にアプリをインストールする必要があります。

    デバイスにアプリをインストールする方法について詳しくは、デバイスでの実行についてのページをご覧ください。

  3. デベロッパー アカウントでデバイスにログインします。

    予約済みアイテム ID のみを使用してテストを実施する場合、テスト アカウントを使う必要はありません。

  4. サポート対象バージョンの Google Play アプリ、または MyApps アプリがデバイスで実行されていることを確認します。

    Android 3.0 が搭載されているデバイスの場合、Google Play 請求サービスにはバージョン 5.0.12 以降の MyApps アプリが必要です。その他のバージョンの場合、Google Play 請求サービスにはバージョン 2.3.4 以降の Google Play アプリが必要です。Google Play アプリのバージョンを確認するには、アプリを起動して [設定] メニューを開き、下にスクロールしてバージョン情報を表示します。

  5. アプリを実行し、予約済みアイテム ID を使用して購入します。onPurchasesUpdated() 内のコードで静的なレスポンスが正しく処理されることを確認します。onPurchasesUpdated() の実装について詳しくは、アプリ内アイテムの購入を有効にするをご覧ください。
  6. 他の予約済みアイテム ID を使用してテストを繰り返します。

: 予約済みアイテム ID を使って Google Play 請求サービスをリクエストすると、通常の本番環境の Google Play システムがオーバーライドされます。予約済みアイテム ID に対して Google Play 請求サービスのリクエストを送信すると、サービス品質が本番環境と異なる場合があります。

購入フロー全体をテストする

静的なレスポンス テストを終えて、アプリ内で署名認証が機能することを確認したら、実際にアプリ内購入を行って Google Play 請求サービスの実装をテストします。実際のアプリ内購入のテストを行うことで、ユーザーが実際に行う Google Play での本購入やアプリ内での精算フローなど、Google Play 請求サービスのプロセス全体をテストできます。

注: クローズド テスト版トラックに公開すると、アプリの包括的なテストを実施できます。これにより、Google Play ストアにアプリを公開できるようになりますが、利用できるのはデベロッパーが指定したテスターに限られます。

実際のアプリ内購入プロセスで Google Play 請求サービスの実装テストをするには、テスト アカウントを使用する必要があります。デフォルトでは、登録されている唯一のテスト アカウントはデベロッパー アカウントに関連付けられていますが、Google Play Console を使用して追加のテスト アカウントを登録できます。これまでにテスト アカウントを設定したことがない場合は、テスト アカウントを設定するをご覧ください。

アイテムが公開されている場合のみ、アイテムリストのアイテムをテスト アカウントで購入できます。

Google Play 請求サービスの実装を本購入のプロセスでテストする手順は次のとおりです。

  1. Play Console でクローズド テスト版トラックにアプリをアップロードします。

    注: 最初のアプリのアップロード後は、アプリのデベロッパー版を Play Console にアップロードしなくても、ライセンス テスターはアプリから購入を行えます。これにより、デベロッパーは新しい版を毎回アップロードすることなく、デバッグされた署名付きのビルドを使用して変更を加えることができます。

    注: 以前は、公開前のドラフト版をアップロードしてアプリをテストできました。この機能は現在サポートされていないため、代わりにクローズド テスト版トラックまたはオープンテスト版トラックに公開する必要があります。詳しくは、ドラフト版アプリのサポート終了についてのページをご覧ください。

  2. Play Console でアプリ内アイテムを作成します。詳細については、1 回限りのアイテムの作成についてのページまたは定期購入の作成をご覧ください。
  3. Android デバイスにアプリをインストールします。エミュレータでは Google Play 請求サービスのテストを実施できません。デバイスにアプリをインストールする方法について詳しくは、デバイスでの実行についてのページをご覧ください。
  4. サポート対象バージョンの Google Play アプリ、または MyApps アプリがデバイスで実行されていることを確認します。Android 3.0 が搭載されているデバイスの場合、Google Play 請求サービスにはバージョン 5.0.12 以降の MyApps アプリが必要です。その他のバージョンの場合、Google Play 請求サービスにはバージョン 2.3.4 以降の Google Play アプリが必要です。Google Play アプリのバージョンを確認するには、Google Play をアップデートする方法についてのページをご覧ください。
  5. アプリでアプリ内購入を行います。

注: デバイスのメイン アカウントを変更する唯一の方法は、出荷時設定へのリセットを行うことですが、必ず最初にメイン アカウントでログインするようにします。

Google Play 請求サービス アプリをユーザーテストする

テスト アカウントを設定する

テスターのアカウントを設定するには:

  1. Play Console を使用して、テスターに購入してもらうアプリ内アイテムをアップロードし、公開します。APK 自体の公開前に、アプリ内アイテムのアップロードと公開ができる点に注意してください。
  2. Developer Console を使用して、ライセンス テスターのアカウントを作成します。
    1. [設定] > [アカウントの詳細] に移動します。
    2. [ライセンス テスト] で、[テスト用のアクセス権がある Gmail アカウント] にテスターのメールアドレスを追加します。
    3. 変更内容を保存すると、15 分以内にテスターはアプリ内アイテムの購入を開始できるようになります。

: テスト アカウントは、テスターの Android デバイス上に存在する必要があります。デバイスに複数のアカウントがある場合、アプリをダウンロードしたアカウントで購入することになります。どのアカウントでもアプリをダウンロードしていない場合は、最初のアカウントで購入します。ユーザーは購入ダイアログを展開すると、購入に使うアカウントを確認できます。

テスターにテスト購入を依頼する

テスト アカウントを設定したら、テスト購入をするようにユーザーに依頼します。テスト購入プロセスの詳細は、次のとおりです。

  • ユーザーは通常のユーザーと同じアプリの購入フローを使用します。
  • ユーザーは少なくとも 2 回購入する必要があります。「必ず承認される」お支払い方法で 1 回、「必ず不承認になる」お支払い方法で 1 回です。この 2 つのお支払い方法で、お支払いが承認された場合と、不承認の場合に、アプリが正しく反応することを確認できます。図 1 は、購入フロー内に表示されるこれらのテスト用のお支払い方法を示しています。
    図 1. ライセンスのテストユーザー向けのテスト用のお支払い方法のオプション
    ライセンス テストでユーザーが利用できるのは、この 2 つのお支払い方法のみです。これらのお支払い方法を使用すると、購入フローで結果がすぐに返されます。
  • テスト購入では、税金は計算されません。
  • ライセンス テスターの購入に対しては課金されません。
  • Google Play では、購入ダイアログの中央に通知を表示することによって、テスト購入が示されます。

注: 同じアプリ内アイテムに対して複数のテスト購入を実行できるようにするには、各購入後に消費済みとしてアイテムにマークを付けます。マークを付けるには、consumeAsync() を呼び出します。

実際のアカウントでテストする

Google Play 請求サービスに対応したアプリの発売準備をする際は、Google Play のクローズドまたはオープンのリリース オプションを活用して、全ユーザーにアプリを配信する前に、実装の検証と読み込みテストを実施することができます。

クローズドまたはオープンのテストグループを利用すると、ユーザーによる Google Play からのアプリ インストール、アプリ内アイテムのテストが可能になります。本購入をすると、Google Play での通常のお支払い方法で実際にユーザーのアカウントに課金されます。

注: クローズドまたはオープンのテスト配信グループにテスト用ライセンス アカウントを含めた場合、そのアカウントのユーザーはテスト購入のみ可能です。

1 回限りのアイテム固有の機能をテストする

アプリ内プロモーションをテストする

アプリでアプリ内プロモーションをサポートしている場合、次のケースをテストします。

ユーザーがアプリ内でプロモーション コードを精算

アプリ内の購入フローに沿ってユーザーがプロモーション コードを精算した場合は、アプリ内課金リクエストを行うに記載のとおり、システムがアクティビティの onActivityResult() メソッドを呼び出して購入を処理します。ユーザーが代金、またはプロモーション コードで支払い、onActivityResult() が購入を正しく処理したことを確認してください。

ユーザーが Google Play ストアでプロモーション コードを精算

Play ストアでプロモーション コードを精算した後のワークフローは、何通りか考えられます。そのワークフローを 1 つずつ確認しましょう。

アプリがインストールされていない場合

ユーザーが、デバイスにインストールされていないアプリのプロモーション コードを精算しようとした場合、Play ストアはユーザーにアプリをインストールするよう要求します(アプリはインストールされているが、最新版ではない場合は、アプリのアップデートを要求します)。アプリがインストールされていないデバイスで、次のシーケンスをテストします。

  1. ユーザーが Play ストアでアプリのプロモーション コードを精算します。Play ストアがユーザーにアプリをインストールするよう要求します。
  2. ユーザーがアプリをインストールし、起動します。起動時にアプリが getPurchases() を呼び出し、ユーザーによるプロモーション コードでの購入を正しく検知することを確認します。
アプリがインストールされているが、実行されていない場合

アプリがインストールされたデバイスでプロモーション コードを精算する場合、Play ストアはユーザーにそのアプリに切り替えるよう要求します。アプリはインストール済みだが実行中ではないデバイスで、次のシーケンスをテストします。

  1. ユーザーが Play ストアでアプリのプロモーション コードを精算します。Play ストアがユーザーにアプリを切り替えるよう要求します。
  2. ユーザーがそのアプリを起動します。起動時に、アプリが getPurchases() を呼び出し、ユーザーによるプロモーション コードでの購入を正しく検知することを確認します。
アプリがインストール済みで実行中の場合

アプリが実行中のデバイスでプロモーション コードを精算する場合、Play ストアは PURCHASES_UPDATED インテントでアプリに通知します。次のシーケンスをテストします。

  1. ユーザーがアプリを起動します。PURCHASES_UPDATED インテントを受信できるよう、アプリが正しく登録されているかを確認します。
  2. ユーザーは手動またはプロモーション コードを含む生成された URL のいずれかで Play ストア アプリを起動し、プロモーション コードを精算します。Play ストアが PURCHASES_UPDATED インテントを発行します。アプリの BroadcastReceiver.onReceive() コールバックが呼び出され、インテントを処理します。
  3. getPurchases() を呼び出して、onReceive() メソッドでインテントに応答する必要があります。アプリがこのメソッドを呼び出し、ユーザーによるプロモーション コードでの購入を正しく検知することを確認してください。
  4. ユーザーはアプリに戻ります。ユーザーがアイテムを購入したことを確認します。

定期購入固有の機能をテストする

1 回限りのアイテムと定期購入の購入フローは似ていますが、定期購入には更新の承認や不承認などの追加のシナリオがあります。両方の状況でアプリをテストするために、「テストカード、常に承認」と「テストカード、常に不承認」のお支払い方法を使用します。これらのお支払い方法を使用して、定期購入の購入後のシナリオをテストします。

定期購入の更新をテストする

テスト用の定期購入は、簡単にテストできるように通常よりも短時間で更新されます。次の表は、定期購入のさまざまなテスト更新時間を示しています。

注: これらはおおよその時間であるため、イベントの正確な時間は若干異なる可能性があります。この違いを補正するには、定期購入の有効期限ごとに API を呼び出して現在のステータスを表示してください。

本番の定期購入の期間テスト用の定期購入の更新
1 週間5 分
1 か月5 分
3 か月10 分
6 か月15 分
1 年30 分

注: テスト用の定期購入は最多 6 回更新されます。

無料試用など、定期購入で利用できる時間ベースの機能もテスト用に期間が短くなっています。次の表は、時間ベースの定期購入機能に関するテスト期間を示しています。

機能テスト期間
無料試用3 分
お試し価格期間定期購入のテスト期間と同じ
猶予期間(3 日間と 7 日間の両方) 5 分
アカウントの一時停止10 分

更新頻度のテストシナリオ

更新頻度をテストする間隔を示すテストシナリオを表示するには、[表示 / 非表示] をクリックしてください。

完了したテスト購入をキャンセルする

Google Play ではユーザーごとに完了したテスト購入を蓄積していますが、支払いのプロセスには渡していません。

テスト購入は自動でキャンセルされないため、テスト購入を手動でキャンセルして、テストを続けたいケースもあるかもしれません。その場合、Play ストアでアプリのページを開きます。キャンセルしたいテスト購入が定期購入の場合、Purchases.subscriptions API の cancel() メソッドを使用することもできます。

重要: Purchases.subscriptions API の refund()revoke() メソッドは、テスト購入に対応していません。

次の手順

Google Play 請求サービスの実装テストが終了すれば、Google Play でアプリを公開する準備は完了です。準備署名Google Play への公開については、通常の手順で行ってください。