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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تصميم جديد للخبز المحمّص

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

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

للحصول على مزيد من التفاصيل، يمكنك الاطّلاع على نظرة عامة على Toasts.

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

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

على الأجهزة التي تعمل بالإصدار 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، أو إذا كنت تدير موقعًا إلكترونيًا أو خدمة تستخدم ملفات تعريف الارتباط، ننصحك باختبار التدفقات على Android 12 WebView. في حال رصد مشاكل، قد تحتاج إلى تعديل ملفات تعريف الارتباط للتوافق مع سلوكيات SameSite الجديدة.

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

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

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

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

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

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

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

مراجع أخرى

لمزيد من المعلومات حول سلوكيات SameSite الحديثة وطرحها على متصفِّح Chrome و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. بالنسبة إلى التطبيقات التي تستهدف Android 12 (المستوى 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" الذي تستخدمه:

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

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

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

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

اختبار تغيير قابلية التغيّر للأهداف المعلَّقة

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

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

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

عروض أداء

قيود إطلاق الخدمات التي تعمل في المقدّمة

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

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

إذن المنبّه المحدد

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

وللحصول على إذن الوصول الخاص إلى هذا التطبيق، عليك طلب إذن 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.

تغييرات في وظائف نقل البيانات بعد الاتصال بالإنترنت

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

  • يؤدي تحديد android:allowBackup="false" إلى إيقاف الاحتفاظ بنسخ احتياطية في Google Drive، ولكنه لا يوقف عمليات نقل D2D للتطبيق.

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

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

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

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

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

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

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

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

اتصال نظير إلى نظير متزامن + اتصال إنترنت

بالنسبة إلى التطبيقات التي تستهدف الإصدار Android 12 (المستوى 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() نهائيًا اعتبارًا من الإصدار 12 من نظام التشغيل Android.

يعرض نموذج الرمز البرمجي التالي طريقة الحصول على 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;
    ...
  }
  ...
};

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

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

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

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

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

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

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

القيود المعدّلة غير التابعة لحزمة تطوير البرامج (SDK)

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

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

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

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