اختبار المصنّع الأصلي للجهاز

يتم استخدام ExoPlayer من قِبل عدد كبير من تطبيقات Android. بصفتك مصنّع أجهزة أصلية، من المهم التأكّد من أنّ ExoPlayer يعمل بشكل صحيح على الأجهزة الجديدة وعلى إصدارات المنصة الجديدة للأجهزة الحالية. توضّح هذه الصفحة اختبارات التوافق التي ننصح بإجرائها قبل شحن جهاز أو منصة عبر التحديث عبر الهواء (OTA)، وبعض أوضاع الأعطال الشائعة التي تحدث عند إجراء هذه الاختبارات.

تنفيذ الاختبارات

لتشغيل اختبارات التشغيل في ExoPlayer، عليك أولاً تنزيل أحدث إصدار من ExoPlayer من GitHub. يمكنك بعد ذلك إجراء الاختبارات من سطر الأوامر أو استوديو Android.

سطر الأوامر

من الدليل الجذر، أنشئ اختبارات التشغيل وثبِّتها:

./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

افتح مشروع ExoPlayer، وانتقِل إلى الوحدة playbacktests، وانقر بزر الماوس الأيمن على المجلد gts، ثم شغِّل الاختبارات. تظهر نتائج الاختبار في نافذة التشغيل في "استوديو Android".

أوضاع الأعطال الشائعة

في ما يلي بعض أوضاع الأعطال الشائعة التي تحدث عند تشغيل اختبارات 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. السبب الأكثر وضوحًا هو أنّ برنامج فك ترميز الفيديو بطيء جدًا في فك ترميز المخازن المؤقتة. إذا حدثت حالات الفشل فقط في مجموعة فرعية من الاختبارات التي تشغّل محتوًى محميًا باستخدام Widevine، من المحتمل أن تكون عمليات النظام الأساسي لفك تشفير المخزن المؤقت بطيئة جدًا. ننصحك بالتحقّق من أداء هذه المكوّنات ومعرفة ما إذا كان يمكن إجراء أي تحسينات لتسريعها.

تعذّر إثبات صحة النافذة الأصلية

سيحتوي 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). افحص حِزم استدعاء سلاسل العمليات في عملية الاختبار لتحديد ما إذا كان هذا هو الحال.