O ExoPlayer é usado por um grande número de apps Android. Como OEM, é importante garantir que o ExoPlayer funcione corretamente em novos dispositivos e em novos builds de plataforma para dispositivos atuais. Esta página descreve os testes de compatibilidade que recomendamos executar antes de enviar um dispositivo ou plataforma OTA e alguns dos modos de falha comuns encontrados durante a execução.
Como executar os testes
Para executar os testes de reprodução do ExoPlayer, confira primeiro a versão mais recente do ExoPlayer no GitHub. Em seguida, você pode executar os testes na linha de comando ou no Android Studio.
Linha de comando
No diretório raiz, crie e instale os testes de reprodução:
./gradlew :test-exoplayer-playback:installDebug
Em seguida, execute os testes de reprodução no pacote 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
Os resultados do teste aparecem em STDOUT.
Android Studio
Abra o projeto ExoPlayer, navegue até o módulo playbacktests
, clique com o botão direito do mouse
na pasta gts
e execute os testes. Os resultados do teste aparecem no
Janela "Run".
Modos de falha comuns
Alguns dos modos de falha comuns encontrados ao executar a reprodução do ExoPlayer são descritos abaixo e a causa raiz provável em cada caso. Vamos adicionar à lista à medida que mais modos de falha forem descobertos.
Carimbo de data/hora de apresentação de buffer de vídeo inesperado
O Logcat vai conter um erro semelhante a este:
Caused by: java.lang.IllegalStateException: Expected to dequeue video buffer
with presentation timestamp: 134766000. Instead got: 134733000 (Processed
buffers since last flush: 2242).
Essa falha é causada com mais frequência pelo decodificador de vídeo em teste incorretamente
o descarte, inserção
ou reordenação dos buffers. No exemplo acima, o teste
esperado para desenfileirar um buffer com o carimbo de data/hora da apresentação 134766000
de
MediaCodec.dequeueOutputBuffer
, mas descobriu que removeu um buffer da fila com
o carimbo de data/hora da apresentação 134733000
. Recomendamos que você verifique a
implementação do decodificador ao encontrar essa falha, em particular, que ela
processe corretamente as mudanças de resolução adaptativa sem descartar buffers.
Muitos buffers descartados
O Logcat vai conter um erro semelhante a este:
junit.framework.AssertionFailedError: Codec(DashTest:Video) was late decoding:
200 buffers. Limit: 25.
Essa falha é um problema de desempenho, em que o decodificador de vídeo em teste estava decodificando um grande número de buffers com atraso. No exemplo acima, o ExoPlayer deixou 200 buffers porque estavam atrasados no momento em que foram retirados da fila, para um teste que impõe um limite de 25. A causa mais óbvia é que o decodificador de vídeo é muito lento para decodificar buffers. Se as falhas ocorrerem apenas no subconjunto de testes que reproduzem conteúdo protegido pelo Widevine, é provável que as operações da plataforma para descriptografia de buffer sejam muito lentas. Recomendamos verificar a performance desses componentes e conferir se é possível fazer otimizações para acelerar o processo.
Não foi possível autenticar a janela nativa.
O Logcat vai conter um erro semelhante a este:
SurfaceUtils: native window could not be authenticated
ExoPlayerImplInternal: Internal runtime error.
ExoPlayerImplInternal: android.media.MediaCodec$CodecException: Error 0xffffffff
Essa falha indica que a plataforma não definiu corretamente o sistema bit.
O teste expirou
O Logcat vai conter um erro semelhante a este:
AssertionFailedError: Test timed out after 300000 ms.
Essa falha geralmente é causada por uma conectividade de rede ruim durante o teste
correr. Se o dispositivo parece ter uma boa conectividade de rede, é possível
que o teste está travando ao chamar um componente da plataforma (como
MediaCodec
, MediaDrm
ou AudioTrack
). Inspecione as pilhas de chamadas da
no processo de teste para estabelecer se esse é o caso.