ExoPlayer est utilisé par un grand nombre d'applications Android. En tant qu'OEM, important de vous assurer qu'ExoPlayer fonctionne correctement sur les nouveaux appareils et sur de nouvelles plateformes pour les appareils existants. Cette page décrit les tests de compatibilité que nous vous recommandons d'exécuter avant d'expédier une mise à jour OTA d'un appareil ou d'une plate-forme, ainsi que certains des modes de défaillance courants rencontrés lors de leur exécution.
Exécuter les tests
Pour exécuter les tests de lecture d'ExoPlayer, commencez par vérifier la dernière version de ExoPlayer sur GitHub Vous pouvez ensuite exécuter les tests à partir de la ligne de commande ou d'Android Studio.
Ligne de commande
À partir du répertoire racine, créez et installez les tests de lecture:
./gradlew :test-exoplayer-playback:installDebug
Exécutez ensuite les tests de lecture dans le package 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
Les résultats du test s'affichent dans STDOUT.
Android Studio
Ouvrez le projet ExoPlayer, accédez au module playbacktests
, effectuez un clic droit sur le dossier gts
, puis exécutez les tests. Les résultats des tests s'affichent dans
Fenêtre d'exécution.
Modes de défaillance courants
Certains des modes de défaillance courants rencontrés lors de l'exécution des tests de lecture d'ExoPlayer sont décrits ci-dessous, avec la cause probable dans chaque cas. Nous ajouterons d'autres modes de défaillance à cette liste à mesure qu'ils seront découverts.
Code temporel de présentation inattendu de la mémoire tampon de la vidéo
Logcat contiendra une erreur semblable à celle-ci:
Caused by: java.lang.IllegalStateException: Expected to dequeue video buffer
with presentation timestamp: 134766000. Instead got: 134733000 (Processed
buffers since last flush: 2242).
Cet échec est le plus souvent dû au fait que le décodeur vidéo testé jette, insère ou réorganise de manière incorrecte des tampons. Dans l'exemple ci-dessus, le test devait retirer de la file d'attente un tampon avec le code temporel de présentation 134766000
à partir de MediaCodec.dequeueOutputBuffer
, mais il a constaté qu'il avait retiré de la file d'attente un tampon avec le code temporel de présentation 134733000
. Nous vous recommandons de consulter
du décodeur en cas d'échec, en particulier si
gère correctement les changements de résolution adaptatives sans supprimer les tampons.
Trop de tampons supprimés
Logcat contient une erreur semblable à celle-ci :
junit.framework.AssertionFailedError: Codec(DashTest:Video) was late decoding:
200 buffers. Limit: 25.
Cet échec est un problème de performances : le décodeur vidéo testé le décodage tardif d'un grand nombre de tampons. Dans l'exemple ci-dessus, ExoPlayer a abandonné 200 tampons, car ils étaient en retard au moment de leur retrait de la file d'attente, pour un test qui impose une limite de 25. La cause la plus évidente est que le décodeur vidéo est trop lent à décoder les tampons. Si les échecs ne se produisent que pour le sous-ensemble de tests qui lisent du contenu protégé par Widevine, il est probable que le fonctionnement pour le déchiffrement du tampon sont trop lents. Nous vous recommandons de vérifier les performances ces composants, et chercher à déterminer s'il est possible d'optimiser et de les activer.
Impossible d'authentifier la fenêtre native
Logcat contiendra une erreur semblable à celle-ci:
SurfaceUtils: native window could not be authenticated
ExoPlayerImplInternal: Internal runtime error.
ExoPlayerImplInternal: android.media.MediaCodec$CodecException: Error 0xffffffff
Cela peut indiquer que la plate-forme n'a pas correctement configuré de bits.
Le test a expiré
Logcat contient une erreur semblable à celle-ci :
AssertionFailedError: Test timed out after 300000 ms.
Cet échec est généralement dû à une mauvaise connectivité réseau lors du test
exécuter. Si l'appareil semble avoir
une bonne connectivité réseau, il est possible
que le test se bloque lors de l'appel d'un composant de plate-forme (tel que
MediaCodec
, MediaDrm
ou AudioTrack
). Inspectez les piles d'appels du
dans le processus de test pour déterminer si tel est le cas.