ExoPlayer wird von einer großen Anzahl von Android-Apps verwendet. Als OEM ist es wichtig, dass ExoPlayer sowohl auf neuen Geräten als auch auf neuen Plattform-Builds für vorhandene Geräte korrekt funktioniert. Auf dieser Seite werden Kompatibilitätstests beschrieben, die wir empfehlen, vor dem Versand eines Geräts oder einer Plattform per OTA auszuführen. Außerdem werden einige der häufigsten Fehlermodi beschrieben, die beim Ausführen dieser Tests auftreten.
Tests ausführen
Wenn Sie die Wiedergabetests von ExoPlayer ausführen möchten, rufen Sie zuerst die aktuelle Version von ExoPlayer von GitHub ab. Anschließend können Sie die Tests über die Befehlszeile oder Android Studio ausführen.
Befehlszeile
Erstellen und installieren Sie die Wiedergabetests im Stammverzeichnis:
./gradlew :test-exoplayer-playback:installDebug
Führen Sie als Nächstes die Wiedergabetests im GTS-Paket aus:
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
Die Testergebnisse werden in STDOUT angezeigt.
Android Studio
Öffnen Sie das ExoPlayer-Projekt, rufen Sie das Modul playbacktests auf, klicken Sie mit der rechten Maustaste auf den Ordner gts und führen Sie die Tests aus. Die Testergebnisse werden im Fenster „Run“ (Ausführen) von Android Studio angezeigt.
Häufige Fehlermodi
Im Folgenden werden einige der häufigsten Fehlermodi beschrieben, die beim Ausführen der Wiedergabetests von ExoPlayer auftreten, zusammen mit der wahrscheinlichen Ursache in jedem Fall. Wir werden diese Liste ergänzen, sobald weitere Fehlerarten entdeckt werden.
Unerwarteter Zeitstempel für die Videobuffer-Präsentation
Logcat enthält einen Fehler wie den folgenden:
Caused by: java.lang.IllegalStateException: Expected to dequeue video buffer
with presentation timestamp: 134766000. Instead got: 134733000 (Processed
buffers since last flush: 2242).
Dieser Fehler wird am häufigsten dadurch verursacht, dass der zu testende Videodecoder Puffer fälschlicherweise verwirft, einfügt oder neu anordnet. Im obigen Beispiel wurde erwartet, dass im Test ein Puffer mit dem Präsentationszeitstempel 134766000 aus MediaCodec.dequeueOutputBuffer in die Warteschlange gestellt wird. Stattdessen wurde jedoch ein Puffer mit dem Präsentationszeitstempel 134733000 in die Warteschlange gestellt. Wir empfehlen, die Decoderimplementierung zu überprüfen, wenn dieser Fehler auftritt. Achten Sie insbesondere darauf, dass adaptive Auflösungswechsel korrekt verarbeitet werden, ohne dass Puffer verworfen werden.
Zu viele verworfene Puffer
Logcat enthält einen Fehler wie den folgenden:
junit.framework.AssertionFailedError: Codec(DashTest:Video) was late decoding:
200 buffers. Limit: 25.
Dieser Fehler ist ein Leistungsproblem, bei dem der getestete Videodecoder eine große Anzahl von Puffern zu spät decodiert hat. Im obigen Beispiel hat ExoPlayer 200 Puffer verworfen, weil sie beim Dequeue zu spät waren. Der Test hat ein Limit von 25. Die offensichtlichste Ursache ist, dass der Videodecoder zu langsam ist, um Puffer zu decodieren. Wenn die Fehler nur bei der Teilmenge der Tests auftreten, bei denen Widevine-geschützte Inhalte wiedergegeben werden, sind die Plattformvorgänge für die Pufferentschlüsselung wahrscheinlich zu langsam. Wir empfehlen, die Leistung dieser Komponenten zu prüfen und zu sehen, ob Optimierungen vorgenommen werden können, um sie zu beschleunigen.
Das native Fenster konnte nicht authentifiziert werden
Logcat enthält einen Fehler wie den folgenden:
SurfaceUtils: native window could not be authenticated
ExoPlayerImplInternal: Internal runtime error.
ExoPlayerImplInternal: android.media.MediaCodec$CodecException: Error 0xffffffff
Dieser Fehler deutet darauf hin, dass die Plattform das Secure-Bit-Flag nicht richtig gesetzt hat.
Zeitüberschreitung beim Test
Logcat enthält einen Fehler wie den folgenden:
AssertionFailedError: Test timed out after 300000 ms.
Dieser Fehler wird meist durch eine schlechte Netzwerkverbindung während des Testlaufs verursacht. Wenn das Gerät eine gute Netzwerkverbindung hat, kann es sein, dass der Test beim Aufrufen einer Plattformkomponente (z. B. MediaCodec, MediaDrm oder AudioTrack) hängen bleibt. Prüfen Sie die Callstacks der Threads im Testprozess, um festzustellen, ob dies der Fall ist.