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

تغييرات السلوك: جميع التطبيقات

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

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

تجربة المستخدم

تأثير التمديد عند الانتقال إلى أعلى الصفحة أو أسفلها

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

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

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

شاشات البداية للتطبيقات

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

للحصول على التعليمات، يُرجى الاطّلاع على مقالة نقل عملية تنفيذ شاشة البداية الحالية إلى Android 12.

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

لمزيد من التفاصيل، يُرجى الاطّلاع على دليل المطوّر الخاص بشاشات البداية.

حلّ النية على الويب

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

يمكن للتطبيقات الحصول على هذه الموافقة من خلال تنفيذ أحد الإجراءات التالية:

إثبات ملكية النطاق باستخدام روابط تطبيقات Android

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

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

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

تحسينات على الوضع الشامل للتنقّل بالإيماءات

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

Display#getRealSize وgetRealMetrics: الإيقاف النهائي والقيود

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

في Android 12، سنواصل اقتراح استخدام WindowMetrics، وسنتوقف نهائيًا عن استخدام الطريقتَين التاليتَين:

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

يجب أن تستخدم التطبيقات واجهات برمجة التطبيقات WindowMetrics لطلب حدود النافذة، وConfiguration.densityDpi لطلب الكثافة الحالية.

للحصول على توافق أوسع مع الإصدارات القديمة من Android، يمكنك استخدام مكتبة WindowManager Jetpack التي تضم فئة WindowMetrics متوافقة مع Android 4.0 (المستوى 14 من واجهة برمجة التطبيقات) والإصدارات الأحدث.

أمثلة على كيفية استخدام WindowMetrics

أولاً، تأكَّد من أنّ أنشطة تطبيقك قابلة للتغيير بالكامل.

يجب أن يعتمد النشاط على WindowMetrics من سياق النشاط لأي عمل مرتبط بواجهة المستخدم، خاصةً WindowManager.getCurrentWindowMetrics() أو WindowMetricsCalculator.computeCurrentWindowMetrics() من Jetpack.

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

إذا كان التطبيق قابلاً للتغيير بالكامل، يعرض سياق النشاط الحدود الصحيحة على النحو التالي:

Kotlin

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

Java

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

إذا لم يكن بالإمكان تغيير حجم التطبيق بالكامل، يجب أن يطلب التطبيق معلومات من مثيل WindowContext ويسترجع WindowMetrics لحدود النشاط باستخدام WindowManager.getMaximumWindowMetrics() أو طريقة Jetpack WindowMetricsCalculator.computeMaximumWindowMetrics().

Kotlin

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

Java

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

جميع التطبيقات في وضع "النوافذ المتعددة"

في نظام التشغيل Android 12، يصبح وضع "النوافذ المتعددة" سلوكًا عاديًا.

على الشاشات الكبيرة (sw >= 600dp)، تتيح المنصة استخدام جميع التطبيقات في وضع المتعدّد المكوّنات بغض النظر عن إعدادات التطبيق. في حال resizeableActivity="false"، يتم وضع التطبيق في وضع التوافق عند الضرورة لاستيعاب سمات الشاشة.

على الشاشات الصغيرة (sw < 600dp)، يتحقّق النظام من minWidth و minHeight لتحديد ما إذا كان يمكن تشغيل النشاط في وضع "النوافذ المتعددة". إذا كان القيمة هي resizeableActivity="false"، يتم منع تشغيل التطبيق في وضع "النوافذ المتعددة" بغض النظر عن الحد الأدنى للعرض والارتفاع.

لمزيد من المعلومات، يُرجى الاطّلاع على التوافق مع ميزة "تعدد النوافذ".

معاينة الكاميرا على الشاشات الكبيرة

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

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

تأخُّر ظهور إشعارات الخدمات التي تعمل في المقدّمة

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

الأداء

حزمة التطبيقات المحظورة في وضع الاستعداد

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

نشط: يتم استخدام التطبيق حاليًا أو تم استخدامه مؤخرًا جدًا.
مجموعة العمل: يتم استخدام التطبيق بانتظام.
متكرّر: يتم استخدام التطبيق بشكل متكرّر، ولكن ليس يوميًا.
نادر: لا يتم استخدام التطبيق بشكل متكرّر.
محظور: يستهلك التطبيق قدرًا كبيرًا من موارد النظام، أو قد يعرض سلوكًا غير مرغوب فيه.

يأخذ النظام سلوك تطبيقك في الاعتبار، بالإضافة إلى أنماط الاستخدام، لتحديد ما إذا كان سيتم وضع تطبيقك في الحزمة المحظورة.

من غير المرجّح أن يتم وضع تطبيقك في المجموعة المحظورة إذا كان يستخدم موارد النظام بمسؤولية أكبر. ويضع النظام تطبيقك أيضًا في مجموعة أقل تقييدًا إذا تفاعل المستخدم مع تطبيقك مباشرةً.

التحقّق مما إذا كان تطبيقك مضمّنًا في الحزمة المحظورة

