Google Play でのマルチデバイス品質の向上とモバイル以外のデバイスへの公開

皆様、ようこそ。

本日は、マルチデバイス アプリの品質管理と、モバイル以外のフォーム ファクタ向けに Google Play で公開する方法に関するセッションにご参加いただき、誠にありがとうございました。

自動車向け Android チームのデベロッパー リレーションズ エンジニア、Jan Kleinert です。

Google Play Trust and Safety チームのオペレーション リード、Faustine Liao です。

本日はご参加いただき、ありがとうございます。

長年にわたり、Android 開発といえば、ほとんどの人がモバイル デバイスを思い浮かべていましたが、Android エコシステムはスマートフォンをはるかに超えて拡大しています。

現在、ユーザーは Android TV を使ってリビングルームで、Android Auto や Automotive OS を使ってカープール レーンや車の充電中に、Wear OS を使って手首で、そして Android XR を使って没入型の 3D 空間でアプリを操作しています。

これは成長の大きなチャンスですが、これらのフォーム ファクタに拡大するということは、パブリッシング戦略で考慮すべき点がいくつかあるということです。

アプリのビルドから Google Play での公開までの全体的なプロセスは、モバイル リリースの場合とほぼ同じです。

アプリをビルドして準備し、Google Play Console で掲載情報を作成して、アプリをテストし、製品版リリースをアップロードして送信し、審査と承認を待ちます。

ただし、モバイル以外のフォーム ファクタ向けにアプリを公開する場合は、いくつか固有の考慮事項があります。

本日は、マルチデバイスのリリース プロセスをよりスムーズかつ予測可能にするための明確なフレームワークをご紹介します。

まずは、アプリの設計とパッケージ化の方法という基本から始めましょう。

そのため、Google Play Console を操作する前に、アーキテクチャに関する重要な決定を行う必要があります。

サポートするすべてのフォーム ファクタ向けのすべてを含む、単一の統合された App Bundle をビルドしますか？それとも、アプリをフォーム ファクタ固有のモジュールに分割し、それぞれに Android App Bundle（AAB）を生成しますか？

モジュールやモジュール化とは、保守性を向上させるようにコードベースを構造化する手法のことです。

モジュール化にはさまざまなアプローチがありますが、一般的には、コードベースを疎結合の自己完結型の部分に編成し、各部分をモジュールにします。

そのため、統合された Android App Bundle アプローチの方が管理が簡単そうに思えますが、実際にはモジュラー アプローチをおすすめします。

このモジュラー アプローチをおすすめする理由を示す例を次に示します。

たとえば、モバイルと Android TV の両方をサポートするアプリがあるとします。

標準のモバイル向けリリース トラックで 1 つの Android App Bundle を送信し、Android TV アプリが審査チェックに不合格となった場合、リリース全体が停止します。

そのため、Android TV アプリとモバイルアプリの両方のリリースに影響します。

モバイルアプリ自体に問題がなかったとしても、Android TV の審査で不合格となった原因を解決し、アプリを再審査に提出していただく必要があります。

一方、フォーム ファクタごとにモジュール式の Android App Bundle を使用すると、より細かく管理できるようになり、フォーム ファクタのリリースをモバイルのリリースから分離できます。

代わりに、モバイルアプリと TV アプリに別々のアプリ モジュールがある場合は、それぞれに別々の Android App Bundle を生成できます。

TV アプリの審査で問題が見つかった場合は、そのアプリのリリースのみがブロックされ、問題が解決されるまで公開されません。

モバイルアプリのリリースは、予定どおり公開されます。

先ほど述べたように、モジュール化にはさまざまなアプローチがあります。

ここでは、モバイル エクスペリエンスと Android Automotive OS エクスペリエンスを備えたオーディオブック アプリをモジュール化するアプローチの例を 1 つ紹介します。

上部の緑色の部分は、各フォーム ファクタのアプリ モジュールです。これにより、プラットフォーム固有の依存関係を分離できます。

黄色は機能モジュールで、アプリの機能の独立した部分に対応しています。

データ モジュールは青色で、下部にはコア モジュール（共通モジュール）があります。これは通常、他のモジュールが頻繁に使用するコードを格納するために使用されます。

