OEM 测试
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
许多 Android 应用都在使用 ExoPlayer。作为原始设备制造商 (OEM)，
务必要确保 ExoPlayer 在新设备上以及
新平台版本。本页将介绍兼容性
我们建议在发布设备或平台 OTA 之前运行的测试；以及
运行它们时遇到的一些常见故障模式。
运行测试
要运行 ExoPlayer 的播放测试，请先查看最新版本的
GitHub 中的 ExoPlayer。然后，您可以从命令行或
Android Studio。
命令行
从根目录中，构建并安装播放测试：
./gradlew :test-exoplayer-playback:installDebug
接下来，运行 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
测试结果会显示在 STDOUT 中。
Android Studio
打开 ExoPlayer 项目，前往 playbacktests 模块，然后右键点击
位于 gts 文件夹下，然后运行测试。测试结果会显示在 Android Studio 的
运行窗口。
常见故障模式
运行 ExoPlayer 的播放时遇到的一些常见故障模式
下面介绍了各种测试，以及每种情况下可能出现的根本原因。周三
将添加到此列表中。
意外的视频缓冲区呈现时间戳
Logcat 将包含类似于以下内容的错误：
Caused by: java.lang.IllegalStateException: Expected to dequeue video buffer
with presentation timestamp: 134766000. Instead got: 134733000 (Processed
buffers since last flush: 2242).
此故障最常见的原因是被测视频解码器未正确操作
舍弃、插入或重新排序缓冲区。在上面的示例中，测试
预计会将呈现时间戳为 134766000 的缓冲区移出队列，
MediaCodec.dequeueOutputBuffer，但发现其将一个缓冲区移出队列，
呈现时间戳 134733000。我们建议您查看
解码器实现，尤其是
正确处理自适应分辨率开关，而不舍弃任何缓冲区。
丢弃的缓冲区过多
Logcat 将包含类似于以下内容的错误：
junit.framework.AssertionFailedError: Codec(DashTest:Video) was late decoding:
200 buffers. Limit: 25.
此故障是性能问题，即被测视频解码器
延迟解码大量缓冲区。在上面的示例中，ExoPlayer 丢弃了
200 个缓冲区，因为它们在离开队列时迟到，用于测试
并将上限设为 25。最明显的原因是视频解码器
因为解码缓冲区的速度过慢。如果只有部分测试出现失败情况
则相应平台的操作
速度太慢。我们建议您检查
这些要素，看看能否对速度进行优化
。
无法对原生窗口进行身份验证
Logcat 将包含类似于以下内容的错误：
SurfaceUtils: native window could not be authenticated
ExoPlayerImplInternal: Internal runtime error.
ExoPlayerImplInternal: android.media.MediaCodec$CodecException: Error 0xffffffff
此故障表明平台未能正确设置
位标志。
测试超时
Logcat 将包含类似于以下内容的错误：
AssertionFailedError: Test timed out after 300000 ms.
此故障最常见的原因是测试期间网络连接不畅
运行。如果设备看似网络连接良好，则有可能
测试在调用平台组件（例如
MediaCodec、MediaDrm 或 AudioTrack）。检查
线程，以确定是否属于这种情况。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-07-27。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-07-27。"],[],[],null,["# OEM testing\n\nExoPlayer is used by a large number of Android apps. As an OEM, it's\nimportant to ensure that ExoPlayer works correctly both on new devices, and on\nnew platform builds for existing devices. This page describes compatibility\ntests that we recommend running before shipping a device or platform OTA, and\nsome of the common failure modes encountered when running them.\n\nRunning the tests\n-----------------\n\nTo run ExoPlayer's playback tests, first check out the latest release of\nExoPlayer from [GitHub](https://github.com/androidx/media). You can then run the tests from the command line or\nAndroid Studio.\n\n### Command line\n\nFrom the root directory, build and install the playback tests: \n\n```\n./gradlew :test-exoplayer-playback:installDebug\n```\n\nNext, run the playback tests in the GTS package: \n\n```\nadb shell am instrument -w -r -e debug false \\\n -e package androidx.media3.test.exoplayer.playback.gts \\\n androidx.media3.test.exoplayer.playback.test/androidx.test.runner.AndroidJUnitRunner\n```\n\nTest results appear in STDOUT.\n\n### Android Studio\n\nOpen the ExoPlayer project, navigate to the `playbacktests` module, right click\non the `gts` folder and run the tests. Test results appear in Android Studio's\nRun window.\n\nCommon failure modes\n--------------------\n\nSome of the common failure modes encountered when running ExoPlayer's playback\ntests are described below, together with the likely root cause in each case. We\nwill add to this list as further failure modes are discovered.\n\n### Unexpected video buffer presentation timestamp\n\nLogcat will contain an error similar to: \n\n Caused by: java.lang.IllegalStateException: Expected to dequeue video buffer\n with presentation timestamp: 134766000. Instead got: 134733000 (Processed\n buffers since last flush: 2242).\n\nThis failure is most often caused by the video decoder under test incorrectly\ndiscarding, inserting or re-ordering buffers. In the example above, the test\nexpected to dequeue a buffer with presentation timestamp `134766000` from\n`MediaCodec.dequeueOutputBuffer`, but found that it dequeued a buffer with\npresentation timestamp `134733000` instead. We recommend that you check the\ndecoder implementation when encountering this failure, in particular that it\ncorrectly handles adaptive resolution switches without discarding any buffers.\n\n### Too many dropped buffers\n\nLogcat will contain an error similar to: \n\n junit.framework.AssertionFailedError: Codec(DashTest:Video) was late decoding:\n 200 buffers. Limit: 25.\n\nThis failure is a performance problem, where the video decoder under test was\nlate decoding a large number of buffers. In the example above, ExoPlayer dropped\n200 buffers because they were late by the time they were dequeued, for a test\nthat imposes a limit of 25. The most obvious cause is that the video decoder\nis too slow decoding buffers. If the failures only occur for the subset of tests\nthat play Widevine protected content, it's likely that the platform operations\nfor buffer decryption are too slow. We recommend checking the performance of\nthese components, and looking at whether any optimizations can be made to speed\nthem up.\n\n### Native window could not be authenticated\n\nLogcat will contain an error similar to: \n\n SurfaceUtils: native window could not be authenticated\n ExoPlayerImplInternal: Internal runtime error.\n ExoPlayerImplInternal: android.media.MediaCodec$CodecException: Error 0xffffffff\n\nThis failure is indicative of the platform failing to correctly set the secure\nbit flag.\n\n### Test timed out\n\nLogcat will contain an error similar to: \n\n AssertionFailedError: Test timed out after 300000 ms.\n\nThis failure is most often caused by poor network connectivity during the test\nrun. If the device appears to have good network connectivity then it's possible\nthat the test is getting stuck calling into a platform component (such as\n`MediaCodec`, `MediaDrm`, or `AudioTrack`). Inspect the call stacks of the\nthreads in the test process to establish whether this is the case."]]
