車の設定での注意散漫に関する最適化

Distraction Optimization（DO）は、車の移動中に設定アプリとドライバーのやり取りを軽減するツールとして提供されています。運転中に設定変更が必要な場合があるため、アプリを完全にブロックしているわけではありません。ただし、デフォルトでは、ほとんどの設定は無効になっており、キーと簡単に更新できる設定のみが有効になっています。

運転中に有効になっているアプリ

図 1. 運転中に有効になっているアプリ

以下に示すように、注意散漫に関して最適化されていない場合は、アクティビティ全体をブロックすることもできます。現在、この方法は設定の検索に使用されています。

すべてのアクティビティのブロック化

図 2. すべてのアクティビティのブロック化

DO のパフォーマンスの基本的なカスタマイズは、構成オーバーレイを介して行えます。さらに細かいカスタマイズが必要な場合は、コードから追加で変更を行うことができます。

高度なカスタマイズ

運転中に設定が無効になっている場合、設定をタップすると、設定コントローラが接続されている場合には、運転中に設定を使用できないことを示すトーストメッセージが表示されます。メッセージには、オーバーレイを使ってカスタマイズできる restricted_while_driving 文字列が使用されます（文字列が 60 文字の制限未満の場合）。

カスタマイズされたオーバーレイ

図 3. カスタマイズされたオーバーレイ

DO フレームワークは、config_always_ignore_ux_restrictions を使用してすべて無効にできます。これを true に設定すると、ドライバは設定アプリのあらゆる側面とやり取りできます。

<bool name="config_always_ignore_ux_restrictions">true</bool>

上記の設定が false の場合、設定アプリは config_ignore_ux_restrictions にフォールバックして、運転中にどの設定を有効にすべきかを判断します。ここで指定する文字列は、preference_keys.xml. で定義されている文字列を指す必要があります。

注: config_ignore_ux_restrictions に設定キーを配置すると、運転中はその設定のみが有効になります。ユーザーが実際に設定を操作できるようにするには、ナビゲーション階層のすべての設定が config_ignore_ux_restrictions にリストされていることを再確認してください。

例

深くネストされた設定を運転中に有効にする方法を示します。この例では、テキスト読み上げ（TTS）出力設定を有効にする方法を示します。これを行うには、階層のすべての設定を config_ignore_ux_restrictions に追加します。これは、設定ファイルにシステム、言語と入力、TTS 設定を含めます。階層が [システム] -> [言語と入力] -> [テキスト読み上げの設定] であるためです。ただし、テキスト読み上げフラグメント内の設定は引き続き無効になります。これらを有効にするには、アクセスを許可する設定のキーを追加する必要があります。この例では、再生設定を有効にしますが、エンジンの設定は有効にしません。そのため、pk_tts_playback_group を設定ファイルに追加します。

<string-array name="config_ignore_ux_restrictions">
    [...]
    <item>@string/pk_system_settings_entry</item>
    <item>@string/pk_languages_and_input_settings</item>
    <item>@string/pk_tts_settings_entry</item>
    <item>@string/pk_tts_playback_group</item>
</string-array>

詳細なカスタマイズ

運転状態に基づいて単に設定を有効/無効にするだけではなく、よりカスタマイズされた動作が必要になる場合があります。たとえば、Bluetooth と Wi-Fi は、運転中には保存された Bluetooth デバイスまたは Wi-Fi アクセスポイントを表示するようすでに変更されています。

現在、このような調整を行うための設定ベースのソリューションはありません。代わりに PreferenceController を拡張し、onApplyUxRestrictions() をオーバーライドして必要な変更を加えたカスタムクラスを作成できます。

注: onApplyUxRestrictions() は設定コントローラの UI 更新時、updateState() の後に呼び出されます。

カスタム設定コントローラが作成された後、関連する XML ファイルをオーバーレイして、デフォルトの設定コントローラを独自の実装に置き換えることができます。

例

CarSettings では、一部の設定にはさらにカスタマイズされた動作があり、追加のカスタマイズの例として使用できます。たとえば、Wi-Fi アクセスポイントリストでは、運転中には保存されたアクセスポイントのみを表示し、それ以外は非表示にするという動作が想定されています。これを行う手順は以下のとおりです。

mAccessPoints = CarUxRestrictionsHelper.isNoSetup(getUxRestrictions())
               ? getCarWifiManager().getSavedAccessPoints()
               : getCarWifiManager().getAllAccessPoints();

ここに表示されるアクセスポイントはすでに制限されているため、これらの設定に UxRestrictions を追加する必要はありません。そのため、onApplyUxRestrictions をオーバーライドして意図的に何も行わないようにします。

@Override
protected void onApplyUxRestrictions(CarUxRestrictions uxRestrictions) {
    // Since the list dynamically changes based on the ux restrictions, we
    // enable this fragment regardless of the restriction. Intentional no-op.
}

別の例を Bluetooth ボンディングデバイスから入手できます。 Bluetooth デバイスの接続と接続解除を今後も継続するために、このデバイスのその他の設定にアクセスする機能を無効にしたい場合、これを実現するには、再度 onApplyUxRestrictions をオーバーライドしますが、今回、NO_SETUP 制限が有効になっている場合は、設定のセカンダリアクションを非表示にします。

@Override
protected void onApplyUxRestrictions(CarUxRestrictions uxRestrictions) {
    super.onApplyUxRestrictions(uxRestrictions);
    if (CarUxRestrictionsHelper.isNoSetup(uxRestrictions)) {
        updateActionVisibility(getPreference(), /* isActionVisible= */ false);
    }
}