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

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

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

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

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

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

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

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

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

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

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

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

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

دقة الموقع الإلكتروني حسب النية بالشراء

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

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

  • أثبِت ملكية النطاق باستخدام Android App Links.

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

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

  • اطلب من المستخدم ربط تطبيقك بالنطاق في إعدادات النظام.

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

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

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

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

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

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

للحدّ من سلوك التطبيقات التي تستخدم واجهة برمجة التطبيقات Display API لاسترداد حدود التطبيق، يقيّد نظام 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. مربّع حوار أذونات النظام الذي يسمح للمستخدم بمنح معلومات الموقع الجغرافي التقريبية.

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

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

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

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

إيقاف/تفعيل الكاميرا والميكروفون

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

في الإصدار 12 من نظام التشغيل Android والإصدارات الأحدث، عندما يطلب أحد التطبيقات الوصول إلى 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 أو الإصدارات الأحدث:

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

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

  • يستهدف تطبيقك الإصدار 11 من نظام التشغيل Android أو الإصدارات الأقدم ويتضمّن خدمة تسهيل استخدام نشطة. إذا كان تطبيقك يستهدف نظام التشغيل 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 أو الإصدارات الأحدث. للسماح بلمسات غير موثوق بها، يمكنك تشغيل أمر AB التالي في نافذة طرفية:

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

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

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

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

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

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

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

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