التغييرات في السلوك: التطبيقات التي تستهدف الإصدار 13 من نظام التشغيل Android أو الإصدارات الأحدث

مثل الإصدارات السابقة، يتضمّن الإصدار 13 من نظام التشغيل Android تغييرات في السلوك قد تؤثر في تطبيقك. تنطبق تغييرات السلوك التالية حصريًا على التطبيقات التي تستهدف الإصدار 13 من نظام التشغيل Android أو الإصدارات الأحدث. إذا كان تطبيقك يستهدف الإصدار 13 من نظام التشغيل Android أو إصدارًا أحدث، عليك تعديله للتوافق مع هذه السلوكيات بشكل صحيح حيثما ينطبق ذلك.

احرص أيضًا على مراجعة قائمة التغييرات في السلوك التي تؤثر في جميع التطبيقات التي تعمل بنظام التشغيل Android 13.

الخصوصية

تأثير إذن الإشعارات في ظهور الخدمة التي تعمل في المقدّمة

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

إذن تشغيل جديد لأجهزة Wi-Fi المجاورة

في الإصدارات السابقة من Android، على المستخدم منح تطبيقك إذن ACCESS_FINE_LOCATION لإكمال العديد من الحالات الشائعة لاستخدام Wi-Fi.

بما أنّه من الصعب على المستخدمين ربط أذونات تحديد الموقع الجغرافي بوظيفة Wi-Fi، يقدّم الإصدار 13 من نظام التشغيل Android (المستوى 33 لواجهة برمجة التطبيقات) إذنًا أثناء التشغيل في مجموعة أذونات NEARBY_DEVICES للتطبيقات التي تدير اتصالات الجهاز بنقاط اتصال مجاورة عبر Wi-Fi. يلبي هذا الإذن، NEARBY_WIFI_DEVICES، حالات استخدام شبكة Wi-Fi، مثل ما يلي:

  • يمكنك العثور على الأجهزة المجاورة أو الاتصال بها، مثل الطابعات أو أجهزة بث الوسائط. يسمح سير العمل هذا لتطبيقك بتنفيذ هذه الأنواع من المهام:
    • تلقّي معلومات AP خارج النطاق، مثل BLE.
    • يمكنك اكتشاف الأجهزة وربطها عبر خدمة Wi-Fi Aware والاتصال باستخدام نقطة اتصال محلية فقط.
    • اكتشاف الأجهزة والاتصال بها من خلال اتصال Wi-Fi المباشر
  • ابدأ الاتصال بمعرّف SSID معروف، مثل سيارة أو جهاز منزلي ذكي.
  • شغِّل نقطة اتصال للأجهزة المحلية فقط.
  • نطاق الأجهزة المجاورة التي تستخدم Wi-Fi Aware

طالما أنّ تطبيقك لا يستخرج معلومات الموقع الجغرافي من واجهات برمجة تطبيقات Wi-Fi، يمكنك طلب الإذن NEARBY_WIFI_DEVICES بدلاً من ACCESS_FINE_LOCATION عند استهداف Android 13 أو إصدار أحدث واستخدام واجهات برمجة تطبيقات Wi-Fi. عند الإفصاح عن إذن NEARBY_WIFI_DEVICES، يجب التأكيد بشدة على أنّ تطبيقك لا يستخرج أبدًا معلومات الموقع الجغرافي من واجهات برمجة تطبيقات Wi-Fi. لإجراء ذلك، اضبط السمة android:usesPermissionFlags على neverForLocation. تشبه هذه العملية الطريقة التي تستخدمها في نظام التشغيل Android 12 (المستوى 31 لواجهة برمجة التطبيقات) والإصدارات الأحدث عند التأكيد على أنّ معلومات الجهاز الذي يتضمّن بلوتوث لا تُستخدم أبدًا للموقع الجغرافي.

تعرَّف على مزيد من المعلومات حول كيفية طلب الإذن بالوصول إلى أجهزة Wi-Fi المجاورة.

أذونات الوسائط الدقيقة

الزران الخاصان بمربع الحوار، من أعلى إلى أسفل، هما "السماح" و"عدم السماح"
الشكل 1. مربّع حوار أذونات النظام الذي يظهر للمستخدم عند طلب إذن READ_MEDIA_AUDIO

إذا كان تطبيقك يستهدف الإصدار 13 من نظام التشغيل Android أو إصدارًا أحدث وكان يحتاج إلى الوصول إلى ملفات الوسائط التي أنشأتها تطبيقات أخرى، يجب طلب إذن واحد أو أكثر من أذونات الوسائط الدقيقة التالية بدلاً من إذن READ_EXTERNAL_STORAGE:

نوع الوسائط الإذن المطلوب
الصور READ_MEDIA_IMAGES
الفيديوهات READ_MEDIA_VIDEO
ملفات صوتية READ_MEDIA_AUDIO

