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

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

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

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

الإشعارات المُخصَّصة

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

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

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

يعرض الرسم التوضيحي التالي إشعارًا مخصّصًا في النموذج العادي:

توضّح الأمثلة التالية كيف سيتم عرض الإشعارات المخصّصة في الحالة المصغّرة والموسّعة:

يؤثّر التغيير في الإصدار 12 من نظام التشغيل Android في التطبيقات التي تحدّد فئات فرعية مخصّصة من Notification.Style أو التي تستخدم طرق Notification.Builder setCustomContentView(RemoteViews) وsetCustomBigContentView(RemoteViews) وsetCustomHeadsUpContentView(RemoteViews).

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

  1. فعِّل خيار تغيير الإشعارات المخصّصة:

    1. غيِّر قيمة targetSdkVersion في تطبيقك إلى S لتفعيل السلوك الجديد.
    2. إعادة التجميع
    3. ثبِّت تطبيقك على جهاز أو محاكي يعمل بالإصدار 12 من نظام التشغيل Android.

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

    • تغيّرت أبعاد العروض المخصّصة. بشكل عام، يكون ارتفاع الإشعارات المخصّصة أقل من السابق. في الحالة المصغّرة، انخفض الحد الأقصى لارتفاع المحتوى المخصّص من 106 بكسل مستقل الكثافة إلى 48 بكسل مستقل الكثافة. بالإضافة إلى ذلك، تتوفّر مساحة أفقية أقل.

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

    • للتأكّد من أنّ حالة "تنبيه" تبدو كما تتوقّع، لا تنسَ رفع مستوى أهمية قناة الإشعارات إلى "عالية" (تظهر على الشاشة).

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

إذا كنت تعتمد على عملية التحقّق من روابط التطبيقات على Android لفتح روابط الويب في تطبيقك، تأكَّد من استخدام التنسيق الصحيح عند إضافة فلاتر intent لإجراء عملية التحقّق من روابط التطبيقات على Android. على وجه الخصوص، تأكَّد من أنّ فلاتر الأهداف هذه تتضمّن الفئة BROWSABLE وتتوافق مع المخطط https.

يمكنك أيضًا التحقّق يدويًا من الروابط في تطبيقك لاختبار مدى صحة البيانات التي تقدّمها.

تحسينات على سلوك ميزة "نافذة ضمن النافذة"

يقدّم نظام التشغيل Android 12 تحسينات على سلوك وضع "نافذة ضمن النافذة" (PiP)، كما يقدّم تحسينات شكلية مقترَحة على رسوم الانتقال المتحركة لكل من التنقّل المستند إلى الإيماءات والتنقّل المستند إلى العناصر.

يمكنك الاطّلاع على تحسينات على ميزة "نافذة ضمن النافذة" للحصول على مزيد من المعلومات.

إعادة تصميم الإشعارات المنبثقة

في Android 12، تمت إعادة تصميم طريقة عرض الإشعارات المنبثقة. أصبح عدد أسطر النص في الإشعارات المؤقتة محصورًا بسطرَين، كما يظهر رمز التطبيق بجانب النص.

صورة لجهاز Android يعرض نافذة منبثقة صغيرة مكتوبًا فيها "جارٍ إرسال الرسالة" بجانب رمز تطبيق

يمكنك الاطّلاع على نظرة عامة على الإشعارات المنبثقة لمزيد من التفاصيل.

الأمان والخصوصية

الموقع الجغرافي التقريبي

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

ملفات تعريف ارتباط SameSite الحديثة في WebView

