The Android 15 Beta is now available. Try it out today and let us know what you think!

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

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

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

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

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

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

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

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

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

إعادة تصميم Toast

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

صورة لجهاز 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 التوضيحية وSchemeful SameSite.

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

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

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

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

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

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

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

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

مراجع أخرى

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

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

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

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

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

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

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

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

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

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

قيد النسخ الاحتياطي عبر ADB

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

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

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

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

إذا كان مكوِّن التطبيق يتضمّن الفئة LAUNCHER، اضبط السمة android:exported على true. في معظم الحالات الأخرى، يمكنك ضبط android:exported على false.

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

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

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

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

إصدار Android Studio 2020.3.1 Canary 11 أو إصدار أحدث

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

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

اختبار التغيير المعلَّق لقابلية التغيّر في النية بالشراء

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

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

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

الأداء

قيود تشغيل الخدمات التي تعمل في المقدّمة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

التوافق

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

في حال توفُّر شبكة Wi-Fi واحدة فقط، يتم عرض WifiInfo.
في حال توفّر أكثر من شبكة Wi-Fi واحدة وأقام تطبيق الاتصال اتصال نظير إلى نظير، يتم إرجاع WifiInfo المتوافقة مع الجهاز النظير.
في حال توفُّر أكثر من شبكة Wi-Fi واحدة ولم يشغِّل تطبيق الاتصال الاتصال من نظير إلى نظير، سيتم عرض اتصال WifiInfo الأساسي الذي يوفّر اتصال الإنترنت.

لتقديم تجربة أفضل للمستخدم على الأجهزة المتوافقة مع شبكات Wi-Fi المزدوجة المتزامنة، ننصح بنقل جميع التطبيقات بعيدًا عن الاتصال WifiManager.getConnectionInfo()، وخاصةً التطبيقات التي تؤدي إلى تشغيل الاتصالات من نظير إلى نظير، 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;
    ...
  }
  ...
};

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

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

وبما أنّ هذا التغيير يؤثر في وقت توفّر البرنامج الخفي mDNSResponseer، فإنّ التطبيقات التي تفترض أنّ البرنامج الخفي mDNSReplyer سيبدأ بعد استدعاء الطريقة getSystemService() قد تتلقّى رسائل من النظام تفيد بأنّ البرنامج الخفي mDNSReplyer غير متاح. ولن يؤثّر هذا التغيير في التطبيقات التي تستخدم 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).