قبل الوصول إلى ملفات وسائط تطبيق آخر، تأكَّد من أنّ المستخدم قد منح تطبيقك أذونات الوصول الدقيقة إلى الوسائط.

يعرض الشكل 1 تطبيقًا يطلب إذن READ_MEDIA_AUDIO.

إذا طلبت إذن READ_MEDIA_IMAGES وإذن READ_MEDIA_VIDEO في الوقت نفسه، سيظهر مربّع حوار واحد فقط لإذن النظام .

إذا سبق أن تم منح تطبيقك إذن READ_EXTERNAL_STORAGE ، سيتم منح أي أذونات READ_MEDIA_* المطلوبة تلقائيًا عند الترقية. يمكنك استخدام الأمر ADB التالي لمراجعة الأذونات التي تمت ترقيتها:

adb shell cmd appops get --uid PACKAGE_NAME

استخدام أجهزة استشعار الجسم في الخلفية يتطلب إذنًا جديدًا

يقدّم نظام التشغيل Android 13 مفهوم الوصول "أثناء الاستخدام" لأدوات استشعار الجسم، مثل معدّل نبضات القلب ودرجة الحرارة ونسبة الأكسجين في الدم. يشبه نموذج الوصول هذا إلى حد كبير النموذج الذي قدّمه النظام للموقع الجغرافي في Android 10 (المستوى 29 لواجهة برمجة التطبيقات).

إذا كان تطبيقك يستهدف الإصدار 13 من نظام التشغيل Android ويتطلّب الوصول إلى معلومات أجهزة استشعار الجسم أثناء تشغيله في الخلفية، يجب تقديم بيان بشأن الإذن الجديد BODY_SENSORS_BACKGROUND بالإضافة إلى الإذن الحالي BODY_SENSORS .

الأداء والبطارية

استخدام موارد البطارية

إذا وضع المستخدم تطبيقك في الحالة "محظور" لاستخدام البطارية في الخلفية بينما يستهدف تطبيقك الإصدار Android 13، لن يعرض النظام بث BOOT_COMPLETED أو بث LOCKED_BOOT_COMPLETED إلا بعد بدء تشغيل التطبيق لأسباب أخرى.

تجربة المستخدم

عناصر التحكّم في الوسائط المستمدة من PlaybackState

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

يوضح الشكل 2 مثالاً على كيف يبدو هذا على هاتف وجهاز لوحي، على التوالي.

عناصر التحكّم في الوسائط من حيث طريقة ظهورها على الهواتف والأجهزة اللوحية،
            باستخدام مثال على مقطع صوتي يعرض كيفية ظهور الأزرار
الشكل 2: عناصر التحكّم في الوسائط على الهواتف والأجهزة اللوحية

قبل نظام التشغيل Android 13، كان النظام يعرض ما يصل إلى خمسة إجراءات من MediaStyle الإشعار بالترتيب الذي تم إضافته به. في الوضع المكثّف، على سبيل المثال، في الإعدادات السريعة المصغّرة، كان يتم عرض ما يصل إلى ثلاثة إجراءات محدّدة باستخدام setShowActionsInCompactView().

بدءًا من Android 13، يعرض النظام ما يصل إلى خمسة أزرار إجراءات استنادًا إلى PlaybackState كما هو موضّح في الجدول التالي. في الوضع المكثّف، لن يتم عرض سوى أول ثلاث مَواضع إجراءات. بالنسبة إلى التطبيقات التي لا تستهدف نظام التشغيل Android 13 أو تلك التي لا تتضمّن PlaybackState، سيعرض النظام عناصر التحكّم استنادًا إلى قائمة Action التي تمت إضافتها إلى إشعار MediaStyle كما هو موضّح في الفقرة السابقة.

الشريحة الإجراء المعايير
1 تشغيل تكون الحالة الحالية للPlaybackState إحدى الحالات التالية:
  • STATE_NONE
  • STATE_STOPPED
  • STATE_PAUSED
  • STATE_ERROR
مؤشر سريان العمل تكون الحالة الحالية للPlaybackState إحدى الحالات التالية:
  • STATE_CONNECTING
  • STATE_BUFFERING
إيقاف مؤقت لا تنطبق أيّ من الحالات السابقة على الحالة الحالية لـ PlaybackState.
2 الصفحة السابقة تشمل PlaybackState الإجراءات ACTION_SKIP_TO_PREVIOUS.
قرض مخصص لا تتضمّن PlaybackState الإجراءات ACTION_SKIP_TO_PREVIOUS وPlaybackState الإجراءات المخصّصة إجراءً مخصّصًا لم يتم وضعه بعد.
فارغ PlaybackState تشمل الإضافات قيمة منطقية true للمفتاح SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV.
3 التالي تشمل PlaybackState الإجراءات ACTION_SKIP_TO_NEXT.
قرض مخصص لا تتضمّن PlaybackState الإجراءات ACTION_SKIP_TO_NEXT وPlaybackState الإجراءات المخصّصة إجراءً مخصّصًا لم يتم وضعه بعد.
فارغ PlaybackState تشمل الإضافات قيمة منطقية true للمفتاح SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT.
4 قرض مخصص PlaybackState تتضمّن الإجراءات المخصّصة إجراءً مخصّصًا لم يتم وضعه بعد.
5 قرض مخصص تتضمّن الإجراءات المخصّصة في PlaybackState إجراءً مخصّصًا لم يتم وضعه بعد.

