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

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

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

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

تأثير التمرير الزائد

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

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

للمزيد من المعلومات، يُرجى الاطّلاع على دليل تحريك إيماءات التنقل.

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

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

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

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

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

دقة أهداف الويب

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

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

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

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

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

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

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

في نظام التشغيل Android 12، سنواصل اقتراح استخدام WindowMetrics، وسيتم إيقاف الطرق التالية نهائيًا:

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

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

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

الأداء

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

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

  1. نشط: التطبيق قيد الاستخدام حاليًا أو تم استخدامه مؤخرًا.
  2. مجموعة العمل: التطبيق قيد الاستخدام العادي.
  3. متكرر: يتم استخدام التطبيق غالبًا، ولكن ليس كل يوم.
  4. نادر: لا يتم استخدام التطبيق بشكل متكرر.
  5. مقيَّد: يستهلك التطبيق قدرًا كبيرًا من موارد النظام أو قد يُظهر سلوكًا غير مرغوب فيه.

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

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

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

لمعرفة ما إذا كان النظام قد وضع تطبيقك في الحزمة المحظورة، يمكنك الاتصال بالرقم 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.

يظهر قسم &quot;الإعدادات السريعة&quot; ضمن &quot;الوصول إلى الكاميرا&quot; و&quot;الوصول إلى الميكروفون&quot;.
الشكل 2. إيقاف/تفعيل الميكروفون والكاميرا في "الإعدادات السريعة"
مستطيل مستدير في أعلى يسار الشاشة يتضمّن رمز الكاميرا ورمز الميكروفون
الشكل 3. مؤشرات الميكروفون والكاميرا التي تعرض عمليات الوصول الحديثة إلى البيانات

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

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

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

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

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

  • يستخدم تطبيقك أحجام مفاتيح 512 بت. لا تتوافق أداة Conscrypt مع حجم المفتاح هذا. إذا لزم الأمر، عدِّل منطق تشفير تطبيقك لاستخدام أحجام مفاتيح مختلفة.

  • يستخدم تطبيقك أحجام مفاتيح غير صالحة مع KeyGenerator. يؤدي تنفيذ Conscrypt لـ KeyGenerator إلى إجراء تحقق إضافي للمعلمات الرئيسية، مقارنةً باستخدام BouncyCastle. على سبيل المثال، لا تسمح أداة Conscrypt لتطبيقك بإنشاء مفتاح AES بحجم 64 بت لأن معيار التشفير المتقدّم (AES) يتوافق فقط مع المفاتيح بمعيار 128 و192 و256 بت.

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

  • يمكنك إعداد رموز Galaxy/وضع العد التنازلي (GCM) باستخدام حجم آخر أكبر من 12 بايت. يتطلّب تطبيق GcmParameterSpec في Conscrypt إعدادًا بحجم 12 بايت، وفقًا لما يوصي به المعهد الوطني للمعايير والتكنولوجيا (NIST).

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

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

يحتوي النص داخل رسالة الإعلام المنبثق على التنسيق التالي: APP pasted from your clipboard.

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

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

  • نص ذو نمط معيّن، باستخدام isStyledText().
  • التصنيفات المختلفة للنص، مثل عناوين URL، باستخدام السمة getConfidenceScore():

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

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

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

  • إذا كان تطبيقك يستهدف الإصدار Android 11 (المستوى 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.

الاستثناءات

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

  • يُجري تطبيقك اختبارًا للأدوات.

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

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

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

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

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

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

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

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

الاستثناءات

يُسمح باستخدام اللمسات "التمرير" في الحالات التالية:

  • التفاعلات داخل تطبيقك: يعرض تطبيقك المحتوى الذي يظهر على سطح الفيديو، ولا يظهر الإعلان المركّب إلا عندما يتفاعل المستخدم مع تطبيقك.

  • النوافذ الموثوق بها: تتضمن هذه النوافذ (على سبيل المثال لا الحصر) ما يلي:

  • النوافذ غير المرئية: طريقة عرض الجذر في النافذة هي 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);

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

تعديلات نقطة المرور

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

  • isPasspointTermsAndConditionsSupported(): الأحكام والشروط هي ميزة نقطة مرور تسمح لعمليات النشر على الشبكة باستبدال البوابات المقيّدة غير الآمنة التي تستخدم الشبكات المفتوحة بشبكة نقطة مرور آمنة. يظهر إشعار للمستخدم عندما تكون الأحكام والشروط مطلوبة. يجب أن تطلب التطبيقات التي تقترح شبكات نقطة المرور المُحاطة بالأحكام والشروط واجهة برمجة التطبيقات هذه أولاً للتأكّد من أنّ الجهاز يوفّر هذه الإمكانية. إذا كان الجهاز لا يتيح هذه الميزة، لن يتمكّن من الاتصال بهذه الشبكة، ويجب اقتراح شبكة بديلة أو قديمة.

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

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

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

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

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

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

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

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

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