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

مثل الإصدارات السابقة، يتضمّن Android 13 تغييرات في السلوك قد تؤثر في تطبيقك. تنطبق التغييرات التالية في السلوك حصريًا على التطبيقات التي تستهدف Android 13 أو الإصدارات الأحدث. إذا كان تطبيقك يستهدف الإصدار 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 مثل ما يلي:

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

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

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

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

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

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

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

أدوات التحكّم في الوسائط مشتقة من "PlaybackState"

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

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

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

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

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

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

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

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