يتم ترتيب الإجراءات المخصّصة بترتيب إضافتها إلى PlaybackState.

تطبيق مظهر ألوان التطبيق تلقائيًا على محتوى WebView

بالنسبة إلى التطبيقات التي تستهدف الإصدار 13 من نظام التشغيل Android (المستوى 33 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث، تم إيقاف الطريقة setForceDark() نهائيًا، ما يؤدي إلى عدم التنفيذ في حال طلب الطريقة.

وبدلاً من ذلك، يضبط WebView الآن دائمًا طلب البحث عن الوسائط prefers-color-scheme وفقًا لسمة مظهر التطبيق، isLightTheme. بعبارة أخرى، إذا كانت قيمة isLightTheme هي true أو لم يتم تحديدها، تكون قيمة prefers-color-scheme هي light، وإلا ستكون dark. ويعني هذا السلوك أنّه يتم تطبيق أسلوب المحتوى على الويب الفاتح أو الداكن تلقائيًا لمطابقة مظهر التطبيق إذا كان المحتوى يتيح ذلك.

بالنسبة إلى معظم التطبيقات، من المفترض أن يتم تطبيق أنماط التطبيق المناسبة تلقائيًا، ولكن يجب اختبار تطبيقك للتحقق من أي حالات ربما كنت تتحكم فيها يدويًا في إعدادات الوضع الداكن.

إذا كنت لا تزال بحاجة إلى تخصيص سلوك مظهر الألوان في تطبيقك، استخدِم الأسلوب setAlgorithmicDarkeningAllowed() بدلاً من ذلك. لضمان التوافق مع الإصدارات السابقة من Android، ننصحك باستخدام الأسلوب المكافئ setAlgorithmicDarkeningAllowed() في AndroidX.

يمكنك الاطّلاع على المستندات المتعلّقة بتلك الطريقة للتعرّف على مزيد من المعلومات حول السلوك الذي يمكن توقّعه في تطبيقك استنادًا إلى إعدادات targetSdkVersion والمظهر في تطبيقك.

إمكانية الاتصال

الإيقاف النهائي لوظيفتَي BluetoothAdapter#enable() وBluetoothAdapter#disable()

بالنسبة إلى التطبيقات التي تستهدف الإصدار 13 من نظام التشغيل Android (المستوى 33 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث، تم إيقاف الطريقتَين BluetoothAdapter#enable() و BluetoothAdapter#disable() نهائيًا، وهما دائمًا تُعرِض القيمة false.

يتم استثناء الأنواع التالية من التطبيقات من هذه التغييرات:

  • تطبيقات مالك الجهاز
  • تطبيقات مالك الملف التجاري
  • تطبيقات النظام

خدمات Google Play

إذن مطلوب للمعرِّف الإعلاني

في التطبيقات التي تستخدم المعرِّف الإعلاني من "خدمات Google Play" والتي تستهدف الإصدار 13 من نظام التشغيل Android (المستوى 33 لواجهة برمجة التطبيقات) والإصدارات الأحدث، يجب تقديم بيان عن الإذن العادي AD_ID فيملف بيان التطبيق، على النحو التالي:

<manifest ...>
    <!-- Required only if your app targets Android 13 or higher. -->
    <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

    <application ...>
        ...
    </application>
</manifest>

إذا لم يقدّم تطبيقك بيانًا لهذا الإذن عند استهداف الإصدار 13 من Android أو إصدار أحدث، ستتم تلقائيًا إزالة المعرِّف الإعلاني واستبداله بسلسلة من الأصفار.

إذا كان تطبيقك يستخدم حِزم SDK تعلن عن إذن AD_ID في ملف بيان المكتبة، سيتم دمج الإذن تلقائيًا مع ملف بيان تطبيقك. في هذه الحالة، لا تحتاج إلى الإفصاح عن الإذن فيملف بيان تطبيقك.

لمزيد من المعلومات، يُرجى الاطّلاع على المعرِّف الإعلاني في مركز مساعدة Play Console.

قيود غير متاحة في حزمة SDK تم تعديلها

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

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

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

لمعرفة المزيد من المعلومات عن التغييرات في هذا الإصدار من Android، يمكنك الاطّلاع على تعديلات على القيود المفروضة على الواجهة غير المستندة إلى حزمة تطوير البرامج (SDK) في Android 13. للاطّلاع على مزيد من المعلومات حول الواجهات غير المتوفّرة في حزمة SDK بشكل عام، اطّلِع على القيود المفروضة على الوجهات غير المتوفّرة في حزمة SDK.