يتضمّن نظام 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 لواجهة برمجة التطبيقات)، تم تقديم مجموعة التطبيقات المقيّدة كمجموعة التطبيقات في وضع "الاستعداد" . بدايةً من نظام التشغيل Android 12، تكون هذه الحزمة نشطة بشكل تلقائي. يكون للحزمة المحظورة أدنى أولوية (وأعلى قيود) من بين جميع الحِزم. وفيما يلي الحِزم بترتيب الأولوية من الأعلى إلى الأدنى:
- نشط: يتم استخدام التطبيق حاليًا أو تم استخدامه مؤخرًا جدًا.
- مجموعة العمل: يتم استخدام التطبيق بانتظام.
- متكرر: يتم استخدام التطبيق غالبًا، ولكن ليس كل يوم.
- نادر: لا يتم استخدام التطبيق بشكل متكرر.
- محدود: يستهلك التطبيق قدرًا كبيرًا من موارد النظام أو قد يعرض سلوكًا غير مرغوب فيه.
يأخذ النظام سلوك تطبيقك في الاعتبار، بالإضافة إلى أنماط الاستخدام، لتحديد ما إذا كان سيتم وضع تطبيقك في الحزمة المحظورة.
ومن غير المرجّح أن يتم وضع تطبيقك في الحزمة المحظورة إذا كان يستخدم موارد النظام بشكل أكثر مسؤولية. ويضع النظام تطبيقك أيضًا في مجموعة أقل تقييدًا إذا تفاعل المستخدم مع تطبيقك مباشرةً.
التحقّق مما إذا كان تطبيقك مضمّنًا في الحزمة المحظورة
للتحقّق مما إذا كان النظام قد وضع تطبيقك في الحزمة المحظورة، يُرجى الاتصال بالرقم getAppStandbyBucket()
.
إذا كانت القيمة المعروضة لهذه الطريقة هي STANDBY_BUCKET_RESTRICTED
، يعني ذلك أنّ تطبيقك
في الحزمة المحظورة.
اختبار سلوك الحزمة المحظورة
لاختبار سلوك تطبيقك عندما يضع النظام تطبيقك في الحزمة المقيّدة، يمكنك نقل تطبيقك يدويًا إلى هذه الحزمة. لإجراء ذلك، نفِّذ الأمر التالي في نافذة وحدة طرفية:
adb shell am set-standby-bucket PACKAGE_NAME restricted
الأمان والخصوصية
الموقع الجغرافي التقريبي
على الأجهزة التي تعمل بنظام التشغيل Android 12 أو إصدار أحدث، يمكن للمستخدمين طلب منح تطبيقك إذنًا بالوصول إلى معلومات الموقع الجغرافي التقريبي فقط.
إذا كان تطبيقك يطلب إذن التشغيل
ACCESS_FINE_LOCATION
، يجب أيضًا طلب إذن
ACCESS_COARSE_LOCATION
للتعامل مع الحالة التي يمنح فيها المستخدم إذن الوصول إلى الموقع الجغرافي التقريبي
لتطبيقك. ويجب تضمين كلا الإذنَين في طلب ملف التشغيل واحد.
يتضمّن مربّع حوار أذونات النظام الخيارات التالية للمستخدم، كما هو موضّح في الشكل 1:
- دقيق: لإتاحة الوصول إلى معلومات عن الموقع الجغرافي الدقيق
- تقريبي: يتيح الوصول إلى معلومات الموقع الجغرافي التقريبي فقط.
خيارات إيقاف/تشغيل الميكروفون والكاميرا
تتيح الأجهزة المتوافقة التي تعمل بنظام التشغيل Android 12 أو الإصدارات الأحدث للمستخدمين تفعيل إذن الوصول إلى الكاميرا والميكروفون وإيقافه لجميع التطبيقات على الجهاز، وذلك من خلال النقر على خيار تبديل واحد. يمكن للمستخدمين الوصول إلى الخيارات القابلة للتبديل من الإعدادات السريعة، كما هو موضح في الشكل 1، أو من شاشة الخصوصية في إعدادات النظام.
اطّلِع على مزيد من المعلومات عن
أزرار الإيقاف/التفعيل هذه وكيفية التأكّد مما إذا كان تطبيقك يتّبع أفضل الممارسات المتعلّقة بأذونات
CAMERA
و
RECORD_AUDIO
.
مؤشرات استخدام الميكروفون والكاميرا
على الأجهزة التي تعمل بنظام التشغيل Android 12 أو إصدار أحدث، يظهر رمز في شريط الحالة عندما يستخدم أحد التطبيقات الميكروفون أو الكاميرا.
اطّلِع على مزيد من المعلومات عن هذين
المؤشّرين وكيفية
التحقّق من اتّباع تطبيقك لأفضل الممارسات المتعلّقة بإذنَي CAMERA
و
RECORD_AUDIO
.
إذن الوصول إلى حزمة الأذونات
على الأجهزة التي تعمل بالإصدار 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
. تعذَّر فك التشفير في وقت سابق.يتم إعداد رموز التشفير Galois/Counter Mode (GCM) باستخدام حجم مختلف عن 12 بايت. يتطلّب تطبيق
GcmParameterSpec
في Conscrypt إعدادًا بحجم 12 بايت، وهو ما يوصي به المعهد الوطني للمعايير والتكنولوجيا (NIST).
إشعارات الوصول إلى الحافظة
في الإصدار 12 من نظام التشغيل Android والإصدارات الأحدث، عندما يستدعي أحد التطبيقات getPrimaryClip()
للوصول إلى بيانات المقتطف من تطبيق مختلف لأول مرة، يتم إرسال رسالة فورية تُعلم المستخدم بالوصول إلى الحافظة.
يحتوي النص داخل رسالة الإعلام المنبثق على التنسيق التالي:
APP pasted from your clipboard.
معلومات عن النص في وصف المقطع
على نظام التشغيل Android 12 والإصدارات الأحدث، يمكن لتطبيق getPrimaryClipDescription()
رصد التفاصيل التالية:
- نص ذو نمط معيّن، باستخدام
isStyledText()
. - تصنيفات مختلفة للنص، مثل عناوين URL، باستخدام
getConfidenceScore()
لا يمكن للتطبيقات إغلاق مربّعات حوار النظام
لتحسين قدرة المستخدم على التحكّم عند التفاعل مع التطبيقات والنظام، تم إيقاف ميزة
ACTION_CLOSE_SYSTEM_DIALOGS
intent action نهائيًا اعتبارًا من 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 أو الإصدارات الأقدم ويعرض نافذة في أعلى درج الإشعارات.
يستهدف تطبيقك الإصدار 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
الاستثناءات
في الحالات التالية، يُسمح بلمسات "المرور":
- التفاعلات داخل تطبيقك: يعرض تطبيقك العنصر المتراكب، ولا يظهر العنصر المتراكب إلا عندما يتفاعل المستخدم مع تطبيقك.
النوافذ الموثوق بها: وتشمل هذه النوافذ (على سبيل المثال لا الحصر) ما يلي:
النوافذ غير المرئية: طريقة عرض الجذر في النافذة هي
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()
. تُحيل واجهات برمجة التطبيقات Activity APIs في 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);
إمكانية الاتصال
تعديلات على Passpoint
تمت إضافة واجهات برمجة التطبيقات التالية في Android 12:
isPasspointTermsAndConditionsSupported()
: الأحكام والشروط هي ميزة Passpoint تسمح بعمليات نشر الشبكة لاستبدال المداخل المشروطة الوصول إليها غير الآمنة، التي تستخدم شبكات مفتوحة، بشبكة Passpoint آمنة. يتم عرض إشعار على المستخدم عند طلب قبول الأحكام والشروط. بالنسبة إلى التطبيقات التي تقترح شبكات Passpoint التي تخضع لأحكام وشروط معيّنة، يجب أن تتصل أولاً بواجهة برمجة التطبيقات هذه للتأكّد من أنّ الجهاز يتيح هذه الميزة. إذا لم يكن الجهاز متوافقًا مع هذه الميزة، لن يتمكّن من الاتصال بهذه الشبكة، ويجب اقتراح شبكة بديلة أو شبكة قديمة.isDecoratedIdentitySupported()
: عند المصادقة على الشبكات التي تتضمّن زخرفة بادئة، تسمح بادئة الهوية المزخرفة لمشغّلي الشبكة بتعديل معرّف الوصول إلى الشبكة (NAI) لإجراء توجيه صريح من خلال عدة خوادم وكيلة داخل شبكة إدارة الهوية وإمكانية الوصول (AAA) (اطّلِع على RFC 7542 للحصول علىمزيد من المعلومات حول هذا الموضوع).ينفِّذ Android 12 هذه الميزة للتوافق مع مواصفات WBA لإضافات PPS-MO. يجب أن تستدعي التطبيقات التي تقترح شبكات نقطة مرور تتطلب هوية مزيّنة واجهة برمجة التطبيقات هذه أولاً للتأكّد من أنّ الجهاز يتيح هذه الميزة. إذا لم يكن الجهاز متوافقًا مع هذه الميزة، لن يتم تزيين الهوية وقد يتعذّر إجراء المصادقة على الشبكة.
لإنشاء اقتراح Passpoint، يجب أن تستخدم التطبيقات فئات
PasspointConfiguration
و
Credential
و
HomeSp
. تصف هذه
الفئات الملف الشخصي لبرنامج Passpoint، والذي تم تحديده في مواصفات Wi-Fi Alliance
Passpoint
.
لمزيد من المعلومات، يُرجى الاطّلاع على واجهة برمجة تطبيقات اقتراح Wi-Fi للاتصال بالإنترنت.
قيود محدَّثة على الواجهات غير المتوفّرة في حِزم SDK
يتضمّن نظام التشغيل Android 12 قوائم معدَّلة للواجهات غير المتوافقة مع حِزم تطوير البرامج (SDK) والتي تم حظرها استنادًا إلى التعاون مع مطوّري تطبيقات Android وأحدث الاختبار الداخلي. نحرص كلما أمكن ذلك على توفير بدائل عامة قبل حظر الواجهات غير المستندة إلى حزمة SDK.
إذا لم يكن تطبيقك يستهدف الإصدار 12 من نظام التشغيل Android، قد لا تؤثر بعض هذه التغييرات في تطبيقك بشكل فوري. ومع أنّه يمكنك حاليًا استخدام بعض واجهات غير حزمة SDK (حسب مستوى واجهة برمجة التطبيقات المستهدَف في تطبيقك)، فإنّ استخدام أي طريقة أو حقل غير حزمة SDK ينطوي دائمًا على مخاطر عالية لتعطُّل تطبيقك.
إذا لم تكن متأكّدًا مما إذا كان تطبيقك يستخدم واجهات غير متوفّرة في حزمة SDK، يمكنك اختبار تطبيقك لمعرفة ذلك. إذا كان تطبيقك يعتمد على واجهات غير متوفرة في حزمة SDK، عليك بدء التخطيط لنقل البيانات إلى بدائل حِزم SDK. ومع ذلك، ندرك أنّ بعض التطبيقات لديها حالات استخدام صالحة لاستخدام واجهات غير متوفرة في حزمة SDK. إذا لم تتمكّن من العثور على بديل لاستخدام واجهة غير متوفرة في حزمة SDK لميزة في تطبيقك، يجب طلب واجهة برمجة تطبيقات عامة جديدة.
لمزيد من المعلومات عن التغييرات في هذا الإصدار من Android، اطّلِع على التعديلات على قيود واجهات المستخدم غير المستندة إلى حزمة SDK في Android 12. للاطّلاع على مزيد من المعلومات حول الواجهات غير المتوفّرة في حزمة SDK بشكل عام، اطّلِع على القيود المفروضة على الواجهات غير المتوفّرة في حزمة SDK.