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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تأخير تجربة المستخدم لإشعارات الخدمة التي تعمل في المقدّمة

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

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

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

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

تظهر مربّعات الإعدادات السريعة تحت عنوان &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. تعذَّر فك التشفير في وقت سابق.

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

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

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

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

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

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

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

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

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

  • يشغّل تطبيقك أداة الاختبار.

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

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

  • يستهدف تطبيقك الإصدار Android 11 أو الإصدارات الأقدم، ويحتوي على ميزات نشطة Accessibility Service. إذا كان تطبيقك تستهدف 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

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

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

رسومات وصور

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

في 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 Alliance نقطة مرور المواصفات.

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

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

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

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

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

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