そして、プロジェクトの Gradle 設定ファイルに、この種のモジュール化をサポートするマルチモジュール Gradle 構成を組み込んで設定します。

...

rootProject.name = "MultiFormFactorApp"

// Define modules for each form factor
include(":app:automotive")
include(":app:mobile")
include(":core:network")
include(":data:books")
include(":data:reviews")
include(":feature:home")
include(":feature:player")
include(":feature:reviews")

そのため、各アプリ モジュールとバンドルで同じパッケージ名またはアプリケーション ID を引き続き使用します。

このモジュラー アプローチは、Google Play Console のトラック戦略に直接結びついています。

公開時には、標準のモバイルトラックを使用できますが、専用のフォーム ファクタ トラックも用意されています。

Android TV、Android XR、Android Automotive OS の場合は、選択肢があります。

モバイル向けと同時に公開することも、専用のフォーム ファクタ トラックを使用することもできます。

ただし、次の 2 つの例外があります。

Wear OS の場合は、専用の Wear OS トラックを使用する必要があります。

Android Auto の場合、基本的にはモバイルアプリを車載画面に投影する拡張機能であるため、標準のモバイルトラックしか選択できません。

複数のトラックを管理している場合、バージョニングは非常に重要です。

1 つの方法は、バージョン コードの最初の数桁をフォーム ファクタに割り当てることです。

たとえば、モバイルの場合は 01、Wear OS の場合は 02、Android Automotive OS の場合は 03 などです。

通常は、バージョン コードを 7 桁以上にして、残りの桁をアプリのバージョンに使用できるようにすることをおすすめします。

これにより、Google Play Console でのバージョン コードの競合を防ぐことができます。

アプリをパッケージ化したら、テストを行います。

フォーム ファクタの開発には徹底的なテストが必要です。Google Play では、製品版をリリースする前に、内部テスト、クローズド テスト、オープンテストの 3 つの異なるチャネルでテストを行うことができます。

専用のフォーム ファクタ トラックを使用している場合は、これらのテストトラックをフォーム ファクタと組み合わせることで、プロセスをさらに細かく制御できます。

たとえば、標準トラックでモバイルアプリのクローズド テスト リリースを作成し、専用の Android TV フォーム ファクタ トラックで Android TV アプリのクローズド テスト リリースを別途作成して、それぞれに異なるテスターを設定できます。

そのため、内部テストは優れた出発点となります。

最大 100 人のテスターにアプリを迅速に配信できます。重要なのは、Google Play の審査がトリガーされないことです。

つまり、開発者とテスターはアプリをデバイスにすばやくインストールし、エミュレータや実際のテレビ、スマートウォッチ、その他のデバイスでエクスペリエンスを検証できます。

内部テストでは、テスターと共有できる固有の URL が生成されます。

内部テストの結果に問題がなければ、クローズド テストとオープンテストに進むことができます。

クローズド テスト版リリースを使用すると、内部テストよりも幅広い対象のテスターを対象にアプリのプレリリース バージョンをテストしつつ、的を絞ったフィードバックを収集することができます。

クローズド テストのグループは、メールアドレスのリストまたは Google グループで管理できます。

一方、オープンテストでは、Google Play でより大規模なグループを対象にテストを実施できます。

アプリは Google Play に表示され、誰でもオープンテスト プログラムに参加できます。

招待は不要で、アプリに関するフィードバックや非公開のフィードバックをデベロッパーと共有できます。

これらのオープンテスト トラックとクローズド テスト トラックでは、審査がトリガーされます。

これは実際には大きなメリットです。

これにより、審査プロセス自体をテストし、待望のリリース日のかなり前に障害をクリアできます。

審査プロセスについて、その内容と重要性を少し説明しましょう。

これらのポリシーとガイドラインの核心は、アプリの品質にあります。

ユーザーに価値を提供する、楽しみながら使用できる、プレミアムなデバイスを最大限有効に活用する、安全性を重視して設計されているアプリやゲームは、高品質であるとみなされます。

