このページは Cloud Translation API によって翻訳されました。

マルチリフレッシュレート

Android 11 では、複数のリフレッシュレートを持つデバイスのサポートが追加されています。この機能には 3 つの主要なコンポーネントがあります。

新しい HAL API がandroid.hardware.graphics.composer@2.4で導入されました。
さまざまなリフレッシュレートのデバイス構成を解析し、必要なリフレッシュレートを設定するプラットフォームコード
アプリが希望のフレームレートを設定できるようにする新しい SDK および NDK API

実装

リフレッシュレート切り替えの専用サポートがandroid.hardware.graphics.composer@2.4 HALに追加されました。 Composer HAL の以前のバージョンではリフレッシュレート切り替えのサポートが制限されているため、このバージョンを使用することを強くお勧めします。

構成グループ

getDisplayAttribute_2_4 API を使用してクエリできる新しい属性CONFIG_GROUPがIComposerClient::Attributeに追加されました。この属性により、ベンダーはディスプレイ構成をグループ化できます。同じグループ内の構成では、ほとんどの場合、それらの間でシームレスに切り替えることができます。構成グループは、構成の他の属性ではなくリフレッシュレートを切り替えるために、プラットフォーム間でどの構成を切り替えることができるかを区別するためにプラットフォームによって使用されます。

4 つのディスプレイ構成をサポートするデバイスで構成グループを使用する利点を示す次の例を考えてみましょう。

1080p@60Hz
1080p@90Hz
1080i@72Hz
1080i@48Hz

デバイスは 48Hz、60Hz、72Hz、90Hz のリフレッシュレートをサポートしていますが、ディスプレイは別のモードで動作し、60Hz から 72Hz に切り替えるとディスプレイ構成が 1080p から 1080i に変更され、これは望ましい動作ではない可能性があります。これは、構成グループを使用することで解決されます。 60Hz と 90Hz を 1 つの構成グループにグループ化し、48Hz と 72Hz を別の構成グループにグループ化します。プラットフォームは、60Hz と 90Hz の間、および 48Hz と 72Hz の間は切り替えられるが、60Hz と 72Hz の間は切り替えられないことを認識しています。これは、単にリフレッシュレートを変更するのではなく、構成が変更されることになるためです。

Composer API の更新

getDisplayVsyncPeriod

リフレッシュレート変更時の制御と予測性を向上させるために、 getDisplayVsyncPeriodが追加されました。 getDisplayVsyncPeriodディスプレイが動作する現在のリフレッシュレート (vsync 期間に関して) を返します。これは、リフレッシュレートと現在のリフレッシュレートの間で移行するときに、プラットフォームが次のフレームをいつ開始するかを決定するために必要になるときに特に役立ちます。

setActiveConfigWithConstraints

setActiveConfigWithConstraintsメソッドは、既存のsetActiveConfigメソッドの新しい拡張機能であり、構成の変更に関する詳細情報を提供します。制約はvsyncPeriodChangeConstraintsパラメーターの一部として指定され、次のパラメーターが含まれます。

希望時間ナノ

vsync 期間が変更されるまでのCLOCK_MONOTONICの時刻 (つまり、この時刻より前に vsync 期間を変更してはなりません)。これは、プラットフォームがリフレッシュレートの変更を事前に計画したいが、キュー内に提示するバッファがすでにいくつかある場合に便利です。プラットフォームは、これらのバッファを考慮してこの時間を設定し、リフレッシュレートの移行が可能な限りスムーズになるようにします。

シームレス必須

true の場合、vsync 期間の変更は、目に見えるアーチファクトを生じることなくシームレスに行われる必要があります。このフラグは、コンテンツ変更の結果としてリフレッシュレートの変更が必要な場合 (たとえば、デバイスがアイドル状態でアニメーションが開始される場合)、プラットフォームによって使用されます。これにより、ベンダーは、目に見えるアーチファクトが発生する可能性がある特定の構成変更を許可しない機会が得られます。構成をシームレスに変更できず、 seamlessRequiredがtrueに設定されている場合、同じ構成変更をシームレスに実行できる場合、実装は戻りコードとしてSEAMLESS_NOT_POSSIBLEを返し、新しいonSeamlessPossibleコールバックを呼び出すことが期待されます。

成功すると、実装は、リフレッシュレートの変更がいつ発生するかをプラットフォームに通知するVsyncPeriodChangeTimelineを返します。 newVsyncAppliedTimeNanosパラメータは、新しい vsync 期間で新しい表示の更新が開始される時刻をCLOCK_MONOTONICに設定する必要があります。これにより、 desiredTimeNanosと組み合わせることで、プラットフォームはリフレッシュレートの切り替えを事前に計画し、事前に新しいリフレッシュレートに合わせてアプリを起動し始めることができます。これにより、リフレッシュレートのシームレスな移行が可能になります。

一部の実装では、リフレッシュレートを送信する前にリフレッシュフレームを送信する必要があります。そのため、HAL には、リフレッシュフレームが必要であることを示すrefreshRequiredパラメータと、その後リフレッシュフレームを送信する必要がある最初の vsync を示すrefreshTimeNanosがあります。

onVsyncPeriodTimingChanged [コールバック]

