تمت ترجمة هذه الصفحة بواسطة 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 بكسل مستقل الكثافة (dp). بالإضافة إلى ذلك، تكون المساحة الأفقية أقل.
- إنّ جميع الإشعارات قابلة للتوسيع للتطبيقات التي تستهدف الإصدار 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 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث، بما في ذلك Android 12، والإصدار 89.0.4385.0 أو إصدار أحدث من WebView.
اجمع تطبيقك لاستهداف الإصدار 12 من Android (المستوى 31 لواجهة برمجة التطبيقات) بحلول targetSdkVersion.

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

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

مراجع أخرى

لمزيد من المعلومات عن السلوكيات الحديثة لـ SameSite وطرحها في Chrome وWeb WebView، انتقِل إلى صفحة تحديثات Chromium SameSite. إذا عثرت على خلل في 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 أو الإصدارات الأحدث ويحتوي على أنشطة أو خدمات أو مُستلِمِي إعلامات البث يستخدمون فلاتر النشاط، عليك تحديد 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":

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

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

لتحسين أمان النظام الأساسي، يوفّر الإصدار 12 من Android والإصدارات الأحدث ميزة debugging (تصحيح الأخطاء) التي ترصد عمليات الإطلاق غير الآمنة لسمات intent. وعندما يكتشف النظام عملية إطلاق غير آمنة، يحدث انتهاك 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
```

القيود المفروضة على ميزة "القفزة إلى الإشعار"

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

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

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

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

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

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

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

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

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

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

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