للتحقّق مما إذا كان النظام قد وضع تطبيقك في الحزمة المحظورة، يُرجى الاتصال بالرقم getAppStandbyBucket(). إذا كانت القيمة المعروضة لهذه الطريقة هي STANDBY_BUCKET_RESTRICTED، يعني ذلك أنّ تطبيقك في الحزمة المحظورة.

اختبار سلوك الحزمة المحظورة

لاختبار سلوك تطبيقك عندما يضع النظام تطبيقك في الحزمة المقيّدة، يمكنك نقل تطبيقك يدويًا إلى هذه الحزمة. لإجراء ذلك، نفِّذ الأمر التالي في نافذة وحدة طرفية:

adb shell am set-standby-bucket PACKAGE_NAME restricted

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

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

يحتوي مربّع الحوار على مجموعتَين من الخيارات، إحداهما فوق
الأخرى. — **الشكل 1.** مربّع حوار أذونات النظام الذي يسمح للمستخدم بمنح معلومات الموقع الجغرافي التقريبي

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

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

يتضمّن مربّع حوار أذونات النظام الخيارات التالية للمستخدم، كما هو موضّح في الشكل 1:

دقيق: يتيح الوصول إلى معلومات الموقع الجغرافي الدقيق.
تقريبي: يتيح الوصول إلى معلومات الموقع الجغرافي التقريبي فقط.

خيارات إيقاف/تشغيل الميكروفون والكاميرا

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

اطّلِع على مزيد من المعلومات عن أزرار الإيقاف/التفعيل هذه وكيفية التأكّد مما إذا كان تطبيقك يتّبع أفضل الممارسات المتعلّقة بأذونات CAMERA و RECORD_AUDIO.

مؤشرات استخدام الميكروفون والكاميرا

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

اطّلِع على مزيد من المعلومات عن هذين المؤشّرين وكيفية التحقّق من اتّباع تطبيقك لأفضل الممارسات المتعلّقة بإذنَي CAMERA و RECORD_AUDIO.

يتم تصنيف مربّعات الإعدادات السريعة على أنّها "الوصول إلى الكاميرا" و
'الوصول إلى الميكروفون". — **الشكل 2.** زرَّا تفعيل الميكروفون والكاميرا في الإعدادات السريعة

مستطيل بيضاوي في أعلى يسار الشاشة يحتوي
على رمز كاميرا ورمز ميكروفون — **الشكل 3.** مؤشرات استخدام الميكروفون والكاميرا، التي تعرض عمليات الوصول إلى البيانات الأخيرة

إذن الوصول إلى الحزمة

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

تمت إزالة عملية تنفيذ BouncyCastle

يزيل نظام التشغيل Android 12 العديد من عمليات تنفيذ BouncyCastle لخوارزميات التشفير التي تم إيقافها نهائيًا سابقًا، بما في ذلك جميع خوارزميات AES. ويستخدم النظام بدلاً من ذلك تطبيقات Conscrypt ل هذه الخوارزميات.

يؤثر هذا التغيير في تطبيقك في حال استيفاء أيٍّ مما يلي:

يستخدم تطبيقك أحجام مفاتيح بسعة 512 بت. لا يتوافق Conscrypt مع حجم المفتاح هذا. عدِّل منطق التشفير في تطبيقك إذا لزم الأمر لاستخدام أحجام مفاتيح مختلفة.
يستخدم تطبيقك أحجام مفاتيح غير صالحة مع KeyGenerator. يُجري تنفيذ Conscrypt لسمة KeyGenerator عملية فحص إضافية على مَعلمات المفاتيح مقارنةً بـ BouncyCastle. على سبيل المثال، لا يسمح Conscrypt لتطبيقك بإنشاء مفتاح AES بسعة 64 بت لأنّ AES لا يدعم سوى مفاتيح بسعة 128 و192 و256 بت.

تسمح مكتبة BouncyCastle بإنشاء مفاتيح بأحجام غير صالحة، ولكنّها تتعذّر في وقت لاحق إذا تم استخدام هذه المفاتيح مع Cipher. تعذّر تشغيل Conscrypt في وقت سابق.
يتم إعداد رموز التشفير Galois/Counter Mode (GCM) باستخدام حجم مختلف عن 12 بايت. يتطلّب تنفيذ مكتبة Conscrypt لخوارزمية GcmParameterSpec عملية initialization تبلغ 12 بايت، وهو ما تنصح به مؤسسة NIST.

إشعارات الوصول إلى الحافظة

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

يحتوي النص داخل رسالة التذكير على التنسيق التالي: APP pasted from your clipboard.

معلومات عن النص في وصف المقطع

على نظام التشغيل Android 12 والإصدارات الأحدث، يمكن لتطبيق getPrimaryClipDescription() رصد التفاصيل التالية:

نص منمق باستخدام isStyledText()
تصنيفات مختلفة للنص، مثل عناوين URL، باستخدام getConfidenceScore()

لا يمكن للتطبيقات إغلاق مربّعات حوار النظام

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

