ExoPlayer est utilisé par un grand nombre d'applications Android. En tant qu'OEM, il est important de s'assurer qu'ExoPlayer fonctionne correctement sur les nouveaux appareils et sur les nouvelles versions de plate-forme pour les appareils existants. Cette page décrit les tests de compatibilité que nous vous recommandons d'exécuter avant d'expédier une OTA pour un appareil ou 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 consulter la dernière version d'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
Ensuite, exécutez 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 des tests 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 la fenêtre d'exécution d'Android Studio.
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, ainsi que la cause probable dans chaque cas. Nous compléterons cette liste au fur et à mesure que d'autres modes de défaillance seront découverts.
Code temporel de présentation du tampon vidéo inattendu
Logcat contient 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 soumis au test supprime, 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 de MediaCodec.dequeueOutputBuffer, mais il a constaté qu'il avait retiré de la file d'attente un tampon dont l'horodatage de présentation était 134733000. Nous vous recommandons de vérifier l'implémentation du décodeur lorsque vous rencontrez cet échec, en particulier qu'elle gère correctement les changements de résolution adaptatifs 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é a décodé en retard un grand nombre de tampons. Dans l'exemple ci-dessus, ExoPlayer a supprimé 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 des tampons de décodage trop lents. 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 les opérations de la plate-forme pour le déchiffrement du tampon soient trop lentes. Nous vous recommandons de vérifier les performances de ces composants et de déterminer si des optimisations peuvent être apportées pour les accélérer.
Impossible d'authentifier la fenêtre native
Logcat contient une erreur semblable à celle-ci:
SurfaceUtils: native window could not be authenticated
ExoPlayerImplInternal: Internal runtime error.
ExoPlayerImplInternal: android.media.MediaCodec$CodecException: Error 0xffffffff
Cet échec indique que la plate-forme n'a pas défini correctement l'indicateur de bit sécurisé.
Le test a expiré
Logcat contient une erreur semblable à celle-ci:
AssertionFailedError: Test timed out after 300000 ms.
Cette défaillance est généralement due à une mauvaise connectivité réseau pendant l'exécution du test. Si l'appareil semble disposer d'une bonne connectivité réseau, il est possible que le test se bloque pendant l'appel à un composant de plate-forme (tel que MediaCodec, MediaDrm ou AudioTrack). Inspectez les piles d'appels des threads dans le processus de test pour déterminer si c'est le cas.