دليل نقل البيانات إلى AndroidX Media3

يجب أن تنتقل التطبيقات التي تستخدم حاليًا مكتبة com.google.android.exoplayer2 المستقلة وandroidx.media إلى androidx.media3. استخدِم النص البرمجي للنقل لنقل ملفات إصدار Gradle وملفات مصدر Java وKotlin وملفات تنسيق XML من ExoPlayer 2.19.1 إلى AndroidX Media3 1.1.1.

نظرة عامة

قبل نقل البيانات، راجِع الأقسام التالية لمعرفة المزيد عن مزايا واجهات برمجة التطبيقات الجديدة وواجهات برمجة التطبيقات التي سيتم نقلها والمتطلبات الأساسية التي يجب أن يستوفيها مشروع تطبيقك.

أهمية نقل البيانات إلى Jetpack Media3

  • وهو الوجهة الجديدة لمكتبة ExoPlayer، بينما تم إيقاف com.google.android.exoplayer2 نهائيًا.
  • يمكنك الوصول إلى واجهة Player API على مستوى المكوّنات/العمليات باستخدام MediaBrowser/MediaController.
  • استخدِم الإمكانات الموسّعة لواجهة برمجة التطبيقات MediaSession وMediaController.
  • الإعلان عن إمكانات التشغيل باستخدام التحكّم الدقيق في الوصول
  • بسِّط تطبيقك من خلال إزالة MediaSessionConnector وPlayerNotificationManager.
  • متوافقة مع الأنظمة القديمة لواجهات برمجة التطبيقات لعملاء media-compat (MediaBrowserCompat/MediaControllerCompat/MediaMetadataCompat)

واجهات برمجة تطبيقات الوسائط التي يجب نقلها إلى AndroidX Media3

  • ‫ExoPlayer وإضافاته
    يشمل ذلك جميع وحدات مشروع ExoPlayer القديم باستثناء وحدة mediasession التي تم إيقافها نهائيًا. يمكن نقل التطبيقات أو الوحدات التي تعتمد على الحزم في com.google.android.exoplayer2 باستخدام النص البرمجي للنقل.
  • MediaSessionConnector (حسب حِزم androidx.media.* من androidx.media:media:1.4.3+)
    يجب إزالة MediaSessionConnector واستخدام androidx.media3.session.MediaSession بدلاً من ذلك.
  • MediaBrowserServiceCompat (حسب androidx.media.* حزم androidx.media:media:1.4.3+)
    نقل الفئات الفرعية من androidx.media.MediaBrowserServiceCompat إلى androidx.media3.session.MediaLibraryService والرمز باستخدام MediaBrowserCompat.MediaItem إلى androidx.media3.common.MediaItem.
  • MediaBrowserCompat (حسب android.support.v4.media.* حزم androidx.media:media:1.4.3+)
    نقل رمز العميل باستخدام MediaBrowserCompat أو MediaControllerCompat لاستخدام androidx.media3.session.MediaBrowser مع androidx.media3.common.MediaItem.

المتطلبات الأساسية

  1. التأكّد من أنّ مشروعك يخضع للتحكّم بالمصدر

    تأكَّد من إمكانية إلغاء التغييرات التي تم تطبيقها باستخدام أدوات نقل البيانات المستندة إلى نصوص برمجية. إذا لم يكن مشروعك خاضعًا للتحكّم في المصدر بعد، فهذا هو الوقت المناسب للبدء في ذلك. إذا كنت لا تريد إجراء ذلك لسبب ما، يمكنك إنشاء نسخة احتياطية من مشروعك قبل بدء عملية نقل البيانات.

  2. تحديث التطبيق

    • ننصحك بتحديث مشروعك لاستخدام أحدث إصدار من مكتبة ExoPlayer وإزالة أي طلبات إلى الطرق المتوقفة نهائيًا. إذا كنت تنوي استخدام النص البرمجي لعملية النقل، عليك مطابقة الإصدار الذي يتم التحديث إليه مع الإصدار الذي يتعامل معه النص البرمجي.

    • زيادة compileSdkVersion لتطبيقك إلى 32 على الأقل

    • ترقية Gradle والمكوّن الإضافي لنظام Gradle المتوافق مع "استوديو Android" إلى إصدار حديث يتوافق مع التبعيات المعدَّلة المذكورة سابقًا على سبيل المثال:

      • إصدار المكوّن الإضافي لنظام Gradle المتوافق مع Android: 7.1.0
      • إصدار Gradle‏: 7.4

    • استبدِل جميع عبارات الاستيراد التي تتضمّن أحرف بدل وتستخدم علامة النجمة (*) واستخدِم عبارات استيراد مؤهَّلة بالكامل: احذف عبارات الاستيراد التي تتضمّن أحرف بدل واستخدِم Android Studio لاستيراد العبارات المؤهَّلة بالكامل (F2 - Alt/Enter،‏ F2 - Alt/Enter، ...).

    • انقل البيانات من com.google.android.exoplayer2.PlayerView إلى com.google.android.exoplayer2.StyledPlayerView. هذا ضروري لأنّه لا يوجد ما يعادل com.google.android.exoplayer2.PlayerView في AndroidX Media3.

