Una gran cantidad de apps para Android usan ExoPlayer. Como OEM, es importante garantizar que ExoPlayer funcione correctamente en dispositivos nuevos y en compilaciones nuevas de plataformas para dispositivos existentes. En esta página, se describen las pruebas de compatibilidad que recomendamos ejecutar antes de enviar un dispositivo o una plataforma de manera inalámbrica y algunos de los modos de falla comunes que se encuentran cuando se ejecutan.
Cómo ejecutar las pruebas
Para ejecutar las pruebas de reproducción de ExoPlayer, primero consulta la versión más reciente de ExoPlayer en GitHub. Luego, podrás ejecutar las pruebas desde la línea de comandos o desde 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 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 pruebas de reproducción de ExoPlayer, junto con la causa raíz probable en cada caso. Agregaremos información a esta lista a medida que se descubran más modos de falla.
Marca de tiempo de presentación de 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).
Esta falla suele deberse a que el decodificador de video sometido a prueba descarta, inserta o reordena los búferes de forma incorrecta. En el ejemplo anterior, la prueba se espera que quite de la cola un búfer con la marca de tiempo de presentación 134766000 de MediaCodec.dequeueOutputBuffer, pero descubrió que, en su lugar, quitó de la cola un búfer con la marca de tiempo de presentación 134733000. Te recomendamos que verifiques la implementación del decodificador cuando encuentres este error, en especial, que maneje correctamente los interruptores de resolución adaptables sin descartar ningún búfer.
Demasiados búferes descartados
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: el decodificador de video en prueba decodificó tardíamente una gran cantidad de búferes. En el ejemplo anterior, ExoPlayer descartaba 200 búferes porque estaban retrasados cuando se quitaron de la cola, para una prueba que impone un límite de 25. La causa más obvia es que el decodificador de video es demasiado lento en los búferes de decodificación. Si las fallas solo se producen en el subconjunto de pruebas que reproducen contenido protegido por Widevine, es probable que las operaciones de la plataforma para la desencriptación del búfer sean demasiado lentas. Recomendamos verificar el rendimiento de estos componentes y analizar 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 configurar correctamente la marca de bits seguro.
Se agotó el tiempo de espera de la prueba
Logcat contendrá un error similar al siguiente:
AssertionFailedError: Test timed out after 300000 ms.
Por lo general, esta falla se debe a una conectividad de red deficiente durante la ejecución de la prueba. Si el dispositivo parece tener una buena conectividad de red, es posible que la prueba se detenga cuando llame a un componente de la plataforma (como MediaCodec, MediaDrm o AudioTrack). Inspecciona las pilas de llamadas de los subprocesos en el proceso de prueba para determinar si este es el caso.