التغييرات في السلوك: التطبيقات التي تستهدف الإصدار 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)، واقتراحات تجميلية لنقل الصور المتحركة لكل من التنقّل بالإيماءات والتنقل المستند إلى العناصر.

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

تصميم جديد لتحميص

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

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

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

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

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

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

ملفات تعريف الارتباط الحديثة من 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.

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

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

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

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

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

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

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

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

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

مراجع أخرى

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

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

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

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

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

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

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

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

تتيح لك واجهة برمجة التطبيقات لفحص الوصول إلى البيانات، التي تم توفيرها في 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'

قابلية تغيُّر الطلبات في انتظار المراجعة

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

اختبار تغيير قابلية التغيّر في انتظار المراجعة

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

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

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

الأداء

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

لا يمكن للتطبيقات التي تستهدف الإصدار 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 الصريح من خلال مطالبتك بتحديد قواعد التضمين والاستثناء بشكل منفصل للنسخ الاحتياطية على السحابة الإلكترونية وللنقل من جهاز إلى جهاز آخر.

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

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

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

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

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

التوافق

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

  • في حال توفّر شبكة 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
    ...
  }
}

جافا

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)

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

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

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

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