نقل ExoPlayer مع إتاحة النصوص البرمجية

يسهّل النص البرمجي الانتقال من com.google.android.exoplayer2 إلى بنية الحزمة والوحدة الجديدة ضمن androidx.media3. يطبّق النص البرمجي بعض عمليات التحقّق من الصحة على مشروعك ويطبع تحذيرات في حال تعذّر التحقّق من الصحة. وإلا، سيتم تطبيق عمليات ربط الفئات والحزم التي تمت إعادة تسميتها في موارد مشروع Gradle على Android مكتوب بلغة Java أو Kotlin.

usage: ./media3-migration.sh [-p|-c|-d|-v]|[-m|-l [-x <path>] [-f] PROJECT_ROOT]
 PROJECT_ROOT: path to your project root (location of 'gradlew')
 -p: list package mappings and then exit
 -c: list class mappings (precedence over package mappings) and then exit
 -d: list dependency mappings and then exit
 -l: list files that will be considered for rewrite and then exit
 -x: exclude the path from the list of file to be changed: 'app/src/test'
 -m: migrate packages, classes and dependencies to AndroidX Media3
 -f: force the action even when validation fails
 -v: print the exoplayer2/media3 version strings of this script
 -h, --help: show this help text

استخدام نص نقل البيانات البرمجي

  1. نزِّل النص البرمجي لنقل البيانات من علامة مشروع ExoPlayer على GitHub المقابلة للإصدار الذي حدّثت تطبيقك إليه:

    curl -o media3-migration.sh \
  "https://raw.githubusercontent.com/google/ExoPlayer/r2.19.1/media3-migration.sh"

  2. اجعل النص البرمجي قابلاً للتنفيذ:

    chmod 744 media3-migration.sh

  3. شغِّل النص البرمجي باستخدام --help للتعرّف على الخيارات.

  4. شغِّل النص البرمجي باستخدام -l لإدراج مجموعة الملفات التي تم اختيارها لنقلها (استخدِم -f لفرض الإدراج بدون تحذيرات):

    ./media3-migration.sh -l -f /path/to/gradle/project/root

  5. شغِّل النص البرمجي باستخدام -m لربط الحزم والفئات والوحدات بـ Media3. سيؤدي تشغيل النص البرمجي باستخدام الخيار -m إلى تطبيق التغييرات على الملفات المحددة.

    • التوقّف عند حدوث خطأ في التحقّق من الصحة بدون إجراء تغييرات
    ./media3-migration.sh -m /path/to/gradle/project/root
    • التنفيذ الإجباري

    إذا عثر النص البرمجي على انتهاك للمتطلبات الأساسية، يمكن فرض عملية نقل البيانات باستخدام العلامة -f:

    ./media3-migration.sh -m -f /path/to/gradle/project/root

 # list files selected for migration when excluding paths
 ./media3-migration.sh -l -x "app/src/test/" -x "service/" /path/to/project/root
 # migrate the selected files
 ./media3-migration.sh -m -x "app/src/test/" -x "service/" /path/to/project/root

أكمِل هذه الخطوات اليدوية بعد تشغيل النص البرمجي باستخدام الخيار -m:

  1. التحقّق من كيفية تغيير النص البرمجي للرمز: استخدِم أداة diff وأصلِح المشاكل المحتملة (ننصحك بالإبلاغ عن خطأ إذا كنت تعتقد أنّ النص البرمجي يتضمّن مشكلة عامة تم تقديمها بدون تمرير الخيار -f).
  2. إنشاء المشروع: استخدِم ./gradlew clean build أو اختَر ملف > مزامنة المشروع مع ملفات Gradle في &quot;استوديو Android&quot;، ثم إنشاء > تنظيف المشروع، ثم إنشاء > إعادة إنشاء المشروع (راقِب عملية الإنشاء في علامة التبويب &quot;إنشاء - ناتج الإنشاء&quot; في &quot;استوديو Android&quot;).