إذا كان تطبيقك يستهدف الإصدار 12 من نظام التشغيل Android أو إصدارًا أحدث، يحدث SecurityException.
إذا كان تطبيقك يستهدف الإصدار 11 من نظام التشغيل Android (المستوى 30 لواجهة برمجة التطبيقات) أو إصدارًا أقدم، لن يتم تنفيذ الإجراء، وستظهر الرسالة التالية في ملف logcat:
```
E ActivityTaskManager Permission Denial: \
android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
dropping broadcast.
```

الاستثناءات

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

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

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

يتم حظر أحداث اللمس غير الموثوق بها

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

التطبيقات المتأثِّرة

يؤثر هذا التغيير في التطبيقات التي تختار السماح بمرور اللمسات من خلال نوافذها، على سبيل المثال باستخدام العلامة FLAG_NOT_TOUCHABLE. تشمل الأمثلة على ذلك، على سبيل المثال لا الحصر، ما يلي:

التراكبات التي تتطلّب إذن SYSTEM_ALERT_WINDOW ، مثل النوافذ التي تستخدم TYPE_APPLICATION_OVERLAY، وتستخدم العلامة FLAG_NOT_TOUCHABLE
نوافذ الأنشطة التي تستخدم العلامة FLAG_NOT_TOUCHABLE

الاستثناءات

في الحالات التالية، يُسمح بلمسات "المرور":

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

رصد حالات حظر لمسة غير موثوق بها

إذا حظر النظام إجراءً باللمس، يسجِّل Logcat الرسالة التالية:

Untrusted touch due to occlusion by PACKAGE_NAME

اختبار التغيير

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

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

للعودة إلى السلوك التلقائي (يتم حظر اللمسات غير الموثوق بها)، شغِّل العبارة التالية:

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

مراحل النشاط

لم تعُد أنشطة مشغّل التطبيقات الجذر تنتهي عند الضغط على "رجوع".

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

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

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

يُرجى العلم أيضًا أنّنا ننصحك بشكل عام باستخدام واجهات برمجة تطبيقات AndroidX Activity API من أجل توفير ميزة التنقّل للخلف المخصّصة، بدلاً من إلغاء onBackPressed(). تُحيل واجهات برمجة التطبيقات AndroidX Activity API تلقائيًا إلى سلوك النظام المناسب في حال عدم توفّر مكونات تعترض الضغط على زر الرجوع في النظام.

الرسومات والصور

تحسين عملية التبديل بين معدّلات التحديث

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

في ما يلي مثال على كيفية تنفيذ ذلك:

Kotlin

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

Java

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

إمكانية الاتصال

تعديلات على Passpoint

تمت إضافة واجهات برمجة التطبيقات التالية في Android 12:

isPasspointTermsAndConditionsSupported(): الأحكام والشروط هي ميزة Passpoint تسمح بعمليات نشر الشبكة لاستبدال المداخل المشروطة الوصول إليها غير الآمنة، التي تستخدم شبكات مفتوحة، بشبكة Passpoint آمنة. يتم عرض إشعار على المستخدم عند طلب قبول الأحكام والشروط. بالنسبة إلى التطبيقات التي تقترح شبكات Passpoint التي تخضع لأحكام وشروط معيّنة، يجب أن تتصل أولاً بواجهة برمجة التطبيقات هذه للتأكّد من أنّ الجهاز يتيح هذه الميزة. إذا لم يكن الجهاز متوافقًا مع هذه الميزة، لن يتمكّن من الاتصال بهذه الشبكة، ويجب اقتراح شبكة بديلة أو شبكة قديمة.
isDecoratedIdentitySupported(): عند المصادقة على الشبكات التي تتضمّن زخرفة بادئة، تسمح بادئة الهوية المزخرفة لمشغّلي الشبكة بتعديل معرّف الوصول إلى الشبكة (NAI) لإجراء توجيه صريح من خلال عدة خوادم وكيلة داخل شبكة إدارة الهوية وإمكانية الوصول (AAA) (اطّلِع على RFC 7542 للحصول علىمزيد من المعلومات حول هذا الموضوع).

ينفِّذ نظام التشغيل Android 12 هذه الميزة للتوافق مع مواصفات WBA لإضافات PPS-MO. على التطبيقات التي تقترح شبكات Passpoint التي تتطلّب هوية مزيّنة طلب هذه الواجهة أولاً للتأكّد من أنّ الجهاز يتيح هذه الميزة. إذا لم يكن الجهاز متوافقًا مع هذه الميزة، لن يتم تزيين الهوية وقد يتعذّر إجراء المصادقة على الشبكة.

لإنشاء اقتراح Passpoint، يجب أن تستخدم التطبيقات فئات PasspointConfiguration و Credential و HomeSp. تصف هذه الفئات الملف الشخصي لبرنامج Passpoint، والذي تم تحديده في مواصفات Wi-Fi Alliance Passpoint.

لمزيد من المعلومات، يُرجى الاطّلاع على Wi-Fi suggestion API للاتصال بالإنترنت.

قيود محدّثة على الواجهات غير المتوفّرة في حِزم SDK

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

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

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

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