そこで、アプリが審査にできるだけ簡単に合格できるように準備する方法を見ていきましょう。

まずは、優れたユーザー エクスペリエンスとはどのようなものかに焦点を当てた、アプリの品質に関するガイドラインを確認することをおすすめします。

Google は、すべてのアプリに適用されるコアアプリの品質に関するガイドラインを公開しています。このガイドラインでは、すべてのアプリが満たすべき最低限の品質を定義しています。また、アダプティブ アプリの品質に関するガイドラインも公開しています。これらのガイドラインは、デバイスのフォーム ファクタ、画面サイズ、表示モードに関係なく、アプリが優れたエクスペリエンスを提供できるようにするのに役立ちます。

この 2 つのガイドラインを組み合わせることで、非常に良いスタートを切ることができます。

また、フォーム ファクタごとに、フォーム ファクタ固有のアプリ品質に関するガイドラインも用意されています。

Google の審査担当者は、これらのガイドラインに照らして、実際のデバイスとエミュレータでアプリをテストします。

そのため、アプリがポリシーに準拠していることを確認することが非常に重要です。

そこで、アプリが各フォーム ファクタで不承認となる最も一般的な理由を簡単に見ていきましょう。

ただし、これらはアプリの品質に関するガイドラインのすべてを網羅しているわけではありません。

より堅牢な基準セットについては、各フォーム ファクタの品質に関するガイドラインを詳しく確認してください。

まずは Android TV から始めましょう。

そのため、これらのセクション スライドの下部には、そのフォーム ファクタのアプリ品質に関するガイドラインの完全なリストに移動する短いリンクが表示されます。

Android TV アプリが不承認となる一般的な理由の一つは、アプリがサポートする各言語のホーム画面バナー画像がないことです。

そのため、アプリを識別するローカライズされたテキストを含む 320×180 ピクセルの画像を提供する必要があります。

このスライドの画像は、これらの条件を満たしているホーム画面バナーの例を示しています。

2 つ目は、ほとんどのテレビで、ユーザーは D-pad リモコンを使用してデバイスを操作することです。

そのため、D-pad のナビゲーションとフォーカスを適切にサポートすることが非常に重要です。

これらの基準に基づいて不承認にならないように、少なくとも最小限の D-pad コントロールをサポートしていることを確認してください。

Android TV アプリが不承認となる 3 つ目の一般的な理由は、Android マニフェスト ファイルに CATEGORY_LEANBACK_LAUNCHER インテント フィルタがない場合です。

<application ...>
...
<activity
    android:name="com.example.TvActivity"
    android:label="@string/app_name"
    android:theme="@style/Theme.Leanback">
    <intent-filter>
      <action android:name=
           "android.intent.action.MAIN" />
      <category android:name=
           "Android.intent.category.
            LEANBACK_LAUNCHER" />
    </intent-filter>
  </activity>
</application>

このフィルタにより、アプリが TV 対応として識別され、Google Play でも TV アプリとしてユーザーに識別されるようになります。

ユーザーがテレビのホーム画面でアプリを選択すると、このインテントによって起動するアクティビティが識別されます。

マニフェストにこの権限が含まれていることを確認してください。

次は Android XR です。

Android XR を搭載した XR ヘッドセットや XR グラス向けに開発する場合は、アプリのパフォーマンス、レンダリング、安定性に特に注意してください。

Perfetto を使用して、Jetpack XR SDK でビルドされたアプリのパフォーマンスをプロファイリングし、最小フレームレートの要件を遵守していることを確認できます。

Unity などのリアルタイム エンジンを使用してビルドする場合は、エンジンに組み込まれているプロファイリング ツールを使用して、レンダリング要件に準拠していることを確認できます。

次に、Android Auto と Android Automotive OS の両方で構成される自動車です。

Android Auto と Android Automotive OS には、この特定のフォーム ファクタに固有のカテゴリという概念があります。

また、自動車向けに公開できるアプリのカテゴリは限られています。

そのため、サポート対象外のカテゴリにアプリを送信した場合や、ベータ版のみのカテゴリでオープンテスト版または製品版にアプリを送信した場合は、不承認となります。

具体的に説明しましょう。

