ExoPlayer se usa en una gran cantidad de apps para Android. Como OEM, es importante asegurarse de que ExoPlayer funcione correctamente tanto en dispositivos nuevos como en compilaciones de plataformas nuevas para dispositivos existentes. En esta página, se describen las pruebas de compatibilidad que recomendamos ejecutar antes de enviar una actualización inalámbrica de un dispositivo o una plataforma, y algunos de los modos de falla comunes que se detectan cuando se ejecutan.
Ejecuta las pruebas
Para ejecutar las pruebas de reproducción de ExoPlayer, primero consulta la versión más reciente de ExoPlayer desde GitHub. Luego, puedes ejecutar las pruebas desde la línea de comandos o Android Studio.
Línea de comandos
Desde el directorio raíz, compila e instala las pruebas de reproducción:
./gradlew :test-exoplayer-playback:installDebug
A continuación, ejecuta las pruebas de reproducción en el paquete de GTS:
adb shell am instrument -w -r -e debug false \ -e package androidx.media3.test.exoplayer.playback.gts \ androidx.media3.test.exoplayer.playback.test/androidx.test.runner.AndroidJUnitRunner
Los resultados de la prueba aparecen en STDOUT.
Android Studio
Abre el proyecto de ExoPlayer, navega al módulo playbacktests, haz clic con el botón derecho en la carpeta gts y ejecuta las pruebas. Los resultados de la prueba aparecen en la ventana Run de Android Studio.
Modos de falla comunes
A continuación, se describen algunos de los modos de falla comunes que se encuentran cuando se ejecutan las pruebas de reproducción de ExoPlayer, junto con la posible causa raíz en cada caso. Agregaremos elementos a esta lista a medida que se descubran más modos de falla.
Marca de tiempo de presentación del búfer de video inesperada
Logcat contendrá un error similar al siguiente:
Caused by: java.lang.IllegalStateException: Expected to dequeue video buffer
with presentation timestamp: 134766000. Instead got: 134733000 (Processed
buffers since last flush: 2242).
Este error suele deberse a que el decodificador de video en prueba descarta, inserta o reordena los búferes de forma incorrecta. En el ejemplo anterior, se esperaba que la prueba pusiera en cola un búfer con la marca de tiempo de presentación 134766000 de MediaCodec.dequeueOutputBuffer, pero se descubrió que puso en cola un búfer con la marca de tiempo de presentación 134733000. Te recomendamos que revises la implementación del decodificador cuando se produzca esta falla, en particular, que controle correctamente los cambios de resolución adaptativa sin descartar ningún búfer.
Se descartaron demasiados búferes
Logcat contendrá un error similar al siguiente:
junit.framework.AssertionFailedError: Codec(DashTest:Video) was late decoding:
200 buffers. Limit: 25.
Esta falla es un problema de rendimiento, en el que el decodificador de video en prueba se retrasó en la decodificación de una gran cantidad de búferes. En el ejemplo anterior, ExoPlayer descartó 200 búferes porque llegaron tarde cuando se quitaron de la cola, en una prueba que impone un límite de 25. La causa más evidente es que el decodificador de video es demasiado lento para decodificar los búferes. Si los errores solo ocurren en el subconjunto de pruebas que reproducen contenido protegido con Widevine, es probable que las operaciones de la plataforma para el descifrado del búfer sean demasiado lentas. Te recomendamos que verifiques el rendimiento de estos componentes y que analices si se pueden realizar optimizaciones para acelerarlos.
No se pudo autenticar la ventana nativa
Logcat contendrá un error similar al siguiente:
SurfaceUtils: native window could not be authenticated
ExoPlayerImplInternal: Internal runtime error.
ExoPlayerImplInternal: android.media.MediaCodec$CodecException: Error 0xffffffff
Este error indica que la plataforma no pudo establecer correctamente la marca de bits seguros.
Se agotó el tiempo de espera de la prueba
Logcat contendrá un error similar al siguiente:
AssertionFailedError: Test timed out after 300000 ms.
Esta falla suele deberse a una mala conectividad de red durante la ejecución de la prueba. Si el dispositivo parece tener buena conectividad de red, es posible que la prueba se quede atascada llamando a un componente de la plataforma (como MediaCodec, MediaDrm o AudioTrack). Inspecciona los seguimientos de pila de los subprocesos en el proceso de prueba para determinar si este es el caso.