ExoPlayer è utilizzato da un numero elevato di app Android. In qualità di OEM, è importante garantire che ExoPlayer funzioni correttamente sia sui nuovi dispositivi sia su nuove build di piattaforme per dispositivi esistenti. In questa pagina vengono descritti i test di compatibilità che consigliamo di eseguire prima di spedire l'OTA di un dispositivo o una piattaforma e alcune delle modalità di errore comuni che si sono verificati durante l'esecuzione.
Esecuzione dei test
Per eseguire i test di riproduzione di ExoPlayer, controlla prima l'ultima release di ExoPlayer di GitHub. Puoi quindi eseguire i test dalla riga di comando o da Android Studio.
Riga di comando
Dalla directory principale, crea e installa i test di riproduzione:
./gradlew :test-exoplayer-playback:installDebug
Quindi, esegui i test di riproduzione nel pacchetto 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
I risultati del test vengono visualizzati in STDOUT.
Android Studio
Apri il progetto ExoPlayer, vai al modulo playbacktests, fai clic con il tasto destro del mouse sulla cartella gts ed esegui i test. I risultati dei test vengono visualizzati
nella finestra Esegui di Android Studio.
Modalità di errore comuni
Di seguito sono descritte alcune delle modalità di errore comuni che si verificano durante l'esecuzione dei test di riproduzione di ExoPlayer, insieme alla probabile causa principale in ciascun caso. Aggiungeremo questo elenco man mano che verranno rilevate ulteriori modalità di errore.
Timestamp imprevisto della presentazione nel buffer del video
Logcat conterrà un errore simile a:
Caused by: java.lang.IllegalStateException: Expected to dequeue video buffer
with presentation timestamp: 134766000. Instead got: 134733000 (Processed
buffers since last flush: 2242).
Questo errore il più delle volte è causato dal fatto che il decoder video sottoposto a test ha erroneamente eliminato, inserito o riordinato i buffer. Nell'esempio precedente, il test prevedeva di rimuovere la coda di un buffer con timestamp di presentazione 134766000 da MediaCodec.dequeueOutputBuffer, ma ha invece rilevato che ha rimosso la coda di un buffer con timestamp di presentazione 134733000. Ti consigliamo di controllare l'implementazione del decoder quando si verifica questo errore, in particolare che gestisca correttamente gli switch di risoluzione adattive senza eliminare i buffer.
Troppi buffer rilasciati
Logcat conterrà un errore simile a:
junit.framework.AssertionFailedError: Codec(DashTest:Video) was late decoding:
200 buffers. Limit: 25.
Questo errore è un problema di prestazioni in cui il decodificatore video sottoposto a test ha decodificato in ritardo un numero elevato di buffer. Nell'esempio precedente, ExoPlayer ha perso 200 buffer perché erano in ritardo nel momento in cui sono stati rimossi dalla coda, per un test che impone un limite di 25. La causa più evidente è che il decoder video è troppo lento per la decodifica dei buffer. Se gli errori si verificano solo per il sottoinsieme di test che riproducono contenuti protetti da Widevine, è probabile che le operazioni della piattaforma per la decriptazione del buffer siano troppo lente. Ti consigliamo di controllare le prestazioni di questi componenti e di cercare eventuali ottimizzazioni per velocizzarli.
Impossibile autenticare la finestra nativa
Logcat conterrà un errore simile a:
SurfaceUtils: native window could not be authenticated
ExoPlayerImplInternal: Internal runtime error.
ExoPlayerImplInternal: android.media.MediaCodec$CodecException: Error 0xffffffff
Questo errore è indicativo che la piattaforma non ha impostato correttamente il flag di bit sicuro.
Timeout del test
Logcat conterrà un errore simile a:
AssertionFailedError: Test timed out after 300000 ms.
Questo errore è spesso causato da una scarsa connettività di rete durante l'esecuzione del test. Se la connettività di rete del dispositivo sembra buona, è possibile che il test si sia bloccato durante la chiamata a un componente della piattaforma (ad esempio MediaCodec, MediaDrm o AudioTrack). Controlla gli stack di chiamate dei thread nel processo di test per stabilire se è questo il caso.