الخطوات المقترَحة للمتابعة:

  1. حلّ أخطاء الموافقة على استخدام واجهات برمجة تطبيقات غير مستقرة
  2. استبدال طلبات البيانات من واجهة برمجة التطبيقات التي تم إيقافها نهائيًا: استخدِم واجهة برمجة التطبيقات البديلة المقترَحة. مرِّر مؤشر الماوس فوق التحذير في استوديو Android، واطّلِع على JavaDoc للرمز الذي تم إيقافه نهائيًا لمعرفة ما يجب استخدامه بدلاً من طلب معيّن.
  3. ترتيب عبارات الاستيراد: افتح المشروع في "استوديو Android"، ثم انقر بزر الماوس الأيمن على عقدة مجلد الحزمة في عارض المشروع واختَر تحسين عمليات الاستيراد في الحِزم التي تحتوي على ملفات المصدر التي تم تغييرها.

استبدال MediaSessionConnector بـ androidx.media3.session.MediaSession

In the legacy MediaSessionCompat world, the MediaSessionConnector was responsible for syncing the state of the player with the state of the session and receiving commands from controllers that needed delegation to appropriate player methods. باستخدام AndroidX Media3، يتم تنفيذ ذلك من خلال MediaSession مباشرةً بدون الحاجة إلى موصّل.

  1. إزالة جميع الإشارات إلى MediaSessionConnector واستخداماته: إذا استخدمت النص البرمجي المبرمَج لنقل فئات ExoPlayer وحزمه، من المرجّح أن يكون النص البرمجي قد ترك الرمز البرمجي في حالة غير قابلة للتجميع في ما يتعلّق بـ MediaSessionConnector الذي لا يمكن حلّه. سيعرض لك استوديو Android الرمز المعطّل عندما تحاول إنشاء التطبيق أو تشغيله.

  2. في ملف build.gradle الذي تحتفظ فيه بالتبعيات، أضِف تبعية تنفيذ إلى وحدة جلسة AndroidX Media3 وأزِل التبعية القديمة:

    implementation "androidx.media3:media3-session:1.11.1"

  3. استبدِل MediaSessionCompat بـ androidx.media3.session.MediaSession.

  4. في موقع الرمز الذي أنشأت فيه MediaSessionCompat القديم، استخدِم androidx.media3.session.MediaSession.Builder لإنشاء MediaSession. مرِّر المشغّل لإنشاء أداة إنشاء الجلسات.

    Kotlin

    val player = ExoPlayer.Builder(context).build()
mediaSession = MediaSession.Builder(context, player).setCallback(MySessionCallback()).build()

    Java

    ExoPlayer player = new ExoPlayer.Builder(context).build();
mediaSession =
    new MediaSession.Builder(context, player).setCallback(new MySessionCallback()).build();

  5. نفِّذ MySessionCallback على النحو المطلوب في تطبيقك، وهذه الخطوة اختيارية. إذا أردت السماح لوحدات التحكّم بإضافة ملفات وسائط إلى المشغّل، يمكنك تنفيذ MediaSession.Callback.onAddMediaItems(). وتوفّر طرقًا مختلفة لواجهة برمجة التطبيقات الحالية والقديمة التي تضيف ملفات الوسائط إلى المشغّل لتشغيلها بطريقة متوافقة مع الأنظمة القديمة. ويشمل ذلك طرق MediaController.set/addMediaItems() في وحدة التحكّم Media3، بالإضافة إلى طرق TransportControls.prepareFrom*/playFrom* في واجهة برمجة التطبيقات القديمة. يمكن العثور على نموذج لتنفيذ onAddMediaItems في PlaybackService من التطبيق التجريبي للجلسة.

  6. حرِّر جلسة الوسائط في موضع الرمز الذي أتلفت فيه جلستك قبل نقل البيانات:

    Kotlin

    mediaSession?.run {
  player.release()
  release()
  mediaSession = null
}

    Java

    if (mediaSession != null) {
  mediaSession.getPlayer().release();
  mediaSession.release();
  mediaSession = null;
}

وظيفة MediaSessionConnector في Media3

