Android 11 デベロッパー プレビュー 2 が公開されました。ぜひお試しのうえ、フィードバックをお寄せください

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

Google Play 請求サービスの実装を完了したら、アプリ内アイテムの購入をテストできます。このドキュメントでは以下の項目について説明します。

テストの準備をする

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 を使用した静的レスポンス テストを実施する際、Google Play Console にアプリをアップロードする必要もありません。アプリをデバイスにインストールして、デバイスにログインし、予約済みアイテム ID を使用して Google Play 請求サービスをリクエストするだけです。

注: 以前は、公開前のドラフト版をアップロードしてアプリをテストできました。この機能は今後サポートされません。代わりに、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 アプリが必要です。それ以外のバージョンの Android の場合、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. Google Play Console でクローズド テスト版トラックにアプリをアップロードします。

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

    注: 以前は、公開前のドラフト版をアップロードしてアプリをテストできました。この機能は現在サポートされていません。代わりにクローズド テスト版トラックまたはオープンテスト版トラックにアプリを公開する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

ユーザーがアプリ内でプロモーション コードを利用する

ユーザーがアプリの購入フローに沿ってプロモーション コードを利用した場合は、Google Play 請求サービス リクエストについての説明に記載のとおり、システムはアクティビティの onActivityResult() メソッドを呼び出して購入を処理します。ユーザーが代金を支払う場合と、プロモーション コードを利用する場合のそれぞれについて、onActivityResult() によって購入が正しく処理されることを確認します。

ユーザーが Google Play ストア内でプロモーション コードを利用する

ユーザーが Play ストア内でプロモーション コードを利用した場合、いくつかのワークフローが考えられます。各ワークフローをそれぞれ検証します。

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

ユーザーが、デバイスにインストールされていないアプリのプロモーション コードを利用した場合は、アプリのインストールを求めるメッセージが 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. onReceive() メソッドが getPurchases() を呼び出してインテントに応答します。アプリがこのメソッドを呼び出し、ユーザーがプロモーション コードを使用して行った購入を正しく検出していることを確認します。
  4. ユーザーがアプリに戻ります。購入したアイテムをユーザーが所持していることを確認します。

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

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

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

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

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

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

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

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

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

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

更新頻度のテストシナリオを表示するには、[表示 / 非表示] をクリックしてください。各テストシナリオにおいて、どのような間隔で更新が行われるのかが示されています。

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

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

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

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

次の手順

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