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

مثل الإصدارات السابقة، يتضمّن Android 12 تغييرات في السلوك قد تؤثر في تطبيقك. تنطبق التغييرات التالية في السلوك حصريًا على التطبيقات التي تستهدف Android 12 أو الإصدارات الأحدث. إذا كان تطبيقك يستهدف الإصدار 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 لفتح روابط الويب في تطبيقك، يُرجى التأكّد من استخدام التنسيق الصحيح عند إضافة فلاتر النيّة لعملية التحقّق من روابط التطبيقات في Android. وعلى وجه الخصوص، تأكَّد من أنّ فلاتر الأهداف هذه تتضمّن الفئة BROWSABLE وتتوافق مع المخطط https.

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

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

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

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

إعادة تصميم رسائل Toast

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

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

لمزيد من التفاصيل، يُرجى الاطّلاع على نظرة عامة على رسائل الإعلام.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مراجع أخرى

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

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

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

مزيد من المعلومات حول الحدّ من معدّل نقل البيانات في أدوات الاستشعار

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

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

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

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

تتيح لك واجهة برمجة التطبيقات للتدقيق في الوصول إلى المعلومات، والتي تم طرحها في الإصدار 11 من نظام التشغيل Android (مستوى واجهة برمجة التطبيقات 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.

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

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

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

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

استوديو Android 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'

قابلية تغيُّر الـ intents المؤجّلة

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

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

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

عمليات تشغيل الطلبات غير الآمنة

لتحسين أمان النظام الأساسي، يوفّر 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

القيود المفروضة على الإشعارات التي تفتح التطبيقات

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

لتحسين أداء التطبيق وتجربة المستخدم، لا يمكن للتطبيقات التي تستهدف الإصدار 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 والاستعادة على Android في شكلَين:

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

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

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

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

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

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

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

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

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

لإعداد جهازك لاستهداف الإصدار 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

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