Android 11 agrega soporte para dispositivos con múltiples frecuencias de actualización. Hay tres componentes principales de esta característica:
- 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 de 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 encarecidamente utilizar 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 de 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@72Hz
- 1080i@48Hz
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 al cambiar de 60 Hz a 72 Hz se cambia la configuración de la pantalla de 1080p a 1080i, lo que puede no ser el comportamiento deseado. Esto se resuelve usando grupos de configuración. Agrupando 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=0&hl=es)
![](https://source.android.com/static/docs/core/graphics/images/multiple-refresh-rate-blue.gif?authuser=0&hl=es)
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 de vsync) a 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 fotograma. - 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. - tiempo deseadoNanos
- El tiempo en
CLOCK_MONOTONIC
después del cual el período de vsync puede cambiar (es decir, el período de 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 buffers en la cola para presentar. La plataforma establece este tiempo en consecuencia para tener en cuenta esos buffers y asegurarse de que la transición de la frecuencia de actualización sea lo más fluida posible. - sin costurasRequerido
- Si es verdadero, requiere que el cambio del período de vsync se realice sin problemas y sin ningún artefacto visual perceptible. 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
está establecido 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. Si tiene éxito, la implementación devuelve un
VsyncPeriodChangeTimeline
que le indica a la plataforma cuándo esperar que se produzca el cambio en la frecuencia de actualización. Los parámetrosnewVsyncAppliedTimeNanos
deben configurarse en la hora enCLOCK_MONOTONIC
cuando la nueva pantalla comenzará a actualizarse en el nuevo período de vsync. Esto, junto condesiredTimeNanos
, permite a la plataforma planificar con anticipación el cambio de frecuencia de actualización y comenzar a seleccionar aplicaciones para la nueva frecuencia de actualización con anticipación. Esto permite una transición perfecta de la frecuencia de actualización.Algunas implementaciones requieren que se envíe un cuadro de actualización antes de poder enviar la frecuencia de actualización. Para eso, HAL tiene el parámetro
refreshRequired
para indicar que se necesita un fotograma de actualización yrefreshTimeNanos
para indicar el primer vsync al que se debe enviar un fotograma de actualización después.- onVsyncPeriodTimingChanged [devolución de llamada]
- Una nueva devolución de llamada a la que HAL puede llamar para indicarle a la plataforma que algún parámetro de la línea de tiempo cambió y que 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 la frecuencia de actualización ocurre en los dos servicios del sistema siguientes:
- 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
los elija como frecuencia de actualización. - SuperficieFlinger
- Determina la frecuencia de actualización estableciendo una configuración que esté 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 visualización sigue los siguientes pasos para determinar la política:
- Encuentra el ID de configuración predeterminado consultando la configuración activa desde
SurfaceFlinger
- Restringir el rango de valores mínimo y máximo 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 utiliza para determinar la frecuencia de actualización estándar del dispositivo para animaciones e interacciones táctiles. - Configuración de frecuencia de actualización máxima : el valor de frecuencia de actualización máxima se lee en
Settings.System.PEAK_REFRESH_RATE
. Este valor se cambia en tiempo de ejecución para reflejar la configuración actual del dispositivo (por ejemplo, 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 en
Settings.System.MIN_REFRESH_RATE
. Este valor se puede cambiar en tiempo de ejecución para reflejar la configuración actual del dispositivo (por ejemplo, desde una opción de menú). El valor predeterminado es 0, por lo que no existe un mínimo predeterminado. - ModeId solicitado por la aplicación : las aplicaciones pueden configurar
WindowManager.LayoutParams.preferredDisplayModeId
para reflejar una configuración preferida en la que debe funcionar la pantalla. En la mayoría de las condicionesDisplayManager
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 cual 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 las actualizaciones de fotogramas). Si el propietario de la capa establece una velocidad 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 velocidad de fotogramas. Para obtener más información, consulte la documentación para desarrolladores en desarrollador.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 establece, la frecuencia de actualización se decide en función de las capas activas, incluso si no se estableció una velocidad de fotogramas. SurfaceFlinger mantiene una heurística en la que encuentra los fps promedio que la capa publica en los búferes al observar la marca de tiempo de presentación adjunta al búfer. -
ro.surface_flinger.set_touch_timer_ms
: si > 0, se utilizará 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 utilizará la frecuencia de actualización mínima cuando no haya actualizaciones de pantalla durante 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 de su velocidad de fotogramas prevista y está disponible en aplicaciones orientadas a Android 11. Para obtener más información sobre la API de velocidad de fotogramas, consulte la documentación para desarrolladores en desarrollador.android.com .
Opciones de desarrollador
![](https://source.android.com/static/docs/core/graphics/images/multiple-refresh-rate-toggle.gif?authuser=0&hl=es)
Se agregó 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.