يعرض الجدول التالي واجهات برمجة تطبيقات Media3 التي تتعامل مع الوظائف التي تم تنفيذها سابقًا في MediaSessionConnector.

MediaSessionConnectorAndroidX Media3
CustomActionProvider MediaSession.Callback.onCustomCommand()/ MediaSession.setMediaButtonPreferences()
PlaybackPreparer ‫MediaSession.Callback.onAddMediaItems() (يتم استدعاء prepare() داخليًا)
QueueNavigator ForwardingSimpleBasePlayer
QueueEditor MediaSession.Callback.onAddMediaItems()
RatingCallback MediaSession.Callback.onSetRating()
PlayerNotificationManager DefaultMediaNotificationProvider/ MediaNotification.Provider

نقل بيانات MediaBrowserService إلى MediaLibraryService

يقدّم AndroidX Media3 واجهة MediaLibraryService التي تحلّ محلّ MediaBrowserServiceCompat. يقدّم JavaDoc الخاص بـ MediaLibraryService وفئته الفائقة MediaSessionService مقدمة جيدة لواجهة برمجة التطبيقات ونموذج البرمجة غير المتزامن للخدمة.

يتوافق MediaLibraryService مع الإصدارات القديمة من MediaBrowserService. يستمر تطبيق العميل الذي يستخدم MediaBrowserCompat أو MediaControllerCompat في العمل بدون تغييرات في الرمز عند الاتصال بـ MediaLibraryService. بالنسبة إلى العميل، من الواضح ما إذا كان تطبيقك يستخدم MediaLibraryService أو MediaBrowserServiceCompat قديمًا.

مخطّط بياني لمكوّنات التطبيق يتضمّن الخدمة والنشاط والتطبيقات الخارجية
الشكل 1: نظرة عامة على مكوّنات تطبيق الموسيقى

  1. لكي يعمل التوافق مع الأنظمة القديمة، عليك تسجيل واجهتَي الخدمة مع خدمتك في AndroidManifest.xml. بهذه الطريقة، يعثر العميل على خدمتك من خلال واجهة الخدمة المطلوبة:

    <service android:name=".MusicService" android:exported="true">
    <intent-filter>
        <action android:name="androidx.media3.session.MediaLibraryService"/>
        <action android:name="android.media.browse.MediaBrowserService" />
    </intent-filter>
</service>

  2. في ملف build.gradle الذي تحتفظ فيه بالتبعيات، أضِف تبعية تنفيذ إلى وحدة جلسة AndroidX Media3 وأزِل التبعية القديمة:

    implementation "androidx.media3:media3-session:1.11.1"

  3. تغيير الخدمة لتكتسب الإعدادات من MediaLibraryService بدلاً من MediaBrowserService كما ذكرنا سابقًا، يتوافق MediaLibraryService مع الإصدار القديم من MediaBrowserService. وبالتالي، فإن واجهة برمجة التطبيقات الأوسع التي تقدمها الخدمة للعملاء لا تزال كما هي. لذا من المرجّح أن يتمكّن التطبيق من الاحتفاظ بمعظم المنطق المطلوب لتنفيذ MediaBrowserService وتكييفه مع MediaLibraryService الجديد.

    في ما يلي الاختلافات الرئيسية مقارنةً بالإصدار القديم من MediaBrowserServiceCompat:

    • تنفيذ طرق مراحل النشاط للخدمة: الطرق التي يجب إلغاؤها في الخدمة نفسها هي onCreate وonDestroy، حيث يخصّص التطبيق أو يحرّر جلسة المكتبة والمشغّل والموارد الأخرى. بالإضافة إلى طرق مراحل النشاط العادية للخدمة، يحتاج التطبيق إلى إلغاء onGetSession(MediaSession.ControllerInfo) لعرض MediaLibrarySession الذي تم إنشاؤه في onCreate.

    • تنفيذ MediaLibraryService.MediaLibrarySessionCallback: يتطلّب إنشاء جلسة استخدام MediaLibraryService.MediaLibrarySessionCallback لتنفيذ طرق واجهة برمجة التطبيقات للنطاق الفعلي. لذلك، بدلاً من إلغاء طرق واجهة برمجة التطبيقات للخدمة القديمة، ستلغي طرق MediaLibrarySession.Callback بدلاً من ذلك.

      بعد ذلك، يتم استخدام دالة ردّ الاتصال لإنشاء MediaLibrarySession:

      Kotlin

      mediaLibrarySession = MediaLibrarySession.Builder(context, player, MySessionCallback()).build()

      Java

      mediaLibrarySession =
    new MediaLibrarySession.Builder(context, player, new MySessionCallback()).build();

      يمكنك العثور على واجهة برمجة التطبيقات الكاملة لـ MediaLibrarySessionCallback في مستندات واجهة برمجة التطبيقات.

    • تنفيذ MediaSession.Callback.onAddMediaItems(): توفّر دالة الاستدعاء onAddMediaItems(MediaSession, ControllerInfo, List<MediaItem>) طرقًا مختلفة لواجهة برمجة التطبيقات الحالية والقديمة التي تضيف ملفات الوسائط إلى المشغّل لتشغيلها بطريقة متوافقة مع الأنظمة القديمة. ويشمل ذلك طرق MediaController.set/addMediaItems() في وحدة تحكّم Media3، بالإضافة إلى طرق TransportControls.prepareFrom*/playFrom* في واجهة برمجة التطبيقات القديمة. يمكن العثور على نموذج لتنفيذ دالة الاستدعاء في PlaybackService من التطبيق التجريبي للجلسة.

    • تستخدم حزمة AndroidX Media3 السمة androidx.media3.common.MediaItem بدلاً من MediaBrowserCompat.MediaItem وMediaMetadataCompat. يجب تغيير أجزاء الرمز البرمجي المرتبطة بالفئات القديمة وفقًا لذلك أو ربطها بـ MediaItem في Media3 بدلاً من ذلك.

    • تم تغيير نموذج البرمجة غير المتزامنة العام إلى Futures على عكس نهج Result القابل للفصل في MediaBrowserServiceCompat. يمكن أن يعرض تنفيذ الخدمة ListenableFuture غير متزامن بدلاً من فصل النتيجة أو عرض Future فوري لعرض قيمة مباشرةً.

