دليل نقل البيانات إلى 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 في "استوديو 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 في Media3 من AndroidX.

نقل بيانات ExoPlayer مع إمكانية استخدام النصوص البرمجية

يسهّل النص البرمجي الانتقال من com.google.android.exoplayer2 إلى بنية الحزمة والوحدة الجديدة ضمن androidx.media3. يطبّق النص البرمجي بعض عمليات التحقّق من الصحة على مشروعك ويعرض تحذيرات في حال تعذّر التحقّق من الصحة. بخلاف ذلك، يتم تطبيق عمليات الربط بين الفئات والحِزم التي تمت إعادة تسميتها في موارد مشروع Android gradle مكتوب بلغة 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. التحقّق من طريقة تغيير النص البرمجي لرمزك: استخدِم أداة مقارنة وأصلِح المشاكل المحتملة (يمكنك الإبلاغ عن خطأ إذا كنت تعتقد أنّ النص البرمجي يتضمّن مشكلة عامة تم إدخالها بدون تمرير الخيار -f).
2. إنشاء المشروع: استخدِم ./gradlew clean build أو انتقِل في "استوديو Android" إلى ملف > مزامنة المشروع مع ملفات Gradle، ثم إنشاء > تنظيف المشروع، ثم إنشاء > إعادة إنشاء المشروع (يمكنك تتبُّع عملية الإنشاء في علامة التبويب "إنشاء - ناتج الإنشاء" في "استوديو Android").

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

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

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

في الإصدار القديم من MediaSessionCompat، كان MediaSessionConnector مسؤولاً عن مزامنة حالة اللاعب مع حالة الجلسة وتلقّي الأوامر من وحدات التحكّم التي تحتاج إلى تفويض إلى طرق اللاعب المناسبة. باستخدام AndroidX Media3، يتم ذلك من خلال MediaSession مباشرةً بدون الحاجة إلى موصّل.

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

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

   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()
   MigrationGuide.kt

   Java

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

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

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

   Kotlin

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

   Java

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

وظيفة MediaSessionConnector في Media3

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

نقل MediaBrowserService إلى MediaLibraryService

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

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

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 الذي تحتفظ فيه بالاعتماديات، أضِف اعتمادية التنفيذ إلى وحدة جلسة Media3 في AndroidX وأزِل الاعتمادية القديمة:

   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()
     MigrationGuide.kt

     Java

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

     يمكنك العثور على واجهة برمجة التطبيقات الكاملة الخاصة بـ 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. يجب تغيير أجزاء الرمز المرتبط بالفئات القديمة وفقًا لذلك أو ربطها بـ Media3 MediaItem بدلاً من ذلك.

   • تم تغيير نموذج البرمجة غير المتزامنة العام إلى 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 والانتظار إلى أن يتم إنشاء الاتصال بالخدمة:

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

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

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

الخطوات الإضافية وعملية التنظيف

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

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

خلفية

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

أدت هذه التغييرات غير المتوافقة إلى حدوث مشكلتين لمستخدمي مكتبتَي ExoPlayer الإصدار 1 والإصدار 2:

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

تحسينات في Media3

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

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

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

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

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

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

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

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