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

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

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

الخصوصية

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

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

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

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

بسبب أنّه من الصعب على المستخدمين ربط أذونات تحديد الموقع الجغرافي بوظائف Wi-Fi، يقدّم نظام Android 13 (المستوى 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 عند استهداف الإصدار 13 من نظام التشغيل Android أو إصدار أحدث واستخدام واجهات برمجة تطبيقات 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 من واجهة برمجة التطبيقات).

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

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

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

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

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

عناصر التحكّم في الوسائط تم اشتقاقها من PlaybackState.

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

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

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

قبل الإصدار 13 من نظام التشغيل Android، كان النظام يعرض ما يصل إلى خمسة إجراءات من إشعار 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() نهائيًا.

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

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