إزالة PlayerNotificationManager

يتيح MediaLibraryService تلقّي إشعارات الوسائط تلقائيًا ويمكن إزالة PlayerNotificationManager عند استخدام MediaLibraryService أو MediaSessionService.

يمكن لأي تطبيق تخصيص الإشعار من خلال ضبط MediaNotification.Provider مخصّص في onCreate() يحلّ محلّ DefaultMediaNotificationProvider. بعد ذلك، يتولّى MediaLibraryService بدء الخدمة في المقدّمة حسب الحاجة.

من خلال إلغاء MediaLibraryService.updateNotification()، يمكن للتطبيق الحصول على الملكية الكاملة لنشر إشعار وبدء الخدمة أو إيقافها في المقدّمة حسب الحاجة.

نقل رمز العميل باستخدام MediaBrowser

باستخدام AndroidX Media3، ينفّذ MediaBrowser واجهات MediaController/Player ويمكن استخدامه للتحكّم في تشغيل الوسائط بالإضافة إلى تصفُّح مكتبة الوسائط. إذا كان عليك إنشاء MediaBrowserCompat وMediaControllerCompat في الإصدار القديم، يمكنك إجراء ذلك باستخدام MediaBrowser فقط في Media3.

يمكن إنشاء MediaBrowser وانتظار إنشاء الاتصال بالخدمة:

Kotlin

scope.launch {
  val sessionToken = SessionToken(context, ComponentName(context, "MusicService"))
  browser =
    MediaBrowser.Builder(context, sessionToken)
      .setListener(BrowserListener())
      .buildAsync()
      .await()
}

Java

SessionToken sessionToken =
    new SessionToken(context, new ComponentName(context, "MusicService"));
ListenableFuture<MediaBrowser> browserFuture =
    new MediaBrowser.Builder(context, sessionToken)
        .setListener(new BrowserListener())
        .buildAsync();

يمكنك الاطّلاع على مقالة التحكّم في التشغيل في جلسة الوسائط لمعرفة كيفية إنشاء MediaController للتحكّم في التشغيل في الخلفية.

الخطوات الإضافية وإعادة الضبط

توضّح الأقسام التالية كيفية التعامل مع أخطاء lint في واجهات برمجة التطبيقات غير المستقرة وواجهات برمجة التطبيقات المتوقفة نهائيًا بعد إكمال عملية النقل الأولية.

أخطاء واجهة برمجة التطبيقات غير المستقرة

