يجب نقل التطبيقات التي تستخدم حاليًا مكتبة 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
. - متوافقة مع الأنظمة القديمة مع واجهات برمجة التطبيقات للعميل المتوافق مع الوسائط
(
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
.
المتطلّبات الأساسية
التأكّد من أنّ مشروعك يخضع للتحكّم في المصدر
تأكَّد من إمكانية التراجع بسهولة عن التغييرات التي تم تطبيقها من خلال أدوات نقل البيانات المستندة إلى النصوص البرمجية. إذا لم يكن مشروعك خاضعًا للتحكم في المصدر حتى الآن، فهذا هو الوقت المناسب لبدء استخدامه. إذا كنت لا تريد القيام بذلك لسبب ما، فقم بعمل نسخة احتياطية من مشروعك قبل البدء في الترحيل.
تحديث التطبيق
ننصحك بتحديث مشروعك لاستخدام أحدث إصدار من مكتبة ExoPlayer وإزالة أي طلبات بحث عن الطرق المتوقّفة نهائيًا. وإذا كنت تنوي استخدام النص البرمجي لإجراء عملية النقل، عليك مطابقة الإصدار الذي يتم تحديثه مع الإصدار الذي يعالجه النص البرمجي.
عليك زيادة إصدار compileSdkVersion من تطبيقك إلى 32 على الأقل.
ترقية Gradle ومكوّن Gradle الإضافي Android Studio إلى إصدار حديث يتوافق مع التبعيات المحدَّثة الواردة أعلاه. على سبيل المثال:
- إصدار المكوّن الإضافي لنظام 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
استخدام النص البرمجي للنقل
نزِّل النص البرمجي لنقل البيانات من علامة مشروع ExoPlayer على GitHub المقابل للإصدار الذي حدّثت تطبيقك إليه:
curl -o media3-migration.sh \ "https://raw.githubusercontent.com/google/ExoPlayer/r2.19.1/media3-migration.sh"
جعل النص البرمجي قابلاً للتنفيذ:
chmod 744 media3-migration.sh
شغِّل النص البرمجي باستخدام
--help
للتعرّف على الخيارات.شغِّل النص البرمجي باستخدام
-l
لسرد مجموعة الملفات المحدَّدة لعملية نقل البيانات (استخدِم-f
لفرض بطاقة البيانات بدون تحذيرات):./media3-migration.sh -l -f /path/to/gradle/project/root
شغِّل النص البرمجي باستخدام
-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
:
- التحقّق من كيفية تغيير النص البرمجي للرمز البرمجي: استخدِم أداة مختلفة وأصلِح المشاكل المحتملة (يمكنك تقديم خطأ إذا كنت تعتقد أنّ النص البرمجي يواجه مشكلة عامة حدثت بدون تمرير الخيار
-f
). - إنشاء المشروع: يمكنك إمّا استخدام
./gradlew clean build
أو في "استوديو Android" اختيار ملف > مزامنة المشروع مع ملفات Gradle، ثم إنشاء > حذف المشروع، ثم إنشاء > إعادة إنشاء المشروع (يمكنك تتبُّع التصميم في علامة التبويب "إنشاء - نتيجة الإصدار" في "استوديو Android".)
خطوات المتابعة المقترَحة:
- عليك حلّ الموافقة على الأخطاء المتعلّقة باستخدام واجهات برمجة التطبيقات غير الثابتة.
- استبدال طلبات البيانات من واجهة برمجة التطبيقات المتوقّفة نهائيًا: استخدِم واجهة برمجة التطبيقات البديلة المقترَحة. ضع مؤشّر الماوس فوق التحذير في "استوديو Android" وراجِع رمز JavaDoc للرمز الذي تم إيقافه لمعرفة ما يجب استخدامه بدلاً من استدعاء معيّن.
- ترتيب عبارات الاستيراد: افتح المشروع في "استوديو Android"، ثم انقر بزر الماوس الأيمن على عقدة مجلد الحزمة في عارض المشروع واختَر تحسين عمليات الاستيراد في الحِزم التي تحتوي على ملفات المصدر التي تم تغييرها.
استبدال MediaSessionConnector
بـ androidx.media3.session.MediaSession
في عالم MediaSessionCompat
القديم، كان MediaSessionConnector
مسؤولًا عن مزامنة حالة المشغّل مع حالة الجلسة واستلام الأوامر من وحدات التحكم التي تتطلب تفويضًا لأساليب اللاعبين المناسبة. باستخدام AndroidX Media3، يتم إجراء ذلك من خلال MediaSession
مباشرةً بدون الحاجة إلى موصِّل.
إزالة كل المراجع واستخدام MediaSessionConnector: إذا استخدمت النص البرمجي المبرمَج لنقل فئات وحِزم ExoPlayer، من المحتمل أن يكون النص البرمجي قد ترك الرمز في حالة غير قابلة للتجميع بشأن
MediaSessionConnector
الذي لا يمكن حلّه. سيعرض لك "استوديو Android" التعليمات البرمجية المعطلة عند محاولة إنشاء تطبيق أو تشغيله.في ملف
build.gradle
الذي تحتفظ فيه بتبعياتك، أضِف تبعية للتنفيذ إلى وحدة جلسة AndroidX Media3 وأزِل التبعية القديمة:implementation "androidx.media3:media3-session:1.3.1"
استبدِل
MediaSessionCompat
بـandroidx.media3.session.MediaSession
.في الموقع الإلكتروني الخاص بالرموز البرمجية حيث أنشأت
MediaSessionCompat
القديمة، استخدِمandroidx.media3.session.MediaSession.Builder
من أجل إنشاءMediaSession
. مرِّر المشغّل لإنشاء أداة إنشاء الجلسات.val player = ExoPlayer.Builder(context).build() mediaSession = MediaSession.Builder(context, player) .setSessionCallback(MySessionCallback()) .build()
نفِّذ
MySessionCallback
حسب ما يتطلبه تطبيقك، وهذا إجراء اختياري. إذا كنت تريد السماح لوحدات التحكّم بإضافة عناصر وسائط إلى المشغّل، عليك تنفيذMediaSession.Callback.onAddMediaItems()
. وهو يوفّر طرق واجهة برمجة تطبيقات مختلفة حالية وقديمة تضيف عناصر إلى المشغّل لتشغيلها بطريقة متوافقة مع الأنظمة القديمة. يشمل ذلك طرقMediaController.set/addMediaItems()
لوحدة التحكّم في Media3، بالإضافة إلى طرقTransportControls.prepareFrom*/playFrom*
لواجهة برمجة التطبيقات القديمة. يمكن العثور على نموذج لتنفيذ السمةonAddMediaItems
فيPlaybackService
من التطبيق التجريبي للجلسة.حرر جلسة الوسائط في موقع التعليمة البرمجية حيث دمّرت جلستك قبل عملية الترحيل:
mediaSession?.run { player.release() release() mediaSession = null }
وظيفة MediaSessionConnector
في Media3
يعرض الجدول التالي واجهات برمجة تطبيقات Media3 التي تعالج وظائف تم تنفيذها سابقًا في MediaSessionConnector
.
MediaSessionConnector | AndroidX Media3 |
---|---|
CustomActionProvider |
MediaSession.Callback.onCustomCommand()/
MediaSession.setCustomLayout() |
PlaybackPreparer |
MediaSession.Callback.onAddMediaItems()
(تتم تسمية prepare() داخليًا)
|
QueueNavigator |
ForwardingPlayer |
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
قديمة.
لكي يعمل التوافق مع الأنظمة القديمة، عليك تسجيل واجهتَي الخدمة من خلال خدمتك في
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>
في ملف
build.gradle
الذي تحتفظ فيه بتبعياتك، أضِف تبعية للتنفيذ إلى وحدة جلسة AndroidX Media3 وأزِل التبعية القديمة:implementation "androidx.media3:media3-session:1.3.1"
تغيير خدمتك لتكتسب من
MediaLibraryService
بدلاً منMediaBrowserService
كما ذكرنا سابقًا، تتوافق خدمةMediaLibraryService
مع الإصدار القديمMediaBrowserService
. ووفقًا لذلك، لا تزال واجهة برمجة التطبيقات الأوسع التي تقدمها الخدمة للعملاء كما هي. لذا، من المرجّح أن يحتفظ التطبيق بمعظم المنطق المطلوب لتنفيذMediaBrowserService
وتكييفه معMediaLibraryService
الجديد.في ما يلي الاختلافات الرئيسية مقارنةً بإصدار
MediaBrowserServiceCompat
القديم:تنفيذ طُرق دورة حياة الخدمة: الطرق التي يجب إلغاءها على الخدمة نفسها هي
onCreate/onDestroy
، حيث يخصّص/يخصص التطبيق جلسة المكتبة والمشغّل والموارد الأخرى. بالإضافة إلى الطُرق العادية لدورة حياة الخدمة، يحتاج التطبيق إلى إلغاء السمةonGetSession(MediaSession.ControllerInfo)
لعرض عنصرMediaLibrarySession
الذي تم إنشاؤه فيonCreate
.تنفيذ MediaLibraryService.MediaLibrarySessionCallback: يتطلب إنشاء جلسة
MediaLibraryService.MediaLibrarySessionCallback
تنفيذ أساليب واجهة برمجة التطبيقات للنطاق الفعلية. لذا بدلاً من إلغاء طرق واجهة برمجة التطبيقات للخدمة القديمة، سيتم إلغاء طرقMediaLibrarySession.Callback
بدلاً من ذلك.يتم بعد ذلك استخدام معاودة الاتصال لإنشاء
MediaLibrarySession
:mediaLibrarySession = MediaLibrarySession.Builder(this, player, 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
غير متزامن بدلاً من فصل نتيجة أو عرض مستقبل فوري لعرض قيمة مباشرةً.
إزالة 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::class.java)
browser =
MediaBrowser.Builder(context, sessionToken))
.setListener(BrowserListener())
.buildAsync()
.await()
// Get the library root to start browsing the library.
root = browser.getLibraryRoot(/* params= */ null).await();
// Add a MediaController.Listener to listen to player state events.
browser.addListener(playerListener)
playerView.setPlayer(browser)
}
ألقِ نظرة على مقالة
التحكّم في التشغيل في جلسة تشغيل الوسائط
للتعرّف على كيفية إنشاء MediaController
للتحكم في التشغيل في
الخلفية.
مزيد من الخطوات وإخلاء مساحة
أخطاء غير مستقرة في واجهة برمجة التطبيقات
بعد الانتقال إلى Media3، قد تظهر لك أخطاء غير مرغوب فيها بشأن الاستخدامات غير الثابتة لواجهة برمجة التطبيقات.
إنّ واجهات برمجة التطبيقات هذه آمنة للاستخدام، وتمثّل أخطاء الوبر منتج ثانوي ضمن ضمانات التوافق الثنائي الجديدة. إذا لم يكن لديك توافق ثنائي
صارم، يمكن منع هذه الأخطاء بأمان باستخدام التعليق التوضيحي @OptIn
.
خلفية
لم يقدّم أي من الإصدار 1 أو الإصدار 2 من ExoPlayer ضمانات صارمة بشأن التوافق الثنائي للمكتبة بين الإصدارات اللاحقة. يتّسم سطح واجهة برمجة تطبيقات ExoPlayer بأنّه كبير جدًا من حيث التصميم، ما يتيح للتطبيقات تخصيص كل جانب من جوانب التشغيل تقريبًا. قد تتضمن الإصدارات اللاحقة من ExoPlayer أحيانًا عمليات إعادة تسمية للرموز أو تغييرات قد تؤدي إلى أعطال أخرى (مثل إضافة طرق جديدة مطلوبة على الواجهات). في معظم الحالات، تم الحدّ من هذه الأعطال من خلال تقديم الرمز الجديد إلى جانب إيقاف الرمز القديم لبعض الإصدارات، ما يمنح المطوّرين وقتًا لنقل بيانات استخدامهم، لكن هذا لم يكن ممكنًا دائمًا.
وأدّت هذه التغييرات التي قد تؤدي إلى تعطُّل إلى حدوث مشكلتين لمستخدمي الإصدارَين 1 و2 من ExoPlayer:
- قد تؤدي الترقية من إصدار ExoPlayer إلى إيقاف تجميع الرموز البرمجية.
- إذا كان التطبيق الذي كان يعتمد على ExoPlayer بشكل مباشر أو من خلال مكتبة وسيطة، كان يجب أن يضمن أن كلتا التبعية كانتا من نفس الإصدار، وإلا فقد تؤدي حالات عدم التوافق الثنائي إلى أعطال في وقت التشغيل.
التحسينات في Media3
تضمن Media3 التوافق الثنائي لمجموعة فرعية من مساحة عرض واجهة برمجة التطبيقات. يتم تمييز الأجزاء التي لا تضمن التوافق الثنائي باستخدام @UnstableApi
. لتوضيح هذا التمييز، ينشأ عن استخدام رموز واجهة برمجة التطبيقات غير المستقرة خطأ غير مرغوب فيه ما لم تتم إضافة تعليقات توضيحية إليه باستخدام @OptIn
.
بعد نقل البيانات من الإصدار الثاني ExoPlayer إلى Media3، قد يظهر لك الكثير من الأخطاء غير الثابتة في واجهة برمجة التطبيقات. قد يجعل هذا الأمر يبدو وكأن Media3 "أقل ثباتًا" من الإصدار 2 من ExoPlayer. ولكن الأمر ليس كذلك. تتمتع الأجزاء "غير الثابتة" من واجهة برمجة التطبيقات Media3 API بالمستوى نفسه من الثبات مثل كامل سطح واجهة برمجة التطبيقات ExoPlayer v2، ولا تتوفر ضمانات السطح الثابت لـ Media3 API في الإصدار 2 من ExoPlayer على الإطلاق. الفرق هو ببساطة أن خطأ الوبر ينبهك الآن إلى المستويات المختلفة للثبات.
معالجة أخطاء البرامج غير الثابتة في واجهة برمجة التطبيقات
لديك خياران لمعالجة أخطاء البرامج غير الثابتة لواجهة برمجة التطبيقات:
- يمكنك التبديل إلى استخدام واجهة برمجة تطبيقات مستقرة تحقق النتيجة نفسها.
يمكنك مواصلة استخدام واجهة برمجة التطبيقات غير الثابتة وإضافة تعليقات توضيحية إلى الاستخدام باستخدام
@OptIn
.import androidx.annotation.OptIn import androidx.media3.common.util.UnstableApi @OptIn(UnstableApi::class) fun functionUsingUnstableApi() { // Do something useful. }
يُرجى العِلم أنّ هناك أيضًا تعليق توضيحي
kotlin.OptIn
يجب عدم استخدامه. من المهم الالتزام بالتعليق التوضيحيandroidx.annotation.OptIn
لهذا الغرض.
يمكن تفعيل كلّ الحِزم من خلال إضافة package-info.java
:
@OptIn(markerClass = UnstableApi.class)
package name.of.your.package;
import androidx.annotation.OptIn;
import androidx.media3.common.util.UnstableApi;
يمكن الموافقة على المشاريع بأكملها من خلال منع خطأ الوبر المحدد في ملف lint.xml الخاص بها. راجِع JavaDoc للتعليق التوضيحي UnstableApi للحصول على مزيد من التفاصيل.
واجهات برمجة التطبيقات التي تم إيقافها نهائيًا
قد تلاحظ أنّ طلبات البيانات من واجهات برمجة التطبيقات المتوقّفة تظهر في "استوديو Android". ونحن ننصح باستبدال هذه الطلبات بالبديل المناسب. مرِّر مؤشر الماوس فوق الرمز لعرض مستند JavaDoc الذي يحدِّد واجهة برمجة التطبيقات التي يجب استخدامها بدلاً من ذلك.
عيّنات التعليمات البرمجية والتطبيقات التجريبية
- تطبيق العرض التوضيحي لجلسة AndroidX Media3 (للأجهزة الجوّالة وWearOS)
- الإجراءات المخصّصة
- إشعار واجهة مستخدم النظام، MediaButton/BT
- التحكّم في تشغيل "مساعد Google"
- UAMP: Android Media Player (branch media3) (الأجهزة الجوّالة و AutomotiveOS)
- إشعار واجهة مستخدم النظام، MediaButton/BT، استئناف التشغيل
- التحكّم في تشغيل الأجهزة من خلال "مساعد Google" أو WearOS
- AutomotiveOS: طلب مخصّص وتسجيل الدخول