この表は、各プラットフォームで自動車向けにサポートされているアプリのカテゴリと、その提供状況の概要を示しています。

ベータ版、一般提供、または未サポート（「近日公開」と表示）のいずれかです。

ナビゲーションやスポットアプリなどの一部のカテゴリは一般提供されているため、誰でもこれらのカテゴリのアプリを自動車向けに製品版として公開できます。

ただし、Android Auto 向けのコミュニケーション通話アプリなど、他のカテゴリはベータ版です。

そのため、これらのカテゴリでは、内部テスト トラックまたはクローズド テスト トラックに公開することはできますが、そのカテゴリの早期アクセス プログラムのいずれかに承認されていない限り、製品版に公開することはできません。

詳細については、自動車向け Android のデベロッパー ガイドをご覧ください。

このページには、早期アクセス プログラムに登録するためのリンクが掲載されています。

Android Automotive OS のスクリーンショットの仕様が不足しているか、正しくないことも、アプリが不承認となる一般的な理由です。

Android Automotive OS のスクリーンショットを提供する場合は、縦向きのスクリーンショットを 2 枚以上、横向きのスクリーンショットを 2 枚以上、ここに記載されているサイズで用意する必要があります。

これらのスクリーンショットを撮影するには、Android Automotive OS エミュレータを使用します。

このツールは、必要なサイズのスクリーンショットを正確にキャプチャできるように設定されています。

最後に、自動車向けアプリでは安全性が最優先されます。

そのため、アプリがドライバーの注意散漫に関するガイドラインに準拠していない場合、不承認となります。

たとえば、動画アプリは再生を一時停止する必要があり、車両の走行中は表示できません。

最後に、Wear OS があります。

そのため、Wear OS アプリは、小型の円形ディスプレイ向けに最適化およびフォーマットされていない場合、不承認となる可能性があります。

そこで、Compose for Wear OS の最新の安定版を使用して、さまざまなサイズのデバイスでコンテンツが端で切れないようにすることや、スクロール可能なコンテンツがある場合にスクロールバーが表示されるようにすることをおすすめします。

@Composable
fun MyText() {
  Text(
    text = stringResource(R.string.compose_for_wear_os),
    modifier = Modifier.fillMaxWidth(),
    textAlign = TextAlign.Center,
    style = MaterialTheme.typography.titleLarge
  )
}

Android Automotive OS の場合と同様に、Wear OS アプリも、Wear OS のスクリーンショットが不足しているか不正確であるために不承認となることがあります。

これは、Androidify サンプルアプリの Google Play ストアの掲載情報からのスクリーンショットの好例です。これは要件を満たしています。

Wear OS デバイスでアプリが動作していることを示すスクリーンショットを 1 枚以上送信してください。

重要なポイント

特定のフォーム ファクタに関するアプリの品質に関するガイドラインを読み、送信前にガイドラインに沿ってテストします。

また、重要なヒントもいくつかご紹介します。

アプリでログインが必要な場合は、Google Play Console の [アプリのアクセス権] セクションで、有効なデモアカウントと有効な認証情報を提供する必要があります。

審査担当者がログインできない場合、アプリをテストできないため、自動的に否承認となります。

また、約束した内容を確実に提供してください。

モバイルのスクリーンショットだけを使用しないでください。

アプリが Wear OS と Android TV で利用可能な場合は、Google Play Console で、それらのフォーム ファクタ向けの高画質のスクリーンショットをアップロードしてください。

最後に、説明を詳しく記述します。

アプリの特長、価値、アプリを各タイプのデバイスにインストールした場合に期待できることをわかりやすく説明してください。

まとめると、ユーザーがどこにいてもリーチできることは、素晴らしい機会です。モジュール式で設計し、内部テストを活用して迅速に反復処理を行い、フォーム ファクタの品質に関するガイドラインに沿って設計し、ストアの掲載情報を最適化することで、アプリのリリースと審査のプロセスをよりスムーズに進めることができます。

本日はお時間をいただきありがとうございました。

皆様が Google Play で提供する素晴らしいマルチデバイス エクスペリエンスを拝見できることを楽しみにしております。