HAL によって呼び出されて、タイムラインの一部のパラメーターが変更され、プラットフォームがタイムラインを調整する必要があることをプラットフォームに示す新しいコールバック。このコールバックは、HAL での長い処理時間または遅いリフレッシュフレームにより、何らかの理由で古いタイムラインが失われた場合に呼び出されることが期待されます。

プラットフォームはリフレッシュレートの変更をどのように決定するのでしょうか?

リフレッシュレートの選択は、次の 2 つのシステムサービスで行われます。

ディスプレイマネージャー: DisplayManagerリフレッシュレートに関する高レベルのポリシーを設定します。これは、コンポーザー HAL 構成と同じデフォルトの表示構成を設定します。さらに、 SurfaceFlingerリフレッシュレートとして選択する最小値と最大値の範囲を設定します。
サーフェスフリンガー: デフォルト設定と同じ設定グループにあり、最小/最大範囲内のリフレッシュレートを持つ設定を設定することによって、リフレッシュレートを決定します。

ディスプレイマネージャーは次の手順を実行してポリシーを決定します。

SurfaceFlingerからアクティブな構成をクエリして、デフォルトの構成 ID を検索します
システム条件を反復して最小値と最大値の範囲を制限する
- デフォルトのリフレッシュレート設定: デフォルトのリフレッシュレート値は、 R.integer.config_defaultRefreshRate構成オーバーレイで設定されます。この値は、アニメーションとタッチ操作の標準デバイスリフレッシュレートを決定するために使用されます。
- ピークリフレッシュレートの設定: ピークリフレッシュレートの値は、 Settings.System.PEAK_REFRESH_RATEから読み取られます。この値は、現在のデバイス設定 (メニューオプションなど) を反映するために実行時に変更されます。デフォルト値は、 R.integer.config_defaultPeakRefreshRate構成オーバーレイで設定されます。
- 最小リフレッシュレート設定: 最小リフレッシュレート値は、 Settings.System.MIN_REFRESH_RATEから読み取られます。この値は、現在のデバイス設定 (メニューオプションなどから) を反映するために実行時に変更できます。デフォルト値は 0 であるため、デフォルトの最小値はありません。
- アプリケーションは ModeId を要求しました: アプリケーションはWindowManager.LayoutParams.preferredDisplayModeIdを設定して、ディスプレイが動作する必要がある優先構成を反映できます。ほとんどの状況では、 DisplayManagerそれに応じてデフォルトの構成 ID を設定し、構成のリフレッシュレートに一致するように最小および最大のリフレッシュレートを設定します。
- バッテリーセーバー: デバイスが低電力モードの場合、リフレッシュレートは 60Hz 以下に制限されます。これは、 Settings.Global.LOW_POWER_MODE.

DisplayManagerポリシーを設定すると、 SurfaceFlingerアクティブレイヤー (フレーム更新をキューに入れるレイヤー) に基づいてリフレッシュレートを設定します。レイヤーの所有者がフレームレートを設定すると、SurfaceFlinger はリフレッシュレートをそのレートの乗数に設定しようとします。たとえば、2 つのアクティブレイヤーのフレームレートが 24 と 60 に設定されている場合、SurfaceFlinger は、利用可能な場合は 120 Hz を選択します。そのようなリフレッシュレートが SurfaceFlinger で利用できない場合、フレームレートの誤差が最小となるリフレッシュレートを選択しようとします。詳細については、 developer.android.comの開発者ドキュメントを参照してください。

SurfaceFlingerリフレッシュレートの決定方法を制御するために次のフラグを維持します。

ro.surface_flinger.use_content_detection_for_refresh_rate:設定されている場合、フレームレートが設定されていない場合でも、リフレッシュレートはアクティブなレイヤーに基づいて決定されます。 SurfaceFlinger は、バッファーに付加されたプレゼンテーションタイムスタンプを確認することで、レイヤーがバッファーに投稿している平均 fps を見つけるヒューリスティックを維持します。
ro.surface_flinger.set_touch_timer_ms : > 0 の場合、設定されたタイムアウトの間、ユーザーが画面に触れたときにデフォルトのリフレッシュレートが使用されます。このヒューリスティックは、アニメーションのデフォルトのリフレッシュレートを準備するために行われます。
ro.surface_flinger.set_idle_timer_ms : > 0 の場合、設定されたタイムアウトの間画面の更新がないときに最小リフレッシュレートが使用されます。
ro.surface_flinger.set_display_power_timer_ms : > 0 の場合、設定されたタイムアウトの間、ディスプレイをオンにするとき (または AOD を終了するとき) にデフォルトのリフレッシュレートが使用されます。

フレームレートAPI

フレームレート API を使用すると、アプリは意図したフレームレートを Android プラットフォームに通知でき、Android 11 をターゲットとするアプリで利用できます。フレームレート API の詳細については、 developer.android.comの開発者ドキュメントを確認してください。

開発者向けオプション

現在のリフレッシュレートでディスプレイ上のオーバーレイを切り替える新しい開発者向けオプションがメニューに追加されました。新しいオプションは、 [設定] > [システム] > [開発者向けオプション] > [リフレッシュレートの表示] にあります。