Android 11 agrega soporte para dispositivos con múltiples frecuencias de actualización. Hay tres componentes principales en esta función:
- Nuevas API HAL introducidas en
android.hardware.graphics.composer@2.4
. - Código de plataforma para analizar configuraciones de dispositivos para diferentes frecuencias de actualización y establecer la frecuencia de actualización deseada
- Nuevas API SDK y NDK para permitir que las aplicaciones establezcan la velocidad de fotogramas deseada
Implementación
Se agregó soporte dedicado para el cambio de frecuencia de actualización a android.hardware.graphics.composer@2.4 HAL
. Recomendamos enfáticamente usar esta versión ya que las versiones anteriores de composer HAL tienen soporte limitado para el cambio de frecuencia de actualización.
Grupos de configuración
Se agregó un nuevo atributo CONFIG_GROUP
a IComposerClient::Attribute
que se puede consultar mediante la API getDisplayAttribute_2_4
. Este atributo permite a los proveedores agrupar configuraciones de visualización. Las configuraciones en el mismo grupo permiten cambiar sin problemas entre ellas en la mayoría de los casos. La plataforma utiliza el grupo de configuración para diferenciar qué configuraciones se pueden cambiar entre ellas para cambiar la frecuencia de actualización y no otros atributos para una configuración.
Considere el siguiente ejemplo que demuestra los beneficios de usar grupos de configuración con un dispositivo que admite cuatro configuraciones de pantalla:
- 1080p@60Hz
- 1080p@90Hz
- 1080i a 72 Hz
- 1080i a 48 Hz
Aunque el dispositivo admite frecuencias de actualización de 48 Hz, 60 Hz, 72 Hz y 90 Hz, la pantalla funciona en un modo diferente y cambiar de 60 Hz a 72 Hz cambia la configuración de la pantalla de 1080p a 1080i, lo que podría no ser el comportamiento deseado. Esto se resuelve usando grupos de configuración. Al agrupar 60 Hz y 90 Hz en un grupo de configuración y 48 Hz y 72 Hz en otro grupo de configuración. La plataforma sabe que puede cambiar entre 60 Hz y 90 Hz y entre 48 Hz y 72 Hz, pero no entre 60 Hz y 72 Hz, ya que esto resultará en un cambio de configuración en lugar de simplemente cambiar la frecuencia de actualización.
![](https://source.android.com/static/docs/core/graphics/images/multiple-refresh-rate-green.gif?authuser=7&hl=es-419)
![](https://source.android.com/static/docs/core/graphics/images/multiple-refresh-rate-blue.gif?authuser=7&hl=es-419)
Actualizaciones de la API del compositor
- getDisplayVsyncPeriod
- Para un mejor control y previsibilidad al cambiar las frecuencias de actualización, se ha agregado
getDisplayVsyncPeriod
.getDisplayVsyncPeriod
devuelve la frecuencia de actualización actual (en términos de período vsync) en la que opera la pantalla. Esto es especialmente útil cuando la plataforma necesita la transición entre la frecuencia de actualización y la frecuencia de actualización actual para decidir cuándo comenzar el siguiente cuadro. - setActiveConfigWithConstraints
- El método
setActiveConfigWithConstraints
es una nueva extensión del métodosetActiveConfig
existente y proporciona más información sobre el cambio de configuración. Las restricciones se proporcionan como parte de los parámetrosvsyncPeriodChangeConstraints
y contienen los siguientes parámetros. - deseadoTiempoNanos
- El tiempo en
CLOCK_MONOTONIC
después del cual el período vsync puede cambiar (es decir, el período vsync no debe cambiar antes de este tiempo). Esto es útil cuando la plataforma quiere planificar con anticipación un cambio en la frecuencia de actualización, pero ya tiene algunos búfer en cola para presentar. La plataforma establece este tiempo en consecuencia para tener en cuenta esos búferes y asegurarse de que la transición de la frecuencia de actualización sea lo más fluida posible. - sin costuraRequerido
- Si es verdadero, requiere que el cambio del período vsync se produzca sin problemas y sin artefactos visuales perceptibles. La plataforma utiliza este indicador cuando se necesita un cambio de frecuencia de actualización como resultado de un cambio de contenido (por ejemplo, el dispositivo está inactivo y comienza la animación). Esto le da al proveedor la oportunidad de no permitir ciertos cambios de configuración cuando podrían resultar en un artefacto visual notable. Si las configuraciones no se pueden cambiar sin problemas y
seamlessRequired
se establece entrue
, se espera que la implementación devuelvaSEAMLESS_NOT_POSSIBLE
como código de retorno y llame a la nueva devolución de llamadaonSeamlessPossible
cuando el mismo cambio de configuración se pueda realizar sin problemas. Tras el éxito, la implementación devuelve un
VsyncPeriodChangeTimeline
que le dice a la plataforma cuándo esperar que ocurra el cambio de frecuencia de actualización. Los parámetrosnewVsyncAppliedTimeNanos
deben establecerse en la hora enCLOCK_MONOTONIC
cuando la nueva pantalla comenzará a actualizarse en el nuevo período vsync. Esto, junto con eldesiredTimeNanos
, permite que la plataforma planifique con anticipación el cambio de frecuencia de actualización y comience a marcar las aplicaciones para la nueva frecuencia de actualización por adelantado. Esto permite una transición perfecta de la frecuencia de actualización.Algunas implementaciones requieren que se envíe un marco de actualización antes de que se pueda enviar la frecuencia de actualización. Para eso, HAL tiene el parámetro
refreshRequired
para indicar que se necesita un marco de actualización yrefreshTimeNanos
para indicar el primer vsync donde se debe enviar un marco de actualización después.- onVsyncPeriodTimingChanged [devolución de llamada]
- Una nueva devolución de llamada a la que HAL puede llamar para indicar a la plataforma que algún parámetro de la línea de tiempo cambió y la plataforma necesita ajustar su línea de tiempo. Se espera que se llame a esta devolución de llamada si, por alguna razón, se perdió la línea de tiempo anterior debido a un tiempo de procesamiento prolongado en HAL o un marco de actualización tardío.
¿Cómo decide la plataforma cambiar la frecuencia de actualización?
La selección de frecuencia de actualización ocurre en los siguientes dos servicios del sistema:
- Gestor de pantalla
-
DisplayManager
establece la política de alto nivel en torno a la frecuencia de actualización. Establece una configuración de visualización predeterminada, que es la misma que la configuración HAL del compositor. Además, establece un rango de valores mínimos y máximos para queSurfaceFlinger
elija como frecuencia de actualización. - Deflector de superficie
- Determina la frecuencia de actualización estableciendo una configuración que se encuentra en el mismo grupo de configuración que la configuración predeterminada y con una frecuencia de actualización dentro del rango mínimo/máximo.
El Administrador de pantalla ejecuta los siguientes pasos para determinar la política:
- Encuentra el ID de configuración predeterminado consultando la configuración activa de
SurfaceFlinger
- Restringir el rango de valores mínimos y máximos iterando sobre las condiciones del sistema
- Configuración de frecuencia de actualización predeterminada : el valor de frecuencia de actualización predeterminado se establece en la superposición de configuración
R.integer.config_defaultRefreshRate
. Este valor se usa para determinar la frecuencia de actualización estándar del dispositivo para animaciones e interacciones táctiles. - Configuración de frecuencia máxima de actualización: el valor de la frecuencia máxima de actualización se lee de
Settings.System.PEAK_REFRESH_RATE
. Este valor se cambia en tiempo de ejecución para reflejar la configuración actual del dispositivo (como desde una opción de menú). El valor predeterminado se establece en la superposición de configuraciónR.integer.config_defaultPeakRefreshRate
. - Configuración de frecuencia de actualización mínima : el valor de frecuencia de actualización mínima se lee de
Settings.System.MIN_REFRESH_RATE
. Este valor se puede cambiar en tiempo de ejecución para reflejar la configuración actual del dispositivo (como desde una opción de menú). El valor predeterminado es 0, por lo que no hay un mínimo predeterminado. - ID de modo solicitado por la aplicación : las aplicaciones pueden configurar
WindowManager.LayoutParams.preferredDisplayModeId
para reflejar una configuración preferida en la que debería funcionar la pantalla. En la mayoría de las condiciones,DisplayManager
establece la ID de configuración predeterminada en consecuencia y establece la frecuencia de actualización mínima y máxima para que coincida con la frecuencia de actualización de la configuración. - Ahorro de batería : la frecuencia de actualización está restringida a 60 Hz o menos cuando el dispositivo está en modo de bajo consumo, lo que se indica a través de
Settings.Global.LOW_POWER_MODE.
- Configuración de frecuencia de actualización predeterminada : el valor de frecuencia de actualización predeterminado se establece en la superposición de configuración
Una vez que DisplayManager
establece la política, SurfaceFlinger
establece la frecuencia de actualización en función de las capas activas (capas que ponen en cola actualizaciones de marcos). Si el propietario de la capa establece una frecuencia de fotogramas , SurfaceFlinger intenta establecer la frecuencia de actualización en algo que sea un multiplicador de esa frecuencia. Por ejemplo, si dos capas activas establecen su velocidad de fotogramas en 24 y 60, SurfaceFlinger elegirá 120 Hz si está disponible. Si dicha frecuencia de actualización no está disponible para SurfaceFlinger, intentará elegir la frecuencia de actualización que tenga el error mínimo para la frecuencia de fotogramas. Para obtener más información, consulte la documentación para desarrolladores en developer.android.com
SurfaceFlinger
mantiene los siguientes indicadores para controlar cómo se decide la frecuencia de actualización:
-
ro.surface_flinger.use_content_detection_for_refresh_rate:
si se configura, la frecuencia de actualización se decide en función de las capas activas, incluso si no se configuró una frecuencia de fotogramas. SurfaceFlinger mantiene una heurística en la que encuentra el promedio de fps que la capa está publicando en los búferes observando la marca de tiempo de la presentación adjunta al búfer. -
ro.surface_flinger.set_touch_timer_ms
: si > 0, se usará la frecuencia de actualización predeterminada cuando un usuario toque la pantalla durante el tiempo de espera configurado. Esta heurística se realiza para estar listo con la frecuencia de actualización predeterminada para las animaciones. -
ro.surface_flinger.set_idle_timer_ms
: si > 0, se usará la frecuencia de actualización mínima cuando no haya actualizaciones de pantalla para el tiempo de espera configurado. -
ro.surface_flinger.set_display_power_timer_ms
: si > 0, se utilizará la frecuencia de actualización predeterminada al encender la pantalla (o al salir de AOD) durante el tiempo de espera configurado.
API de velocidad de fotogramas
La API de velocidad de fotogramas permite que las aplicaciones informen a la plataforma Android sobre su velocidad de fotogramas prevista y está disponible en aplicaciones destinadas a Android 11. Para obtener más información sobre la API de velocidad de fotogramas, consulte la documentación para desarrolladores en developer.android.com .
Opciones de desarrollador
![](https://source.android.com/static/docs/core/graphics/images/multiple-refresh-rate-toggle.gif?authuser=7&hl=es-419)
Se ha agregado una nueva opción de desarrollador al menú que alterna una superposición en la pantalla con la frecuencia de actualización actual. La nueva opción está en Configuración > Sistema > Opciones de desarrollador > Mostrar frecuencia de actualización.