Android Automotive OS デバイスにアプリを配信する場合は、フォーム ファクタに固有の考慮事項に注意する必要があります。このガイドでは、これらの考慮事項について説明します。
Android Automotive OS エミュレータで既存のアプリをテストする
Android Automotive OS 用のアプリを作成するには、まず Android Automotive OS エミュレータで既存のアプリをテストします。エミュレータをセットアップするには、Android Automotive OS エミュレータを使用してテストするの手順に沿って行ってください。その後、エミュレータでアプリを実行するの手順に沿ってアプリを実行します。
アプリを実行するときは、次のような互換性の問題に注意します。
- インフォテインメント画面は向きが固定されています。自動車向けアプリの品質に関するガイドラインに沿って、アプリは縦向きと横向きの両方をサポートする必要があります。
- 他のデバイスで利用可能な API が Android Automotive OS では利用できない場合があります。たとえば、一部の Google Play 開発者サービス API は Android Automotive OS では利用できません。こうした問題に対処する方法について詳しくは、機能を無効にするセクションをご覧ください。
アプリのマニフェスト ファイルを構成する
Android Automotive OS デバイスをターゲットにするには、アプリに特定のマニフェスト エントリが必要です。Android Automotive OS デバイスへの配信を有効にすると、互換性のあるアプリは、車で安全に使用できることを確認するために手動による審査を受けます。詳細については、車に配信するをご覧ください。
必須の Android Automotive OS の機能
Android Automotive OS 用にビルドされたすべてのアプリは、Google Play を使用して配信されるために特定の要件を満たす必要があります。詳しくは、Google Play の機能要件を満たすをご覧ください。
カテゴリ固有のマニフェスト エントリ
駐車中のすべてのアプリに適用される上記の要件に加え、動画カテゴリとゲームカテゴリには追加の要件があります。
- 動画アプリの場合は、アプリを動画アプリとしてマークするをご覧ください。
- ゲームの場合は、アプリをゲームとしてマークするをご覧ください。
ドライバーの注意散漫に関する要件を満たす
アプリを自動車に導入する場合は、運転中の注意散漫を回避することが重要です。パークされたアプリの場合、これは主に、ユーザー エクスペリエンス（UX）の制限が有効になっている間、アプリの使用や音声の再生を防止することで実現されます。これは、DD-2 と DD-3 の品質ガイドラインで定められています。
ユーザー エクスペリエンスの制限が有効な間は使用できないようにする
デフォルトでは、UX の制限が有効になっている間は、アクティビティを使用または起動できません。この動作をアプリに適用するには、マニフェスト内の <activity> 要素に次の <meta-data> 要素を含めないでください。
<!-- NOT ALLOWED -->
<meta-data
android:name="distractionOptimized"
android:value="true"/>
UX 制限が有効になったときにアプリ内のアクティビティが再開されている場合、そのアクティビティは OS が所有するアクティビティによって隠されます。
少なくとも、アプリのアクティビティは 一時停止ライフサイクル状態に遷移します。これは onPause() ライフサイクル コールバックとして発生し、その間はアプリでの動画と音声の再生をともに一時停止する必要があります。
Android Automotive OS 互換モードが搭載されているデバイスでは、システムのブロックにより、アプリのアクティビティが一時停止状態から停止状態に移行します。
再生を停止し、再生の再開を防止する
一部のアプリでは、onPause() 中に再生を一時停止し、onResume() になるまで再生を再開できないように状態をトラッキングすることで、ドライバーの注意散漫に関する要件を満たすことができます。
ライフサイクル コールバックへの対応がアプリに不十分な場合は、次のセクションで説明するように、UX 制限状態を直接リッスンできます。たとえば、ピクチャー イン ピクチャーをサポートするアプリでは、ライフサイクル コールバックで条件チェックを行うのではなく、直接リッスンすることをおすすめします。
ユーザー エクスペリエンス制限を聴く
UX の制限をリッスンするには、まずアプリ モジュールの build.gradle ファイルに android.car ライブラリへの依存関係を追加します。これは、Android Automotive OS に固有の API を提供する Android SDK の拡張機能です。
android {
...
useLibrary("android.car")
}
CarUxRestrictionsManager を使用して UX 制限の状態を読み取ります。UX 制限は車両内のディスプレイによって異なる可能性があるため、ギアや速度などの他のハードウェアの状態から UX 制限の状態を判断しようとしないでください。
val car = Car.createCar(context)
val carUxRestrictionsManager =
car.getCarManager(Car.CAR_UX_RESTRICTION_SERVICE) as CarUxRestrictionsManager
// You can either read the state directly ...
val currentUxRestrictions = carUxRestrictionsManager.currentUxRestrictions
// or listen to state changes
carUxRestrictionsManager.registerListener { carUxRestrictions: CarUxRestrictions -> ...}
// Don't forget to teardown and release resources when they're no longer needed
carUxRestrictionsManager.unregisterListener()
car.disconnect()
アプリが参照する必要がある CarUxRestrictions から提供される値は、isRequiresDistractionOptimization() の戻り値のみです。他の値は、注意散漫防止の最適化済みとしてマークされているアクティビティにのみ関連します。
実装をテストする
次の手順に沿って、アプリが運転中の注意散漫に関する要件を満たしていることを確認します。
- Google Play ストアまたは互換モードのないシステム イメージにアプリをインストールします。
- ランチャー アプリのグリッドを開き、運転をシミュレートして、アプリを開けないことを確認します。
- 運転の模擬を停止し、アプリを開いて再生画面に移動して再生を開始します。
- 運転を再びシミュレートし、再生が一時停止することを確認します。
- アプリが
MediaSessionとの統合をサポートしている場合は、adb shell cmd media_session dispatch playを使用して、再生が再開されないことを確認します。
- アプリが
Android Automotive OS 用のアプリを最適化する
自動車で優れたユーザー エクスペリエンスを提供するために、Android Automotive OS 用のアプリをビルドする際は、次の点に注意してください。
ウィンドウ インセットとディスプレイ カットアウトを使用する
他のフォーム ファクタと同様に、Android Automotive OS には、ステータスバーやナビゲーション バーなどのシステム UI 要素が含まれており、非矩形ディスプレイをサポートしています。
デフォルトでは、アプリはシステムバーやディスプレイ カットアウトと重ならない領域に描画を行います。ただし、ウィンドウ インセット内でアプリを配置するで説明されているように、アプリでシステムバーを非表示にしたり、システムバーの背後にコンテンツを描画したり、ディスプレイ カットアウトにコンテンツを表示したりすることもできます。アプリが上記のいずれかを行う場合は、Android Automotive OS デバイスのエコシステム全体でアプリを適切に動作させる方法の詳細について、以降のサブセクションをご覧ください。
システムバー、没入モード、エッジ ツー エッジのレンダリング
自動車のシステムバーは、サイズと配置が他のフォーム ファクタとは異なる場合があります。たとえば、ナビゲーション バーを画面の左側、右側、下部に配置できます。ほとんどのスマートフォンやタブレットのように、上部にステータスバー、下部にナビゲーション バーがある場合でも、自動車ではこれらの要素のサイズがはるかに大きくなる可能性があります。
また、Android Automotive OS では、アプリが没入モードの開始と終了に合わせてシステムバーの表示と非表示を切り替えられるかどうかを OEM が制御できます。たとえば、OEM は、アプリがシステムバーを非表示にできないようにして、空調などの車両制御に常に画面からアクセスできるようにすることができます。アプリによるシステムバーの制御を OEM が禁止している場合、アプリがWindowInsetsController（またはWindowInsetsControllerCompat） API を呼び出しても何も起こりません。アプリがインセットを変更できたかどうかを検出する方法については、show と hide のドキュメントをご覧ください。
同様に OEM は、システムバーの色と透明度をアプリが設定できるかどうかを制御して、システムバーとそこに含まれる要素が常に明確に表示されるようにすることもできます。アプリがエッジ ツー エッジで描画する場合は、重要でないコンテンツのみがシステムバーの背後に描画されるようにします。デバイスの OEM がシステムバーの色や透明度の設定を許可しない場合、このコンテンツは表示されないことがあります。
<!-- Depending on OEM configuration, these style declarations
(and the corresponding runtime calls) may be ignored -->
<style name="...">
<item name="android:statusBarColor">...</item>
<item name="android:navigationBarColor">...</item>
<item name="android:windowTranslucentStatus">...</item>
<item name="android:windowTranslucentNavigation">...</status>
</style>
アプリをエッジ ツー エッジで表示する場合は、システムバーのサイズ、数、タイプ、位置について想定しないでください。代わりに、ウィンドウ インセットの API を使用して、システムバーを基準として相対的にアプリのコンテンツを配置します。これらの API の使用方法について詳しくは、アプリ内でコンテンツをエッジ ツー エッジで表示するをご覧ください。パディング値のハードコードはどのフォーム ファクタでも推奨されませんが、自動車ではコンテンツをセーフエリアに保持するために機能しない可能性があります。
不規則な形状のディスプレイに適応する
ディスプレイは長方形のものだけでなく、車両によっては図 1 に示すように不規則な形状の画面もあります。
アプリがエッジ ツー エッジでレンダリングしない場合、セーフエリア内でレンダリングするために何かをする必要はありません。
アプリがエッジ ツー エッジでレンダリングする場合は、ディスプレイ カットアウトに関する動作を選択できます。リソースを使用してこれを実現するには、アプリのテーマに android:windowLayoutInDisplayCutoutMode 属性を設定するか、実行時にウィンドウの layoutInDisplayCutoutMode 属性を変更します。
Android Automotive OS デバイスでのディスプレイ カットアウトの種類はモバイル デバイスのものとは異なるため、LAYOUT_IN_DISPLAY_CUTOUT_MODE_DEFAULT または LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES は使用しないでください。これらはモバイル デバイスのカットアウトに合わせて動作が最適化されています。代わりに、LAYOUT_IN_DISPLAY_CUTOUT_MODE_NEVER または LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS を使用して、常にカットアウトを回避するか、常にカットアウトに入るようにします。後者を選択する場合は、ディスプレイ カットアウトをサポートするで、ディスプレイ カットアウトに関連する API の詳細をご覧ください。
ディスプレイ カットアウト領域にレンダリングするアプリで、この動作を Android Automotive OS とモバイルで異なるものにする場合、実行時にアプリでこの動作を設定するなら機能を無効にするを、アプリがリソース ファイルを使用してこの動作を設定するなら代替リソースを使用するをご覧ください。
機能を無効にする
既存のモバイルアプリを Android Automotive OS で利用できるようにしている場合、一部の機能は関連性を持たないか、使用できない場合があります。たとえば一般的に、車ではカメラへのアクセスを提供していません。また、Android Automotive OS では Google Play 開発者サービスのサブセットのみを使用できます。詳しくは、自動車用の Google Play 開発者サービスをご覧ください。
PackageManager.hasSystemFeature API を使用すると、次の例で示すとおり、FEATURE_AUTOMOTIVE 機能を確認することで、アプリが Android Automotive OS で実行されているかどうかを検出できます。
Kotlin
val packageManager: PackageManager = ... // Get a PackageManager from a Context val isCar = packageManager.hasSystemFeature(PackageManager.FEATURE_AUTOMOTIVE) if (isCar) { // Enable or disable a given feature }
Java
PackageManager packageManager = ... // Get a PackageManager from a Context boolean isCar = packageManager.hasSystemFeature(PackageManager.FEATURE_AUTOMOTIVE) if (isCar) { // Enable or disable a given feature }
または、アプリに Android Auto コンポーネントも含まれる場合には、自動車向け Android アプリ ライブラリの CarConnection API を使用して、アプリが Android Automotive OS または Android Auto で実行されているか、車にまったく接続されていないかを検出できます。
ピクチャー イン ピクチャー（PIP）については、実績のあるベスト プラクティスに沿って、この機能が利用可能かどうかを確認し、適切に対応します。
オフラインのシナリオに対応する
インターネットに接続されている車が増えていますが、次に示すように、アプリはインターネット接続がない状態で実行することをおすすめします。
- ユーザーは、自動車メーカーが定期購入パッケージの一部として提供しているモバイルデータをオプトアウトする場合があります。
- 一部の地域ではモバイルデータへのアクセスが制限される場合があります。
- Wi-Fi 無線通信のある自動車でも、Wi-Fi の通信範囲外にある場合や、OEM がモバイル ネットワークを優先して Wi-Fi をオフにしている場合があります。
アプリがこのようなシナリオに対応できるように、オフライン コンテンツを提供するなどして、インターネット アクセスに依存する機能のグレースフル デグラデーションを行ってください。詳しくは、ネットワークを最適化するためのおすすめの方法をご覧ください。
代替リソースを使用する
Android Automotive OS 車両で動作させる場合、アプリを自動車に適応させるために、car リソース修飾子を使用して代替リソースを指定できます。たとえば、ディメンション リソースを使用してパディング値を格納する場合は、より大きな値を car リソースセットに指定して、タップ ターゲットを大きくすることができます。