要点
エミュレータはテスター12人に数えられる？要件が挙げているのはテスターと継続的なオプトインであり、デバイスの種類ではありません
エミュレータはアプリのテストに使ってください。クローズド テストの参加者をエミュレータで作り出してはいけません。Googleが公開している要件は、12人のテスターが14日間連続でオプトインしていることです。このガイドで確認した要件と技術ドキュメントには、エミュレータからの参加がその最低人数に数えられるかどうかは明記されていません。開発者に代わってこうしたテストを運営してきたPrimeTestLabの推奨は、ドキュメントよりも一歩踏み込んだものです。自分のビルドをエミュレータで動かすのは通常の開発であり、まったく問題ありません。エミュレータのインスタンスを12人の代わりに立てるのは、私たちなら取らない近道です。そして、偽のGoogleアカウントを作ってそこからオプトインするのは操作行為であり、私たちの経験では、追加テストを求めて差し戻されるか却下されるタイプのテストです。Play Consoleで進捗を確認し、実際にアプリを使って気づいたことを伝えてくれる人を集めてください。
| 質問 | 決め手になるもの | 答えがある場所 |
|---|---|---|
| エミュレータでアプリを動かしてテストできる？ | 選んだシステム イメージと、アプリそのもの。 | Android Studioのエミュレータのドキュメント。これがこのツールの本来の用途です。 |
| テスターはエミュレータでクローズド テストのビルドを開ける？ | Googleアカウント、オプトインが受け付けられたかどうか、公開済みのリリース、そして自分で設定した制限。 | Play Consoleのテスト設定。アカウントの対象可否、リリースの提供状況、互換性、そして設定したデバイス チェック。 |
| Play Integrityはそれについて何を報告する？ | デバイスの状態、Androidのバージョン、そして自分のアプリやバックエンドが読み取るフィールド。 | Play Integrityのドキュメント。応答するのは自分のアプリとバックエンドに対してであり、Play Consoleはそれとは別に報告します。 |
| その人は12人に数えられる？ | テスターがクローズド テストに14日間、継続してオプトインしているかどうか。 | テスト要件。デバイスの種類や整合性については何も述べていません。 |
目次
Googleが求めていること、そして誰に適用されるか
Googleの要件GoogleのPlay Consoleヘルプによると、2023年11月13日以降に作成した個人用アカウントの開発者は、製品版として公開する前にクローズド テストを実施し、12人以上のテスターが少なくとも14日間連続でオプトイン（テストへの参加を選択）した状態を満たす必要があります（アプリのテスト要件）。これを満たすまで、製品版と事前登録はロックされたままです。満たせば申請の対象になりますが、承認は別途の審査です。組織用アカウントはこのルールの対象外です。要件そのものはテスター12人要件の解説で詳しく説明しています。
2023年11月13日以降に作成した個人用デベロッパー アカウントでは、製品版へのアクセスを申請する前に、12人以上のテスターが14日間連続でオプトインしたクローズド テストをアプリで実施する必要があります。
Googleは、連続とは何を指すのかも明示しています。オプトインしたあと14日未満でテストをやめてオプトアウトしたテスターは要件に数えられず、あとで再びオプトインしても、14日間は連続していなければなりません。最低人数は20人でしたが、Googleは2024年12月11日に12人へ引き下げ、その変更を2023年の発表に追記しました。14日間という期間は変わっていません。
要件を書かれたとおりに読む：問われているのはオプトインの状態
要件がどの名詞を使い、どの名詞を使っていないかに注目してください。挙げられているのはテスターと継続的なオプトインであり、デバイスの機種でも、認定の状態でも、整合性の判定でもありません。ここから2つの誤読が生まれます。アンインストールはオプトアウトとは別の操作なので、アンインストールしただけで自動的に期間が途切れるわけではありません。また、1人が離脱しても他の人がリセットされることはありません。継続性は参加登録ごとに追跡されます。
デベロッパーのデバイス確認は別の作業
Googleが物理的なAndroidデバイスを求めている箇所は1つあり、テスターのルールと取り違えやすいものです。新しい個人用デベロッパー アカウントは、root化されていないAndroid 10以降の物理的なAndroidデバイスで、アカウント所有者としてログインした状態でデバイス確認を完了する必要があります（デバイス確認の要件）。Googleによれば、あとで再度の確認を求められることもありますが、必ずしも同じデバイスである必要はありません。いずれにしても、これはアカウント所有者がデバイスを使えることを証明する手続きであり、テスターが何を使うかについては何も述べていません。
そもそも、この要件は自分に適用されるのか？
適用されるのは、2023年11月13日以降に作成した個人用アカウントです。それより前の個人用アカウントと組織用アカウントは対象外なので、「組織用アカウントを取る」というのは、巧妙な抜け道ではなく適用対象の違いにすぎません。組織用アカウントには、Googleが確認できる登録済みの組織が必要で、通常はD-U-N-S番号を使います。D-U-N-S番号は無料で申請できます。両者の比較はGoogle Playの個人用アカウントと組織用アカウントの違いをご覧ください。
エミュレータはテスター12人に数えられるのか？
ここで確認したドキュメントのどこにも、それにイエスかノーで答えるものはありません。だからこそ、このガイドの残りの部分では、明記されていることと推測されていることを分けています。主張は4つの区分のいずれかに入り、よくある間違いは、下の区分にあるものを上の区分へこっそり格上げすることです。
満たさなければならないルール。12人のテスター、14日間連続、2023年11月13日という基準日、そして満たせば申請できるということ。
挙動についての正確な説明。整合性判定、システム イメージ、テストの設定。誰を数えるかを決めるのとは別の目的で書かれています。
Google Play デベロッパー コミュニティやRedditのスレッド。ここで引用しているスレッドの推奨回答は、エミュレータではなく、実機のAndroidデバイスを持つ他の人に頼むよう勧めています。読む価値はありますが、ページ自体が内容は未検証の可能性があると注意しており、Googleのホスト名で公開されていてもポリシーではありません。
私たち自身の判断。最低人数より多く集めること、そしてエミュレータや偽のアカウントで参加者を作り出さないこと。この仕事をしてきた経験からの助言であってルールではなく、私たちはテスト支援を販売している立場です。
ドキュメント化されており、引用しても安全
Googleのポリシー、ヘルプページ、または開発者向けドキュメントに明記されているもの。
- 要件そのもの。2023年11月13日以降に作成した個人用アカウントについて、12人のテスターが14日間連続でオプトインすること。
- 製品版へのアクセスの申請では、テストをどう実施したか、どんなアプリか、テストの結果として何を変更したかが問われること。
- デベロッパー プログラム ポリシーは、不正な手段で掲載順位、評価、レビュー、インストール数を操作することを禁じていること。
- Googleはリリース前に実機でテストすることを推奨し、複数のバージョンと画面サイズにわたるエミュレータでのテストをドキュメント化していること。
明記されていない：推測しないこと
もっともらしく聞こえるが、ここで確認したドキュメントには存在しないもの。
- Play Integrityの判定が、テスターを12人に数えるかどうかを決めるということ。
- 加速度センサーのノイズ、バッテリー温度のばらつき、GPSのずれ、タッチのテレメトリー、IPアドレスの集中、アカウントの年数など、名指しされた検出シグナル。
- 「エミュレータのX%が検出される」といった具体的な数字。正確なパーセンテージは、測定値ではなく根拠のないものとして扱ってください。
- 一律の報告遅延、1日あたりの必要セッション数、期間中の必要アップデート回数。
オプトイン済みテスター、インストール済みオーディエンス、製品版へのアクセス
この議論の大半は、実のところPlay Console上の3つの数字が同じものとして扱われていることから生じています。この3つは別物です。
| 見ている数字 | その意味 | そこから分からないこと |
|---|---|---|
| オプトイン済みのテスター | このトラックのオプトインリンクを承諾したアカウント。要件はこの名詞と、オプトイン状態が続いた期間を軸に書かれています。 | 誰かがインストールしたか、アプリを開いたか、役立つフィードバックをくれたか。 |
| インストール済みオーディエンス | Googleの定義では、過去30日間に使用した少なくとも1台のデバイスにアプリをインストールしているユーザーです。使用されている必要があるのはデバイスであって、アプリではありません。 | オーディエンス指標であり、製品版へのアクセスのカウンターではなく、セキュリティ チェックに合格したデバイスの数でもありません。 |
| 製品版へのアクセスのチェックリスト | 何人のテスターが何日間連続でオプトインしているかを示すダッシュボードの項目。要件はこれで測られます。 | 特定の人がそこに含まれる、または含まれない理由。それは参加登録の状態で確認します。 |
最低条件を満たすことと、説得力のあるテストは同じではありません。12人のテスターが14日間連続でオプトインしたあとでも、テスターのエンゲージメントが不十分な場合、Googleは追加のテストを求めることがあります。1日あたりのセッション数の割り当ては公開されていないため、目指すべきは、忙しそうに見せるために作り出した活動ではなく、実際の利用と実際のフィードバックを生んだテストです。
Play以外からのインストールは別の経路であり、誰の参加登録にもなりません。Android App Bundleは公開用の形式であってインストール可能なファイルではないため、その経路でインストールされるのは、そこから生成されたAPKです。そして、手動インストール、共有リンク、内部アプリ共有など、ファイルがどのような形で届いても、それによって誰かのオプトインリンクが承諾されることはありません。
これらの数字の間に開きがあるのは症状であって、診断ではありません。オプトインが12件なのにインストール済みオーディエンスが少ないことには、ごく普通の説明がつきます。オプトインしたもののインストールしていない、最近使っていないデバイスにインストールした、レポートに遅れがある、リリースがその人に提供されていない、などです。
ここで言えること、言えないこと
Googleはテスト要件とこれらの指標の定義を公開していますが、個々の集計結果の一つひとつについての説明や、一律の報告遅延は公開していません。該当する指標のドキュメントを読み、観測された遅れと公開された保証を区別し、下のチェックリストを順に確認してください。
テスターがクローズド テストのビルドを見つけられない、またはインストールできない場合
環境のせいにする前に、次の設定上の問題を確認してください。実機にもエミュレータにも同じように当てはまります。
-
01
Googleアカウントが違う
オプトインリンクを承諾したアカウントが、デバイスにログインしていてPlay ストアで選択されているアカウントと同じでなければなりません。複数のGoogleアカウントが入ったスマートフォンで「アプリを利用できません」と報告されたら、まずここを確認してください。
-
02
オプトインが完了していない
メーリング リストやリンクしたGoogle グループは、その人を対象にするだけで、参加登録にはなりません。本人がオプトインリンクを開いて承諾する必要があり、グループのメンバーシップが反映されるまで少し時間がかかることもあります。クローズド テストのビルドはPlay ストアの検索にも表示されないため、テスターは渡されたオプトインリンクとストアのリンクからアクセスします。
-
03
トラックの競合
そのアカウントが内部テストにも参加している場合は、クローズド テストにオプトインする前にそちらを退出してもらってください。トラックが重なっている場合、対象ユーザーには利用可能な最も高い互換バージョン コードが配信されるため、確認しているリリースとは異なることがあります（テストの設定）。
-
04
そのトラックに公開中のリリースがない
クローズド テストのトラックには、想定どおりのバージョンと割合で実際にロールアウトされた公開済みリリースが必要です。下書きは誰にも配信されません。ロールアウトを停止するとそれ以降の配信は止まりますが、そのバージョンをすでに受け取ったテスターはインストールしたままにできるため、どのバージョンが配信されているかを確認してください。Googleはまた、新しいテスト用リンクと、その後の変更が利用可能になるまで数時間かかることがあるとしています。
-
05
自分で設定した提供範囲
国別の提供範囲とデバイスの制限は自分で設定するものです。国については、GoogleはテスターのGoogle Playアカウントの国を参照しますが、これは必ずしも本人がいる場所とは限りません。また、整合性に基づくストア掲載情報のデバイス チェックを有効にしていると、一部のデバイスでアプリの表示やインストールが止まることがあります。これは自分で設定したアクセス制限であって、どのテスターが数えられるかの証拠ではありません。
-
06
環境またはビルドそのもの
上の5つを確認したあとで初めて。システム イメージが適切でないエミュレータはそもそもPlay ストアにログインできず、Android Studioは特定のイメージの既知の問題を公開しています。
-
07
ブロックしているのはストアではなく自分のアプリ
ダウンロードはできるのにアプリが起動を拒否するなら、それはPlayの提供状況ではなく自分自身の制御です。テスターがビルドを入手できないと結論づける前に、自分のアプリやバックエンドがPlay Integrityの応答をどう扱っているかを確認してください。
それでも数字がおかしく見える場合は、個別の解説記事があります。テスターを追加したのにオプトインが0人、テスターにアプリが提供されない、Google グループのテスター アクセスです。それぞれ、よくある設定上の原因と、さらに実行すべき確認を扱っています。
エミュレータでのテストが役立つとき
エミュレータは優れたツールで、Google自身も1つ作っています。Android Studioに同梱されており、Googleはさまざまなバージョンと画面サイズのAndroidでテストすることを推奨しています。間違いはエミュレータを使うことではなく、本来の用途ではない仕事をエミュレータに期待することです。
PrimeTestLabの推奨開発中の高速な反復。手元にないAndroidのバージョンや画面サイズ。タブレット、ロケール、ダークモード、右から左へのレイアウト。クラッシュを必要なときに再現すること。
独立した判断。1台のマシンで5台の仮想デバイスを動かしても、それは1人の意見にすぎません。
人々が実際に持っているハードウェア上でのアプリの挙動。パフォーマンス、バッテリー、カメラ、通知、ネットワークの切り替わり、メーカー独自のAndroidビルド。Googleはリリース前に実機でテストすることを推奨しています。
対象可否の保証。良い端末を使っても、テスターについて書かれた要件は満たせません。
ツールでは補えない部分。オプトインし、アプリをインストールしたままにし、想定していなかった操作を試し、どこで戸惑ったかを教えてくれる人です。
デバイスのカバー範囲。12人のテスターが似たような端末を持っていることもあるため、エミュレータでの確認には引き続き価値があります。
Android Studioのイメージ、Play対応イメージ、BlueStacks
エミュレータはどれも同じではなく、違いはシステム イメージにあります。AOSPイメージにはGoogleアプリが入っていません。Google APIsイメージはGoogleサービスを追加しますが、Play ストアはありません。Google Playイメージにはストアが含まれており、Android Studioは、これに対応するデバイス プロファイルにPlayのロゴを付け、そのPhoneプロファイルがCTS準拠であることをドキュメントに記しています。仮想デバイスを作成する際、プロファイルとシステム イメージは別々に選ぶもので、その中でログインしてインストールするにはPlayイメージが必要です。BlueStacksもPlay ストアへのログインをドキュメント化しています。ただ、どれも対象可否を決めるものではありません。ストアにたどり着けることと、テスターとして数えられることは別の結果です。
Androidスマートフォンを持っていないが、誰かのテストを手伝いたい場合
これは、開発者がテスター集団を作り出すのとは別の状況であり、非難ではなく率直な答えに値します。自分の持っているマシンで友人のテストを手伝うことは欺瞞ではありません。誰にも約束できないのは結果です。Googleは参加者一人ひとりがどう数えられるかを公開していないからです。結果が重要なら、Androidスマートフォンを借りるか、古くても互換性のある端末を使ってください。代わりにエミュレータを使うなら、開発者がそれを踏まえてテストを計画できるように伝えておきましょう。
クラウドのデバイス ラボとリリース前レポート
Firebase Test LabはGoogleのインフラ上のデバイスでアプリを実行し、Play Consoleのリリース前レポートはビルドを自動的にクロールします。どちらも正当な自動QAです。ただし、どちらも参加者ではありません。自動実行はオプトインせず、14日間オプトイン状態を維持することもなく、オンボーディング画面が分かりにくかったと教えてくれることもありません。
Play Integrityが立証すること、しないこと
Googleの技術ドキュメントPlay Integrityは、この議論の大半が拠り所にしている技術なので、何のためのものかを知っておく価値があります。developer.android.comによれば、このAPIは「helps you check that user actions and server requests are coming from your genuine app, installed by Google Play, running on a genuine and certified Android device」（ユーザーの操作とサーバー リクエストが、Google Playによってインストールされた正規のアプリから、正規で認定済みのAndroidデバイス上で行われていることを確認するのに役立つ）ためのものです（整合性判定）。その答えの受け手は自分のアプリと自分のバックエンドです。Play Consoleも整合性の応答を開発者に報告し、ストア掲載情報の別の設定でインストールできるデバイスを制限することもできます。これらはいずれもクローズド テストの要件ではなく、要件として読むべきものでもありません。
「The app is running on a genuine and certified Android device.」（アプリは正規で認定済みのAndroidデバイス上で動作している。）Android 13以降では、ブートローダーがロックされていてOSが認定済みのメーカー製イメージであることを示す、ハードウェアに基づく証明が伴います。それより前のバージョンでは、ソフトウェアに基づく評価になることがあります。
APIからデバイスがどう見えるか。参加登録についての記述ではありません。「signs of attack (such as API hooking) or system compromise (such as being rooted)」（APIフックなどの攻撃の兆候、またはroot化などのシステム侵害）があるデバイス、あるいは「not running on a physical device (such as an emulator that does not pass Google Play integrity checks)」（Google Playの整合性チェックに合格しないエミュレータなど、物理デバイス上で動作していない）アプリとしてドキュメント化されています。このフィールドは複数のラベルを持ち得るため、これはラベルの欠落であって、「空欄」という値ではありません。
いくつもの異なる状況を含むため、そこから1つの原因へ逆算することはできません。「The app is running on a device that passes basic system integrity checks. The device may not be certified.」（アプリは基本的なシステム整合性チェックに合格したデバイス上で動作している。デバイスは認定済みでない可能性がある。）ここでのオプションとは、このラベルを受け取るかどうかを開発者が選ぶという意味で、テスターのオプトインとは何の関係もありません。
応答の設定であって、参加登録ではありません。「The app is running on a genuine and certified Android device with a recent security update.」（アプリは、最近のセキュリティ アップデートが適用された正規で認定済みのAndroidデバイス上で動作している。）Android 13以降では、デバイス整合性に加えて、関連するパーティションに最近のセキュリティ アップデートが適用されていることを意味します。Android 12以前はハードウェアに基づく起動時の整合性で評価され、同じ最新アップデートの検査はありません。
自分のバックエンド向けの高い基準。クローズド テストのしきい値ではありません。「Android-powered emulator with Google Play services」（Google Play開発者サービスを備えたAndroid搭載エミュレータ）向けにドキュメント化されたもので、これはGoogle Play Games on PCという文脈、つまり独自の要件を持つ別の配信面での話です。
Android Studioのテスト用エミュレータに対する判定ではありません。どちらの方向にも。デバイス、アプリ認識、ライセンスは別々のフィールド
3つのフィールドが1つであるかのように引用され、それらを混同するところから混乱の多くが始まります。デバイスのフィールドは環境を表します。アプリ認識のフィールドは、実行中のバイナリがGoogle Playから配信されたものと一致するかを表します。ライセンスのフィールドは利用資格を表し、アカウントにそのアプリのPlayでの利用資格がない場合はライセンスなしと報告されることがあります。Play以外からインストールされたビルドは、ライセンスと配信の話であって、ハードウェアの判定ではありません。
これらの例は用語を説明するためのものです。ここにあるものはGoogleに接続せず、デバイスを測定せず、参加を検証せず、製品版へのアクセスを予測しません。実際の応答は、アプリ、その設定、環境によって異なります。
| 環境 | 応答に含まれ得るもの | そこから分かること、分からないこと |
|---|---|---|
| 認定済みの端末、ロックされたブートローダー | デバイスのフィールドにMEETS_DEVICE_INTEGRITYが含まれ、最近のセキュリティ アップデートがあればMEETS_STRONG_INTEGRITYも含まれることがあります。 | デバイスがAPIの基準を満たしていること。その人がオプトインリンクを承諾したかどうかではありません。 |
| 標準のAndroid Studioエミュレータ | Googleは、Playのチェックに合格しないエミュレータを、デバイス認識のラベルが返されない理由の1つとしてドキュメント化しています。 | 自分のバックエンドがその結果に対応できること。ラベルの不在だけではエミュレータだと特定できず、誰かの参加登録についても何も語りません。 |
| Play以外からインストールされたビルド | これに答えるのは別のフィールドです。パッケージと証明書の一致はアプリ認識のフィールドが、そしてアカウントにPlayでの利用資格がない場合にライセンスなしと報告されることがあるのはライセンスのフィールドです。 | これらのフィールドが表すのはアプリ認識とアカウントの利用資格です。別々に読んでください。現在のコピーがどのようにインストールされたかの完全な記録ではなく、誰の参加登録にもなりません。 |
つまり、結論は限定的です。Play Integrityは、アプリが動作している環境について自分のバックエンドに多くを教えてくれますが、この技術ドキュメントのどこにも、その判定がどのテスターを数えるかを決めるとは書かれていません。
実践的な進め方と、エミュレータのあとの立て直し
14日間を、乗り越えるべきハードルではなく本物のベータ テストとして扱ってください。以下のステップは、Googleが公開している手順と私たち自身の推奨を組み合わせたものです。最低人数より多く集めることや、この形でフィードバックを整理することは提案であって、Googleの追加ノルマではありません。目標は本物のテストであり、カレンダーが進むのを待つことではありません。
PrimeTestLabの推奨署名済みのApp Bundleをアップロードし、クローズド テストのトラックを作成して、そこにリリースを公開します。そのトラックでリリースが公開されるまで、他のことは何も進みません。
メーリング リストは小規模で顔ぶれが分かっているグループに向いており、リンクしたGoogle グループのほうが規模を広げやすいです。どちらの場合も、一人ひとりが自分でオプトインリンクを承諾する必要があります。
助言であってルールではありません。人は興味を失ったり、スマートフォンを替えたり、オプトアウトしたりしますし、代わりの人が誰かの履歴を引き継ぐことはありません。その人の14日間は参加登録した時点から始まります。15～30人集めておくと余裕ができます。
テスターには、具体的に試してほしいことと、手軽に報告できる場所を用意してください。1日あたりのセッション数やスクリーンショットの割り当ては公開されていないので、活動を作り出す必要はありません。
テストによって正当化された変更をリリースし、何が報告され、何をしたかの簡単な記録を残してください。必要なアップデート回数は公開されていないので、想定上のアップデート ノルマを満たすためだけに変更を公開しないでください。
フォームでは、テストをどう実施しテスターとどう関わったか、どんなアプリで誰向けか、その結果として何を変更したかが問われます。記録をもとに答えてください。審査は通常7日以内ですが、それより長くかかることもあります。
すでにエミュレータでテストを実施してしまった場合
-
ダッシュボードで製品版へのアクセスのチェックリストを開き、何人のテスターが何日間連続かという表示を読んでください。それがテストの実際の状態です。
-
参加登録しているのに期待どおりに表示されない人については、上の診断リストを順に確認してください。デバイスについて何かを結論づける前に、設定を直してください。
-
正当に得た進捗は維持してください。テスターが使った環境を理由にテストがリセットされるとは、Googleが公開しているどこにも書かれていません。
-
本物の参加者を追加し、新しいテスター一人ひとりに、自分の14日間連続のオプトインを完了してもらってください。その人の期間は他の誰かの期間を引き継がないため、当初考えていた終了日を過ぎてテストを続ける必要があるかもしれません。アプリに本当の問題があるなら、それを見つけるのもこの部分です。
人を集めるのが難しいなら、テスター12人を見つける7つの正当な方法にある無料の選択肢から始めてください。そこから先は、テスターの招待方法、14日間連続ルール、テスト中のアプリ更新、製品版へのアクセスの質問票をご覧ください。
本物の参加と、ルールを破る行為
この不安の多くは、まったく異なる3つの行為をひとまとめにしてしまうことから生じています。3つは同じではなく、その結果も同じではありません。
コンパイルできるか、動くか、見た目が正しいかを確認するために自分のビルドをエミュレータにインストールするのは、Googleがそのために提供しているツールを使った通常のエンジニアリングです。欺瞞ではなく、取り締まりの対象でもありません。
これは、うまくいかなくなってから開発者が私たちに救済を求めてくるケースです。Googleはエミュレータの算入ルールを公開していないので、ルール違反だとは言えません。言えるのは、私たちがどうしているかです。私たちはこの方法でテストを組むことはなく、勧めもしません。製品版へのアクセスは本物のテストの証拠で判断され、私たちの経験では、仮想デバイスで組み立てた集団は、追加テストを求めて差し戻されるか、却下されるタイプのものです。
偽のGoogleアカウントを作り、エミュレータであれ何であれ、そこからオプトインするのはまったく別の行為です。Googleの評価、レビュー、インストールに関するポリシーは、不正な手段で掲載順位、評価、レビュー、インストール数を操作しようとすることを禁じています。
つまり、実務上の線引きは仮想化ではなく欺瞞にあります。誰が参加しているかを偽るために、アカウントを作ったり活動を自動化したりしないでください。Googleはインストール数やその他のストア指標の不正な操作を禁じています。ただし、そのポリシーだけでエミュレータ固有の算入ルールが定まるわけではありません。
1つ正しておきたい点があります。「さらにテストが必要」という返答は、それだけでアカウントに対する取り締まり措置が行われたことを意味しません。具体的なメッセージを読み、今後の審査での自動的なペナルティを推測するのではなく、指示どおりにテストを続けてください。その不承認のあとに何をすべきかで詳しく解きほぐしています。
実務上の結論は3つとも同じです。エミュレータは人を1人増やしてはくれないので、時間をかける価値があるのは、本物の人をどう効率よく見つけるかという問いだけです。
PrimeTestLabの位置づけ
利害関係の開示私たちはクローズド テストの支援を販売しているので、そのことを踏まえてこのセクションを読んでください。開発者がエミュレータに手を伸ばすのは、不正をしたいからではなく、2週間オプトイン状態を保ってくれる人を12人ほど見つけるのが本当に難しいからです。その部分を担うのが私たちです。
私たちがすること
12人以上の実在のテスターを集めて調整し、14日間ずっと参加登録を維持し、離脱した人がいれば補充します。テストは約4～6時間以内に開始します。
私たちが主張しないこと
どのサービスであれGoogleの判断を保証できるとか、テスターを雇えば審査がなくなるといったこと。製品版へのアクセスは、実施したテストとアプリそのもので判断されます。
費用をかけたくない場合
それはまったく妥当な選択で、テスター12人を集める7つの正当な方法にある無料の方法は機能します。お金の代わりに時間がかかるだけです。
すべてのプランに返金保証が付いています。決める前にステップごとの流れを読むこともできます。
よくある質問
Google Playのクローズド テストにエミュレータは使えますか？
アプリのテストには使ってください。Googleがエミュレータを作っているのはそのためです。公開されている要件は12人のテスターが14日間連続でオプトインすることで、ここで確認したどのドキュメントにも、エミュレータで参加したテスターがそこに数えられるかどうかは書かれていません。PrimeTestLabの推奨はドキュメントより一歩踏み込んでいます。自分のビルドをエミュレータでテストするのは問題ありません。エミュレータのインスタンスをテスターの代わりに使うのは、私たちならしないことです。そして、偽のGoogleアカウントからオプトインするのは操作行為であり、製品版へのアクセスが却下される原因になり得ます。
Play Integrityに合格しないと、そのテスターは数えられないのですか？
このガイドで確認したドキュメントには、そのようには書かれていません。Play Integrityは、アプリが動作している環境について自分のアプリとバックエンドに答えるもので、Googleはこれをクローズド テストの要件とは別にドキュメント化しています。整合性の判定からテスター数へとつなげる推論は、公開された手続きではなく推測として扱ってください。
必要なのは12人の人、12個のアカウント、それとも12台のスマートフォンですか？
要件は14日間継続してオプトインしているテスターについて書かれており、実務上は、自分のGoogleアカウントを持ち、オプトインリンクを承諾してくれる12人の人を意味します。スマートフォンを12台所有する必要はなく、高価なハードウェアや複数メーカーの端末を求めるGoogleのドキュメントもありません。自分自身が12人の1人になれるかどうかは、自分のアカウントをテスターとして使うで扱っています。
Androidスマートフォンを持っていません。それでも誰かのアプリのテストを手伝えますか？
手伝いたいという気持ちは欺瞞ではなく、開発者がテスター集団を作り出すのとは別の話です。ただし、ご自身の参加がどう数えられるかは、誰にも正直には約束できません。Androidデバイスを借りるのがリスクの低い方法です。代わりにエミュレータを使うなら、開発者がそれを踏まえて計画できるように伝えてください。
Google Playのクローズド テストにBlueStacksは使えますか？
BlueStacksはPlay ストアへのログインをドキュメント化しており、Play対応のAndroid Studioイメージもストアにアクセスできます。それが裏付けるのはPlay ストアにアクセスできるということであって、自分のクローズド テストのビルドが提供されるということではありません。それはアカウント、トラック、リリースに左右されます。対象可否についても何も決まりません。そのような参加者が数えられるかどうかを述べたGoogleのドキュメントがないからです。ベンダーのページは、その製品についての情報源としてのみ扱い、どちらの方向にもそれ以上の意味を読み取らないでください。
デベロッパーのデバイス確認はクローズド テストと同じものですか？
いいえ。デバイス確認は、アカウント所有者がアカウント設定時に、root化されていないAndroid 10以降の物理的なAndroidデバイスを使えることを証明するもので、Googleはあとで再度求めることもあります。クローズド テストは、人がテストトラックにオプトインすることに関するものです。行う人も、目的も、ヘルプページも異なります。
アプリをアンインストールしたら、そのテスターはテストから抜けたことになりますか？
アンインストールとオプトアウトは別の操作です。要件は継続的なオプトインの状態について書かれているので、アンインストールで期間が途切れるとか、1人が離脱すると他の人がリセットされるとは決めつけないでください。進捗がおかしく見えるなら、まず製品版へのアクセスのチェックリストと参加登録の状態を確認してください。
まとめ
要約
エミュレータは正当なテスト用ツールであり、参加者の代わりにはなりません。要件は12人のテスターが14日間連続でオプトインすることで、ここで確認したドキュメントには、エミュレータで参加したテスターが数えられるかどうかは明記されていません。ですから、製品版へのアクセスのチェックリストを開き、ハードウェアのせいにする前に設定の確認を順に進め、残りの期間は実際にアプリを使ってくれる人を集めることに使ってください。私たち自身の推奨は、ドキュメントに書かれているかどうかとは別に、はっきりしています。エミュレータや偽のアカウントで参加者を作り出すのは、却下のリスクに見合いません。テスター12人を見つける無料の方法から始める →
Googleの公式ドキュメント
コミュニティでの議論であり、ドキュメントではありません
そこでの推奨回答は、エミュレータではなく実機のAndroidデバイスを持つ他の人に頼むよう勧めており、プロダクト エキスパートがそれを支持していることは知っておく価値があります。それでもコミュニティでの議論にすぎません。ポリシーは引用されておらず、ページ自体が内容は未検証の可能性があると注意しています。