ログインを必須にしたアプリをGoogle Playへ提出すると、審査担当者はサインインできない限り主要機能に到達できません。
ユーザー名とパスワードを添えれば足りるように見えますが、Google Playは渡す認証情報そのものに条件を課しています。
条件を外したまま提出すると、審査が進まないまま否承認になることがあります。
「アプリのアクセス権」はアプリのコンテンツから登録する
審査用の認証情報は、ストア掲載情報やリリースノートではなく、専用の申告欄へ入れます。
審査のためにアプリを準備するでは、次の場所が案内されています。
- Play Consoleで「ポリシーとプログラム」を開く
- 「アプリのコンテンツ」ページへ移動する
- 「アプリのアクセス権」セクションの「開始」を選ぶ
- 「新しい手順の追加」から詳細を入力する
ログインやメンバーシップによってアプリ全体または一部の機能が制限される場合、アクセスを有効にするために必要な詳細情報をすべて提供する必要があります。
権限申告の公式ヘルプでは、ログインを要求するアプリについて「すべてまたは一部の機能が制限される」を選び、テスト用の有効なユーザー名や電話番号、パスワードに加えて、制限されたコンテンツへのアクセスに必要なその他の手順の説明を提供するよう求めています。
制限のかかる場所が複数あるなら、一つの欄へまとめず、機能ごとに手順を分けて登録します。
どの手順がどの機能に対応するかが残るため、次のリリースで直す箇所を特定しやすくなります。
認証情報が満たす条件は文書で決まっている
ログイン認証情報の提供に関する要件には、渡すアカウントが満たすべき状態が並んでいます。
- 常にアクセスが可能である
- 再利用できる
- ユーザーの位置情報にかかわらず有効である
- 常にエラーのない状態で利用できる
- 英語で提供されている
- テスト専用であり、実際に使用するユーザーの認証情報ではない
英語という条件は見落としやすい箇所です。
日本語で説明を書いた場合は、英語版を別途用意して同じ欄に添えてください。
期限の扱いも明記されています。
提供したパスワードが期限切れの場合、アプリを審査できず、否承認になる可能性があると書かれています。
審査の開始日を見込んで短い有効期限を設定するのではなく、失効しない審査専用アカウントを用意するほうが確実です。
実際に使用するユーザーの認証情報を渡すことは要件で否定されています。
問い合わせ対応で預かった利用者のアカウントや、開発者本人が普段使っているアカウントを審査用に転用しないでください。
二段階認証は回避できる経路を先に決める
届いたコードを開発者が都度転送する運用は、審査では成立しません。
審査は開発者の稼働時間と無関係に進み、ワンタイムコードには有効期限があります。
要件では、二段階認証やワンタイム認証が通常必要な場合について、これらの要件を回避できる再利用可能なログイン認証情報を提供するよう求めています。
実現方法はアプリの構成によって変わるため、次の選択肢を自分の実装に当てて確認してください。
- 審査用アカウントだけ追加認証を免除するフラグを持たせる
- 審査用アカウントに固定の検証コードを割り当てる
- 追加認証を通過済みの状態が維持されるテスト経路を用意する
いずれも採用できない場合は、審査側だけで完結しない手順をそのまま提出せず、先に成立する経路を用意してください。
QRコードや独自PINには決められた渡し方がある
認証情報が文字列でないアプリには、別の指示があります。
| アプリ側の作り | 要件で示されている渡し方 |
|---|---|
| QRコードやバーコードでログインする | 静的URLを生成してGoogle Play Consoleにアップロードする |
| アプリ内の独自パスワードやPINが必要 | 明確な手順を提供する |
| 外部サービスのアカウント連携が必要 | すべてのアカウント情報と詳しい手順を分かりやすく提供する |
コードの画像を説明文へ貼り付けるのではなく、静的URLとしてアップロードする点が指定されています。
毎回生成し直すコードや、期限付きで無効になるURLは、再利用できるという条件を満たしません。
「その他の手順」は到達手順として書く
「その他の手順」欄には、ワンタイムパスワードや多要素認証などの特記事項を記載します。
審査担当者はアプリ固有の前提を知らないため、画面名と操作、そこで何が表示されれば成功かまで書きます。
英語で提出する必要があるので、次の構成で組み立てると項目の抜けに気づきやすくなります。
Test account
User name: [test user name]
Password: [test password]
Region: works from any location
How to reach [restricted feature]
1. Open the app and sign in with the account above.
2. Open [menu or tab name].
3. Select [sample item name].
Expected: [what the reviewer should see].
Notes
- Two-factor authentication is turned off for this test account.
- Sample data stays available and is not deleted automatically.
「ログインして確認してください」だけでは、制限された機能の入口が伝わりません。
アプリ内の実際の表示名と、手順に書いた名称をそろえてください。
iOS版も同時に提出する場合、入力欄の構成と求められる情報がApple側では異なります。違いはApp Store審査用デモアカウントの準備で確認できます。
権限申告フォームは別に求められることがある
危険性が高い権限や機密情報にかかわる権限をリクエストするアプリでは、アプリのコンテンツページに権限申告フォームが表示されます。
ここではサポートされているユースケースのリストからコア機能を指定し、実証に手順が必要ならその内容を記入します。
YouTubeリンクまたはmp4形式の動画でデモを提供することもできます。
このリクエストの審査手続きには数週間かかることもあると案内されています。
公開予定日から逆算し、権限を追加するリリースでは申告を先に済ませてください。
否承認になっても連絡なしで戻せる
情報が足りずアップデートが否承認になったり、アプリが削除されたりした場合でも、ポリシーサポートチームへ連絡する手順は挟みません。
公式ヘルプでは、アプリのアクセス権ページで情報を更新して保存し、公開の概要ページから審査に送信し直す流れが案内されています。
送信し直す前に、次を確かめてください。
- 登録したアカウントで実際にサインインできる
- 追加認証やメール確認を求められない
- 制限された機能まで手順どおり到達できる
- 手順の英語版がある
- サンプルデータが残っている
作成した本人の端末では、保存済みのセッションや設定が残っているため確認になりません。
提出するビルドを入れ直し、登録した手順だけを見て通してください。
審査で書いた手順は公開後にも使う
審査向けに言語化した「どの画面で何をすると、どこで止まるか」は、公開後の問い合わせでも同じ形で必要になります。
「サインインできない」「コードが届かない」という連絡は、原因がアカウント状態にあるのか、端末や通信にあるのかで返信内容が変わります。
IndieFormでは、ログイン周りの条件と手順をプロダクトのナレッジへ登録しておくと、届いた問い合わせの返信案がその内容を根拠に作られます。
登録するのは条件と手順だけです。審査用のユーザー名やパスワードは含めないでください。一般ユーザーからの問い合わせに答えるうえで、審査専用の認証情報が必要になる場面はありません。
問い合わせと一緒にアプリのバージョンやOSを受け取れるため、サインインできないという報告でも、どのビルドで起きているかを聞き直さずに確認できます。
提出前に見直す項目
- アプリのアクセス権を申告した
- テスト専用アカウントを使っている
- アカウントに有効期限がない
- 地域を問わずサインインできる
- 追加認証を回避できる経路がある
- QRコードは静的URLとしてアップロードした
- 手順と補足を英語で書いた
- 権限申告が必要なリリースでは別途提出した
認証情報を入れる欄は小さくても、審査が進むかどうかはここで決まります。
アカウントを用意したら、事情を知らない人が手順だけを読んで最後まで通せるか、提出前に一度試してください。