بعد نقل البيانات إلى Media3، قد تظهر لك أخطاء في أداة Lint بشأن استخدامات واجهة برمجة التطبيقات غير المستقرة. يمكن استخدام واجهات برمجة التطبيقات هذه بأمان، وأخطاء lint هي نتيجة ثانوية لسياسة التوافق الثنائي الجديدة. إذا لم تكن بحاجة إلى توافق ثنائي صارم، يمكن منع هذه الأخطاء بأمان باستخدام تعليق توضيحي @OptIn.

خلفية

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

أدت هذه التغييرات التي قد تؤدي إلى عطل إلى مشكلتَين لمستخدمي مكتبات ExoPlayer v1 وv2:

  1. قد تؤدي الترقية إلى إصدار ExoPlayer إلى توقُّف تجميع الرموز البرمجية.
  2. كان على التطبيق الذي يعتمد على ExoPlayer بشكل مباشر وباستخدام مكتبة وسيطة التأكّد من أنّ كلا التبعيتين من الإصدار نفسه، وإلا قد تؤدي حالات عدم التوافق الثنائية إلى حدوث أعطال في وقت التشغيل.

التحسينات في Media3

توفّر Media3 توافقًا ثنائيًا لمجموعة فرعية من واجهة برمجة التطبيقات. أما الأجزاء التي لا توفّر التوافق الثنائي، فيتم تمييزها بالرمز @UnstableApi. ولتوضيح هذا الفرق، فإنّ استخدامات رموز واجهة برمجة التطبيقات غير المستقرة تؤدي إلى حدوث خطأ في أداة التحقّق من الأخطاء ما لم يتم وضع تعليقات توضيحية عليها باستخدام @OptIn.

بعد نقل البيانات من ExoPlayer v2 إلى Media3، قد تظهر لك الكثير من أخطاء lint في واجهة برمجة التطبيقات غير المستقرة. قد يجعل ذلك Media3 يبدو "أقل استقرارًا" من ExoPlayer الإصدار 2. هذا غير صحيح. تتمتع الأجزاء "غير المستقرة" من واجهة برمجة التطبيقات Media3 API بالمستوى نفسه من الاستقرار الذي تتمتع به واجهة برمجة التطبيقات ExoPlayer v2 بأكملها، ولا يتوفّر التوافق الثنائي لواجهة برمجة التطبيقات Media3 API المستقرة في ExoPlayer v2 على الإطلاق. يكمن الفرق في أنّ خطأ lint ينبّهك الآن إلى مستويات الثبات المختلفة.

التعامل مع أخطاء lint غير المستقرة في واجهة برمجة التطبيقات

يُرجى الاطّلاع على قسم تحديد المشاكل وحلّها في أخطاء lint هذه للحصول على تفاصيل حول كيفية إضافة تعليقات توضيحية إلى استخدامات Java وKotlin لواجهات برمجة التطبيقات غير المستقرة باستخدام @OptIn.

واجهات برمجة التطبيقات المتوقّفة نهائيًا

قد تلاحظ أنّ طلبات البيانات من واجهات برمجة التطبيقات المتوقّفة نهائيًا يتوسطها خط في &quot;استوديو Android&quot;. ننصحك باستبدال هذه الطلبات بالبديل المناسب. مرِّر مؤشر الماوس فوق الرمز للاطّلاع على JavaDoc الذي يوضّح واجهة برمجة التطبيقات التي يجب استخدامها بدلاً من ذلك.

لقطة شاشة: كيفية عرض JavaDoc مع بديل للطريقة المتوقّفة نهائيًا
الشكل 3: تلميح JavaDoc في "استوديو Android" يقترح بديلاً لأي رمز متوقّف نهائيًا.

عيّنات التعليمات البرمجية والتطبيقات التجريبية

  • تطبيق AndroidX Media3 التجريبي للجلسات (للأجهزة الجوّالة وأجهزة WearOS)
    • الإجراءات المخصّصة
    • إشعار من واجهة مستخدم النظام، MediaButton/BT
    • عناصر التحكّم في التشغيل من خلال "مساعد Google"
  • ‫UAMP: مشغّل وسائط Android (الفرع media3) (الأجهزة الجوّالة ونظام التشغيل AutomotiveOS)
    • إشعار واجهة مستخدم النظام، MediaButton/BT، استئناف التشغيل
    • عناصر التحكّم في التشغيل من خلال "مساعد Google" أو WearOS
    • ‫AutomotiveOS: أمر مخصّص وتسجيل الدخول