1--- 2title: OEM testing 3--- 4 5ExoPlayer is used by a large number of Android applications. As an OEM, it's 6important to ensure that ExoPlayer works correctly both on new devices, and on 7new platform builds for existing devices. This page describes compatibility 8tests that we recommend running before shipping a device or platform OTA, and 9some of the common failure modes encountered when running them. 10 11## Running the tests ## 12 13To run ExoPlayer's playback tests, first check out the latest release of 14ExoPlayer from [GitHub][]. You can then run the tests from the command line or 15Android Studio. 16 17### Command line ### 18 19From the root directory, build and install the playback tests: 20~~~ 21./gradlew :playbacktests:installDebug 22~~~ 23{: .language-shell} 24Next, run the playback tests in the GTS package: 25~~~ 26adb shell am instrument -w -r -e debug false \ 27 -e package com.google.android.exoplayer2.playbacktests.gts \ 28 com.google.android.exoplayer2.playbacktests.test/androidx.test.runner.AndroidJUnitRunner 29~~~ 30{: .language-shell} 31Test results appear in STDOUT. 32 33### Android Studio ### 34 35Open the ExoPlayer project, navigate to the `playbacktests` module, right click 36on the `gts` folder and run the tests. Test results appear in Android Studio's 37Run window. 38 39## Common failure modes ## 40 41Some of the common failure modes encountered when running ExoPlayer's playback 42tests are described below, together with the likely root cause in each case. We 43will add to this list as further failure modes are discovered. 44 45### Unexpected video buffer presentation timestamp ### 46 47Logcat will contain an error similar to: 48~~~ 49Caused by: java.lang.IllegalStateException: Expected to dequeue video buffer 50with presentation timestamp: 134766000. Instead got: 134733000 (Processed 51buffers since last flush: 2242). 52~~~ 53{: .language-shell} 54This failure is most often caused by the video decoder under test incorrectly 55discarding, inserting or re-ordering buffers. In the example above, the test 56expected to dequeue a buffer with presentation timestamp `134766000` from 57`MediaCodec.dequeueOutputBuffer`, but found that it dequeued a buffer with 58presentation timestamp `134733000` instead. We recommend that you check the 59decoder implementation when encountering this failure, in particular that it 60correctly handles adaptive resolution switches without discarding any buffers. 61 62### Too many dropped buffers ### 63 64Logcat will contain an error similar to: 65~~~ 66junit.framework.AssertionFailedError: Codec(DashTest:Video) was late decoding: 67200 buffers. Limit: 25. 68~~~ 69{: .language-shell} 70This failure is a performance problem, where the video decoder under test was 71late decoding a large number of buffers. In the example above, ExoPlayer dropped 72200 buffers because they were late by the time they were dequeued, for a test 73that imposes a limit of 25. The most obvious cause is that the video decoder 74is too slow decoding buffers. If the failures only occur for the subset of tests 75that play Widevine protected content, it's likely that the platform operations 76for buffer decryption are too slow. We recommend checking the performance of 77these components, and looking at whether any optimizations can be made to speed 78them up. 79 80### Native window could not be authenticated ### 81 82Logcat will contain an error similar to: 83~~~ 84SurfaceUtils: native window could not be authenticated 85ExoPlayerImplInternal: Internal runtime error. 86ExoPlayerImplInternal: android.media.MediaCodec$CodecException: Error 0xffffffff 87~~~ 88{: .language-shell} 89This failure is indicative of the platform failing to correctly set the secure 90bit flag. 91 92### Test timed out ### 93 94Logcat will contain an error similar to: 95~~~ 96AssertionFailedError: Test timed out after 300000 ms. 97~~~ 98{: .language-shell} 99This failure is most often caused by poor network connectivity during the test 100run. If the device appears to have good network connectivity then it's possible 101that the test is getting stuck calling into a platform component (e.g. 102`MediaCodec`, `MediaDrm`, `AudioTrack` etc). Inspect the call stacks of the 103threads in the test process to establish whether this is the case. 104 105[GitHub]: https://github.com/google/ExoPlayer 106