يستند مكوّن WebView في Android إلى Chromium، وهو مشروع مفتوح المصدر يتيح تشغيل متصفّح Chrome من Google. أدخل Chromium تغييرات على طريقة التعامل مع ملفات تعريف الارتباط التابعة لجهات خارجية بهدف توفير المزيد من الأمان والخصوصية ومنح المستخدمين المزيد من الشفافية والتحكّم. بدءًا من Android 12، يتم تضمين هذه التغييرات أيضًا في WebView عندما تستهدف التطبيقات الإصدار 12 من نظام التشغيل Android (المستوى 31 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث.

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

  • ويتم التعامل مع ملفات تعريف الارتباط التي لا تحتوي على السمة SameSite على أنّها SameSite=Lax.
  • يجب أن تحدّد ملفات تعريف الارتباط التي تتضمّن SameSite=None السمة Secure أيضًا، ما يعني أنّها تتطلّب سياقًا آمنًا ويجب إرسالها عبر HTTPS.
  • تُعامل الروابط بين إصدارَي HTTP وHTTPS من أحد المواقع الإلكترونية الآن على أنّها طلبات من مواقع إلكترونية متعددة، وبالتالي لا يتم إرسال ملفات تعريف الارتباط إلا إذا تم وضع علامة SameSite=None; Secure عليها بشكل مناسب.

بالنسبة إلى المطوّرين، تتمثّل الإرشادات العامة في تحديد التبعيات الخاصة بملفات تعريف الارتباط على مستوى المواقع الإلكترونية في مسارات المستخدمين المهمة والتأكّد من ضبط السمة SameSite بشكلٍ صريح باستخدام القيم المناسبة عند الحاجة. يجب أن تحدّد بشكل صريح ملفات تعريف الارتباط المسموح لها بالعمل على المواقع الإلكترونية أو عمليات التنقّل على الموقع الإلكتروني نفسه التي تنتقل من HTTP إلى HTTPS.

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

اختبار سلوكيات SameSite في تطبيقك

إذا كان تطبيقك يستخدم WebView، أو إذا كنت تدير موقعًا إلكترونيًا أو خدمة تستخدم ملفات تعريف الارتباط، ننصحك باختبار مساراتك على WebView في نظام التشغيل Android 12. في حال رصد مشاكل، قد تحتاج إلى تعديل ملفات تعريف الارتباط لتتوافق مع السلوكيات الجديدة لسمة SameSite.

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

لاختبار تطبيق باستخدام WebView، عليك تفعيل سلوكيات SameSite الجديدة للتطبيق الذي تريد اختباره من خلال إكمال أيّ من الخطوتَين التاليتَين:

  • فعِّل يدويًا سلوكيات SameSite على جهاز الاختبار من خلال تبديل علامة واجهة المستخدم webview-enable-modern-cookie-same-site في أدوات مطوّري WebView.

    يتيح لك هذا الأسلوب إجراء الاختبار على أي جهاز يعمل بالإصدار 5.0 (المستوى 21 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث من نظام التشغيل Android، بما في ذلك الإصدار 12، والإصدار 89.0.4385.0 أو الإصدارات الأحدث من WebView.

  • يجب تجميع تطبيقك لاستهداف الإصدار 12 من نظام التشغيل Android (المستوى 31 لواجهة برمجة التطبيقات) بحلول targetSdkVersion.

    إذا اخترت هذا الأسلوب، يجب استخدام جهاز يعمل بنظام التشغيل Android 12.

للحصول على معلومات حول تصحيح الأخطاء عن بُعد في WebView على Android، يُرجى الاطّلاع على البدء في تصحيح الأخطاء عن بُعد في أجهزة Android.

مراجع أخرى

لمزيد من المعلومات حول السلوكيات الحديثة لـ SameSite وطرحها في Chrome وWebView، يُرجى الانتقال إلى صفحة "تحديثات SameSite" في Chromium. إذا عثرت على خطأ في WebView أو Chromium، يمكنك الإبلاغ عنه في أداة تتبُّع المشاكل العامة في Chromium.

تم وضع حدّ أقصى لعدد مرات استخدام مستشعرات الحركة

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

مزيد من المعلومات حول الحدّ من معدّل استخدام المستشعر

إسبات التطبيق

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

يمكنك الاطّلاع على مزيد من المعلومات في الدليل حول وضع التطبيقات في وضع السكون.

بيان تحديد المصدر في التدقيق في الوصول إلى البيانات

تتيح لك واجهة برمجة التطبيقات لتدقيق الوصول إلى البيانات، التي تم طرحها في نظام التشغيل Android 11 (المستوى 30 لواجهة برمجة التطبيقات)، إمكانية إنشاء علامات تحديد المصدر استنادًا إلى حالات استخدام تطبيقك. تسهّل عليك هذه العلامات تحديد الجزء من تطبيقك الذي ينفّذ نوعًا معيّنًا من عمليات الوصول إلى البيانات.

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

قيود النسخ الاحتياطي باستخدام أداة ADB

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

إذا كانت عمليات الاختبار أو التطوير تعتمد على بيانات التطبيق باستخدام adb backup، يمكنك الآن الموافقة على تصدير بيانات تطبيقك من خلال ضبط android:debuggable على true في ملف البيان الخاص بتطبيقك.

تصدير المكوّنات بشكل أكثر أمانًا

إذا كان تطبيقك يستهدف الإصدار 12 من نظام التشغيل Android أو الإصدارات الأحدث ويتضمّن أنشطة أو خدمات أو أدوات استقبال البث تستخدم فلاتر intent، عليك توضيح قيمة السمة android:exported لهذه المكوّنات في التطبيق.

إذا كان مكوّن التطبيق يتضمّن الفئة LAUNCHER، اضبط android:exported على true. في معظم الحالات الأخرى، اضبط السمة android:exported على false.

يوضّح مقتطف الرمز التالي مثالاً على خدمة تحتوي على فلتر intent تم ضبط السمة android:exported الخاصة به على false:

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

الرسائل في "استوديو Android"

إذا كان تطبيقك يتضمّن نشاطًا أو خدمة أو مستقبِل بث يستخدم فلاتر الأهداف ولكنّه لا يصرّح عن android:exported، ستظهر رسائل التحذير التالية، وذلك حسب إصدار Android Studio الذي تستخدمه:

الإصدار 2020.3.1 Canary 11 أو الإصدارات الأحدث من "استوديو Android"

تظهر الرسائل التالية:

  1. يظهر تحذير lint التالي في ملف البيان:

    When using intent filters, please specify android:exported as well

  2. عند محاولة تجميع تطبيقك، ستظهر رسالة خطأ الإنشاء التالية:

    Manifest merger failed : Apps targeting Android 12 and higher are required \
to specify an explicit value for android:exported when the corresponding \
component has an intent filter defined.
الإصدارات القديمة من "استوديو Android"

إذا حاولت تثبيت التطبيق، ستعرض أداة Logcat رسالة الخطأ التالية:

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

قابلية تغيير رموز PendingIntent

إذا كان تطبيقك يستهدف الإصدار 12 من نظام التشغيل Android، عليك تحديد قابلية التغيّر لكل عنصر PendingIntent ينشئه تطبيقك. يساهم هذا الشرط الإضافي في تحسين أمان تطبيقك.

اختبار تغيير قابلية التغيير في PendingIntent

لتحديد ما إذا كان تطبيقك يفتقد إلى بيانات حول قابلية التغيّر، ابحث عن تحذير lint التالي في Android Studio:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

عمليات إطلاق غير آمنة لكائن intent

لتحسين أمان النظام الأساسي، يوفّر نظام التشغيل Android 12 والإصدارات الأحدث ميزة تصحيح الأخطاء التي ترصد عمليات إطلاق غير آمنة للأهداف. عندما يرصد النظام عملية تشغيل غير آمنة من هذا النوع، يحدث انتهاك StrictMode.

الأداء

قيود على تشغيل الخدمات التي تعمل في المقدّمة

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

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

إذن استخدام المنبّهات المحدَّدة الوقت

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

للحصول على إذن الوصول الخاص هذا، يجب طلب الإذن SCHEDULE_EXACT_ALARM في ملف البيان.

يجب استخدام المنبّهات الدقيقة فقط للميزات التي تتفاعل مع المستخدم. مزيد من المعلومات حول حالات الاستخدام المقبولة لضبط منبّه دقيق

إيقاف التغيير في السلوك

أثناء إعداد تطبيقك لاستهداف الإصدار Android 12، يمكنك إيقاف التغيير في السلوك مؤقتًا في نوع الإصدار القابل للتصحيح لأغراض الاختبار. لإجراء ذلك، أكمِل إحدى المهمتَين التاليتَين:

  • في شاشة إعدادات خيارات المطوّرين، انقر على تغييرات توافق التطبيقات. على الشاشة التي تظهر، انقر على اسم تطبيقك، ثم أوقِف REQUIRE_EXACT_ALARM_PERMISSION.

  • في نافذة الوحدة الطرفية على جهاز التطوير، نفِّذ الأمر التالي:

    adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME

قيود التوجيه غير المباشر للإشعارات

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

لتحسين أداء التطبيقات وتجربة المستخدم، لا يمكن للتطبيقات التي تستهدف الإصدار 12 من نظام التشغيل Android أو الإصدارات الأحدث بدء الأنشطة من الخدمات أو مستقبلات البث التي يتم استخدامها كمنصات إطلاق للإشعارات. بعبارة أخرى، بعد أن ينقر المستخدم على إشعار أو على زر إجراء داخل الإشعار، لا يمكن لتطبيقك استدعاء startActivity() داخل خدمة أو أداة استقبال بث.

عندما يحاول تطبيقك بدء نشاط من خدمة أو أداة استقبال بث تعمل كمنصة إطلاق للإشعارات، يمنع النظام بدء النشاط، وتظهر الرسالة التالية في Logcat:

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

تحديد مكوّنات التطبيق التي تعمل كمنصات لإطلاق الإشعارات

عند اختبار تطبيقك، بعد النقر على إشعار، يمكنك تحديد الخدمة أو أداة استقبال البث التي عملت كمنصة إطلاق الإشعارات في تطبيقك. ولإجراء ذلك، اطّلِع على ناتج أمر الوحدة الطرفية التالي:

adb shell dumpsys activity service \
  com.android.systemui/.dump.SystemUIAuxiliaryDumpService

يتضمّن أحد أقسام الناتج النص "NotifInteractionLog". يحتوي هذا القسم على المعلومات اللازمة لتحديد المكوّن الذي يبدأ نتيجةً للنقر على إشعار.

تحديث تطبيقك

إذا كان تطبيقك يبدأ نشاطًا من خدمة أو أداة استقبال بث تعمل كمنصّة إطلاق إشعارات، عليك إكمال خطوات نقل البيانات التالية:

  1. أنشئ عنصر PendingIntent مرتبطًا بالنشاط الذي يراه المستخدمون بعد النقر على الإشعار.
  2. استخدِم العنصر PendingIntent الذي أنشأته في الخطوة السابقة كجزء من إنشاء إشعارك.

لتحديد مصدر النشاط، من أجل تنفيذ التسجيل مثلاً، استخدِم البيانات الإضافية عند نشر الإشعار. لإجراء تسجيل مركزي، استخدِم ActivityLifecycleCallbacks أو مراقب دورة حياة Jetpack.

إيقاف السلوك أو تفعيله

عند اختبار إصدار قابل للتصحيح من تطبيقك، يمكنك تفعيل هذا القيد وإيقافه باستخدام علامة NOTIFICATION_TRAMPOLINE_BLOCK توافق التطبيق.

الاحتفاظ بنسخة احتياطية والاستعادة

هناك تغييرات في طريقة عمل ميزة الاحتفاظ بنسخة احتياطية واستعادتها في التطبيقات التي تعمل على الإصدار Android 12 (المستوى 31 لواجهة برمجة التطبيقات) وتستهدفه. تتوفّر طريقتان للاحتفاظ بنسخة احتياطية من البيانات واستعادتها على Android:

  • النُسخ الاحتياطية على السحابة الإلكترونية: يتم تخزين بيانات المستخدم في Google Drive الخاص به ليتمكّن من استعادتها لاحقًا على هذا الجهاز أو جهاز جديد.
  • عمليات النقل من جهاز إلى جهاز: يتم إرسال بيانات المستخدم مباشرةً إلى جهاز المستخدم الجديد من جهازه القديم، مثلاً باستخدام كابل.

لمزيد من المعلومات حول كيفية الاحتفاظ بنسخة احتياطية من البيانات واستعادتها، يُرجى الاطّلاع على الاحتفاظ بنسخة احتياطية من بيانات المستخدم باستخدام ميزة "التحميل التلقائي" والاحتفاظ بنسخة احتياطية من أزواج المفاتيح والقيم باستخدام خدمة الاحتفاظ بنسخة احتياطية من البيانات على Android.

التغييرات في وظائف ميزة "نقل البيانات من جهاز إلى آخر"

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

  • تحديد قواعد التضمين والاستبعاد باستخدام آلية إعداد XML لا يؤثر في عمليات نقل البيانات من جهاز إلى آخر، ولكنّه يظل يؤثر في عمليات الاحتفاظ بنسخة احتياطية من البيانات واستعادتها المستندة إلى السحابة الإلكترونية (مثل النُسخ الاحتياطية في Google Drive). لتحديد قواعد عمليات النقل من جهاز إلى جهاز، يجب استخدام الإعدادات الجديدة الموضّحة في القسم التالي.

  • على الأجهزة التي تصنّعها بعض الشركات، يؤدي تحديد android:allowBackup="false" إلى إيقاف النسخ الاحتياطي إلى Google Drive، ولكنّه لا يؤدي إلى إيقاف عمليات النقل من جهاز إلى جهاز للتطبيق.

تنسيق جديد للتضمين والاستبعاد

تستخدم التطبيقات التي تعمل على الإصدار 12 من نظام التشغيل Android والإصدارات الأحدث وتستهدفها تنسيقًا مختلفًا لملف إعداد XML. يُبرز هذا التنسيق الفرق بين النسخ الاحتياطي على Google Drive ونقل البيانات من جهاز إلى آخر، وذلك من خلال مطالبتك بتحديد قواعد التضمين والاستبعاد بشكل منفصل لكل من النسخ الاحتياطية على السحابة الإلكترونية ونقل البيانات من جهاز إلى آخر.

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

تغييرات في تنسيق XML

في ما يلي التنسيق المستخدَم لإعدادات النسخ الاحتياطي والاستعادة في الإصدار 11 من نظام التشغيل Android والإصدارات الأقدم:

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

في ما يلي التغييرات التي طرأت على التنسيق بالخط العريض.

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

لمزيد من المعلومات، يُرجى الاطّلاع على القسم ذي الصلة في دليل الاحتفاظ بنسخة احتياطية من بيانات المستخدمين باستخدام ميزة "النسخ الاحتياطي التلقائي".

علامة في بيان التطبيق

وجِّه تطبيقاتك إلى إعدادات XML الجديدة باستخدام السمة android:dataExtractionRules في ملف البيان. عند الإشارة إلى إعداد XML الجديد، سيتم تجاهل السمة android:fullBackupContent التي تشير إلى الإعداد القديم على الأجهزة التي تعمل بالإصدار 12 من نظام التشغيل Android أو الإصدارات الأحدث. يعرض نموذج الرمز التالي إدخالات ملف البيان الجديدة:

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>

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

أذونات البلوتوث

يقدّم نظام التشغيل Android 12 أذونات BLUETOOTH_SCAN وBLUETOOTH_ADVERTISE وBLUETOOTH_CONNECT. تسهّل هذه الأذونات على التطبيقات التي تستهدف الإصدار 12 من نظام التشغيل Android التفاعل مع أجهزة Bluetooth، خاصةً التطبيقات التي لا تتطلّب الوصول إلى الموقع الجغرافي للجهاز.

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

استخدام شبكة الند للند واتصال الإنترنت في الوقت نفسه

بالنسبة إلى التطبيقات التي تستهدف الإصدار 12 من نظام التشغيل Android (المستوى 31 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث، يمكن للأجهزة التي تتيح الاتصالات المتزامنة بين الأجهزة والاتصالات بالإنترنت الحفاظ على اتصالات Wi-Fi متزامنة مع كل من الجهاز المجاور والشبكة الأساسية التي توفّر الإنترنت، ما يجعل تجربة المستخدم أكثر سلاسة. ستظل التطبيقات التي تستهدف الإصدار 11 من نظام التشغيل Android (المستوى 30 لواجهة برمجة التطبيقات) أو الإصدارات الأقدم تعمل وفقًا للسلوك القديم، حيث يتم قطع الاتصال بشبكة Wi-Fi الأساسية قبل الاتصال بالجهاز المجاور.

التوافق

يمكن أن تعرض WifiManager.getConnectionInfo() WifiInfo لشبكة واحدة فقط. ونتيجةً لذلك، تم تغيير سلوك واجهة برمجة التطبيقات بالطرق التالية في نظام التشغيل Android 12 والإصدارات الأحدث:

  • إذا كانت شبكة Wi-Fi واحدة فقط متاحة، يتم عرض WifiInfo الخاص بها.
  • في حال توفُّر أكثر من شبكة Wi-Fi واحدة وتفعيل تطبيق الاتصال لاتصال من نظير إلى نظير، يتم عرض WifiInfo الخاص بجهاز النظير.
  • إذا كانت هناك أكثر من شبكة Wi-Fi متاحة ولم يؤدِّ تطبيق الاتصال إلى إنشاء اتصال من جهاز إلى جهاز، سيتم عرض WifiInfo لاتصال الإنترنت الأساسي.

لتقديم تجربة أفضل للمستخدمين على الأجهزة التي تتوافق مع شبكات Wi-Fi مزدوجة ومتزامنة، ننصح جميع التطبيقات، خاصةً تلك التي تؤدي إلى إنشاء اتصالات بين الأجهزة، بالانتقال من استدعاء WifiManager.getConnectionInfo() إلى استخدام NetworkCallback.onCapabilitiesChanged() للحصول على جميع عناصر WifiInfo التي تتطابق مع NetworkRequest المستخدَمة لتسجيل NetworkCallback. تم إيقاف getConnectionInfo() نهائيًا بدءًا من Android 12.

يوضّح نموذج الرمز البرمجي التالي كيفية الحصول على WifiInfo في NetworkCallback:

Kotlin

val networkCallback = object : ConnectivityManager.NetworkCallback() {
  ...
  override fun onCapabilitiesChanged(
           network : Network,
           networkCapabilities : NetworkCapabilities) {
    val transportInfo = networkCapabilities.getTransportInfo()
    if (transportInfo !is WifiInfo) return
    val wifiInfo : WifiInfo = transportInfo
    ...
  }
}

Java

final NetworkCallback networkCallback = new NetworkCallback() {
  ...
  @Override
  public void onCapabilitiesChanged(
         Network network,
         NetworkCapabilities networkCapabilities) {
    final TransportInfo transportInfo = networkCapabilities.getTransportInfo();
    if (!(transportInfo instanceof WifiInfo)) return;
    final WifiInfo wifiInfo = (WifiInfo) transportInfo;
    ...
  }
  ...
};

mDNSResponder native API

يغيّر نظام التشغيل Android 12 الوقت الذي يمكن فيه للتطبيقات التفاعل مع البرنامج الخفي mDNSResponder باستخدام واجهة برمجة التطبيقات الأصلية mDNSResponder. في السابق، عندما كان أحد التطبيقات يسجّل خدمة على الشبكة ويستدعي الطريقة getSystemService()، كانت خدمة NSD في النظام تبدأ عملية mDNSResponder، حتى إذا لم يستدعِ التطبيق أي طرق NsdManager بعد. بعد ذلك، اشترك البرنامج الخفي في مجموعات البث المتعدد لجميع العُقد، ما أدّى إلى تنبيه النظام بشكل متكرر واستهلاك طاقة إضافية. للحدّ من استهلاك البطارية، يبدأ النظام في الإصدار 12 من نظام التشغيل Android والإصدارات الأحدث عملية mDNSResponder فقط عند الحاجة إليها لأحداث NSD، ثم يتوقف بعد ذلك.

بما أنّ هذا التغيير يؤثّر في وقت توفّر البرنامج الخفي mDNSResponder، قد تتلقّى التطبيقات التي تفترض أنّه سيتم بدء البرنامج الخفي mDNSResponder بعد استدعاء الطريقة getSystemService() رسائل من النظام تفيد بأنّ البرنامج الخفي mDNSResponder غير متوفّر. لن تتأثّر التطبيقات التي تستخدم NsdManager ولا تستخدم واجهة برمجة التطبيقات الأصلية mDNSResponder بهذا التغيير.

مكتبات المورّدين

المكتبات المشتركة الأصلية التي يوفّرها المورّد

لا يمكن الوصول تلقائيًا إلى المكتبات المشترَكة المجمّعة من رموز برمجية أصلية غير تابعة لمجموعة تطوير البرامج (NDK) التي يوفّرها مورّدو شرائح السيليكون أو مصنّعو الأجهزة، إذا كان التطبيق يستهدف الإصدار 12 من نظام التشغيل Android (المستوى 31 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث. لا يمكن الوصول إلى المكتبات إلا عند طلبها بشكل صريح باستخدام العلامة <uses-native-library>.

إذا كان التطبيق يستهدف الإصدار 11 من نظام التشغيل Android (المستوى 30 لواجهة برمجة التطبيقات) أو إصدارًا أقدم، لا يلزم استخدام العلامة <uses-native-library>. في هذه الحالة، يمكن الوصول إلى أي مكتبة مشتركة أصلية بغض النظر عمّا إذا كانت مكتبة NDK أم لا.

تعديل القيود المفروضة على استخدام واجهات برمجة التطبيقات غير التابعة لحزمة SDK

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

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

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

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