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

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

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

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

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

يغيّر نظام التشغيل 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، بما في ذلك 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 أو الإصدارات الأحدث ويتضمّن أنشطة أو خدمات أو مستقبِلات بث تستخدم فلاتر أهداف، عليك الإفصاح صراحةً عن السمة android:exported لهذه المكوّنات في التطبيق.

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

يوضّح مقتطف الرمز التالي مثالاً على خدمة تحتوي على فلتر أهداف تم ضبط السمة 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، ستظهر رسائل التحذير التالية، وذلك حسب إصدار &quot;استوديو Android&quot; الذي تستخدمه:

الإصدار 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.
الإصدارات القديمة من &quot;استوديو Android&quot;

إذا حاولت تثبيت التطبيق، ستعرض أداة 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 ينشئه تطبيقك. يساهم هذا الشرط الإضافي في تحسين أمان تطبيقك.

اختبار تغيير قابلية التغيّر في intent مؤجّلة

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

عمليات إطلاق غير آمنة لـ Intent

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

الأداء

تقييد إمكانية تشغيل الخدمات التي تعمل في المقدّمة

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

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

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

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

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

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

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

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

  • في شاشة إعدادات خيارات المطوّرين، انقر على تغييرات توافق التطبيقات. في الشاشة التي تظهر، انقر على اسم تطبيقك، ثم أوقِف 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 الخاص به ليتمكّن من استعادتها لاحقًا على هذا الجهاز أو جهاز جديد.
  • عمليات النقل من جهاز إلى جهاز (D2D): يتم إرسال بيانات المستخدم مباشرةً إلى جهاز المستخدم الجديد من جهازه القديم، مثلاً باستخدام كابل.

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

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

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

<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.