تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

التغييرات في السلوك: التطبيقات التي تستهدف الإصدار 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. غيِّر targetSdkVersion في تطبيقك إلى S لتفعيل السلوك الجديد.
2. إعادة التجميع
3. ثبِّت تطبيقك على جهاز أو جهاز محاكاة يعمل بنظام التشغيل Android 12.
اختبِر جميع الإشعارات التي تستخدم طرق عرض مخصّصة، وتأكَّد من أنّها تظهر بالشكل الذي تريده في وضع "الإضاءة المنخفضة". أثناء الاختبار، يجب مراعاة الاعتبارات التالية وإجراء التعديلات اللازمة:
- تغيّرت سمات العروض المخصّصة. بشكل عام، أصبح الارتفاع المخصّص للإشعارات المخصّصة أقلّ مما كان عليه من قبل. في الحالة المُدمَجة ، انخفض الحد الأقصى لارتفاع المحتوى المخصّص من 106 بكسل مستقل الكثافة إلى 48 بكسل مستقل الكثافة. بالإضافة إلى ذلك، تكون المساحة الأفقية أقل.
- تكون جميع الإشعارات قابلة للتوسيع في التطبيقات التي تستهدف الإصدار 12 من Android. يعني ذلك عادةً أنّه إذا كنت تستخدم setCustomContentView، عليك أيضًا استخدام setBigCustomContentView للتأكّد من اتساق حالتَي التصغير والتوسيع.
- للتأكّد من أنّ حالة "تنبيه" تظهر على النحو المتوقّع، لا تنسَ رفع أهمية قناة الإشعارات إلى "عالية" (تنبيهات منبثقة على الشاشة).

تغييرات في عملية إثبات ملكية رابط تطبيق Android

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

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

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

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

يقدّم نظام التشغيل Android 12 تحسينات على سلوك وضع "صورة في صورة"، ويقدّم تحسينات جمالية مقترَحة على الرسوم المتحرّكة للانتقالات لكلّ من التنقّل باستخدام الإيماءات والتنقّل المستنِد إلى العناصر.

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

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

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

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

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

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

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

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

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

مراجع أخرى

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

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

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

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

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

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

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

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

تتيح لك واجهة برمجة التطبيقات Data access auditing API، التي تم طرحها في Android 11 (المستوى 30 من واجهة برمجة التطبيقات)، إنشاء علامات تحديد المصدر استنادًا إلى حالات استخدام تطبيقك. تسهّل عليك هذه العلامات تحديد الجزء الذي يؤدي فيه تطبيقك نوعًا معيّنًا من الوصول إلى البيانات.

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

القيود المفروضة على الاحتفاظ بنسخة احتياطية باستخدام أداة ADB

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

إذا كانت سير عمل الاختبار أو التطوير تعتمد على بيانات التطبيق باستخدام adb backup، يمكنك الآن تفعيل تصدير بيانات تطبيقك من خلال ضبط android:debuggable على true في ملف بيان تطبيقك.

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

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

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

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

يظهر تحذير lint التالي في ملف البيان:

When using intent filters, please specify android:exported as well

عند محاولة تجميع تطبيقك، تظهر رسالة خطأ الإنشاء التالية:

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 Studio:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

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

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

الأداء

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

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

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

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

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

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

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

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

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

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

تحديث تطبيقك

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

أنشئ عنصر PendingIntent مرتبطًا بالنشاط الذي يظهر للمستخدمين بعد النقر على الإشعار.
استخدِم العنصر PendingIntent الذي أنشأته في الخطوة السابقة كجزء من إنشاء إعلامك.

لتحديد مصدر النشاط، مثلاً لإجراء التسجيل، استخدِم الإضافات عند نشر الإشعار. بالنسبة إلى التسجيل المركزي، استخدِم ActivityLifecycleCallbacks أو مراقبو دورة حياة Jetpack.

تفعيل السلوك أو إيقافه

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

الاحتفاظ بنسخة احتياطية والاستعادة

تم إجراء تغييرات على آلية عمل الاحتفاظ بنسخة احتياطية من البيانات واستعادتها في التطبيقات التي تعمل بالإصدار Android 12 (المستوى 31 لواجهة برمجة التطبيقات) وتستهدفه. يتوفّر الاحتفاظ بنسخة احتياطية من البيانات واستعادتها على Android بطريقتَين:

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

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

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

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

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

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

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

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

تغييرات في تنسيق 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 التي تشير إلى ملف الإعدادات القديم على الأجهزة التي تعمل بنظام التشغيل 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;
    ...
  }
  ...
};

واجهة برمجة التطبيقات الأصلية لخدمة mDNSResponder

تم إجراء تغييرات في Android 12 عندما يمكن للتطبيقات التفاعل مع الخادم الدائم mDNSResponder باستخدام واجهة برمجة التطبيقات الأصلية mDNSResponder API. في السابق، عندما كان التطبيق يُسجِّل خدمة على الشبكة ويستدعي الطريقة 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) تم تعديلها

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

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

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

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