原始設備製造商 (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 的
「Run」(執行) 視窗。
常見的故障模式
執行 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 和/或其關係企業的商標或註冊商標。
上次更新時間：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"]],["上次更新時間：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."]]
