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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

في Android 12، تمت إعادة تصميم عرض الإعلام المنبثق. تقتصر الإشعارات المنبثقة الآن على سطرَين من النص وتعرض رمز التطبيق بجانب النص.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مراجع أخرى

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

أجهزة استشعار الحركة محدودة المعدّل

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

اطّلِع على المزيد من المعلومات حول تحديد معدّلات الاستجابة لأجهزة الاستشعار.

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

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

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

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

تتيح لك واجهة برمجة التطبيقات "تدقيق الوصول إلى البيانات"، التي تم تقديمها في 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، ستظهر رسائل التحذير التالية حسب إصدار "استوديو Android" الذي تستخدمه:

إصدار Android Studio 2020.3.1 Canary 11 أو إصدار أحدث

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

  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'

قابلية التغيّر في عناصر واجهة المستخدم في انتظار المراجعة

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

اختبار تغيير قابلية تغيُّر PendingIntent

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

عمليات الإطلاق غير الآمنة حسب نية العميل

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

الأداء

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

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

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

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

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

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

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

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

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

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

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

    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.

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

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

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

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

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

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

واجهة برمجة التطبيقات الأصلية لـ mDNSReplyer

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

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

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

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

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

إذا كان التطبيق يستهدف الإصدار Android 11 (المستوى 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.