يتضمّن نظام Android 12 الأساسي تغييرات في السلوك قد
تؤثر على تطبيقك. تنطبق التغييرات التالية في السلوك على جميع التطبيقات عند
تشغيلها على Android 12، بغض النظر عن targetSdkVersion
. يجب
اختبار تطبيقك ثم تعديله حسب الحاجة لتفعيل هذه الميزات بشكل صحيح، حيث
ينطبق ذلك.
احرص أيضًا على مراجعة قائمة تغييرات السلوك التي تؤثر فقط على التطبيقات التي تستهدف Android 12.
تجربة المستخدم
تأثير التمرير الزائد
على الأجهزة التي تعمل بالإصدار 12 من نظام التشغيل Android والإصدارات الأحدث، يتغيّر السلوك المرئي لأحداث التمرير السريع .
في نظام التشغيل Android 11 والإصدارات الأقدم، يؤدي حدث التمرير السريع إلى أن تشعّ عناصر المحتوى بالضوء. وفي نظام التشغيل Android 12 والإصدارات الأحدث، تتمدد عناصر المحتوى وترتجّع عند حدوث حدث السحب، وتتم رميها وترتجّع عند حدوث حدث الرمي.
لمزيد من المعلومات، يمكنك الاطّلاع على دليل إيقاف التمرير باستخدام الإيماءات.
شاشات بداية التطبيقات
إذا سبق لك تطبيق شاشة بداية مخصّصة في نظام التشغيل Android 11 أو الإصدارات الأقدم، عليك نقل تطبيقك إلى واجهة برمجة تطبيقات SplashScreen
لضمان عرضه بشكل صحيح بدءًا من نظام التشغيل Android 12. سيؤدي عدم نقل بيانات تطبيقك إلى
تدهّور تجربة تشغيل التطبيق أو حدوث مشاكل غير مقصودة.
للحصول على تعليمات، يمكنك الاطّلاع على نقل طريقة تنفيذ شاشة البداية الحالية إلى الإصدار Android 12.
بالإضافة إلى ذلك، اعتبارًا من Android 12، يطبّق النظام دائمًا شاشة البداية التلقائية الجديدة لنظام Android
عند بدء التشغيل على البارد وإعادة التشغيل البطيء لجميع التطبيقات.
يتم إنشاء شاشة البداية التلقائية هذه للنظام تلقائيًا باستخدام عنصر رمز مشغّل التطبيق
وwindowBackground
لموضوعك (إذا كان لونًا واحدًا).
لمزيد من التفاصيل، يمكنك الاطّلاع على دليل مطوّري شاشات البداية.
حلّ النية على الويب
اعتبارًا من الإصدار 12 من نظام التشغيل Android (المستوى 31 لواجهة برمجة التطبيقات)، لا يتم تحويل النية العامة للويب إلى نشاط في تطبيقك إلا إذا تمت الموافقة على تطبيقك للاستخدام مع النطاق المحدد المضمّن في نية الويب هذه. إذا لم تتم الموافقة على تطبيقك في النطاق، ينتقل Web intent إلى تطبيق المتصفّح التلقائي لدى المستخدم بدلاً من ذلك.
يمكن للتطبيقات الحصول على هذه الموافقة من خلال تنفيذ أحد الإجراءات التالية:
إثبات ملكية النطاق باستخدام روابط تطبيقات Android.
في التطبيقات التي تستهدف الإصدار 12 من نظام التشغيل Android أو الإصدارات الأحدث، يغيِّر النظام طريقة التحقّق تلقائيًا من روابط تطبيقات Android في تطبيقك. في فلاتر الغرض في تطبيقك، تحقّق من تضمين فئة
BROWSABLE
وتوافق مع المخطّطhttps
.على نظام التشغيل Android 12 أو الإصدارات الأحدث، يمكنك التحقّق يدويًا من روابط تطبيقات Android الخاصة بتطبيقك لاختبار مدى تأثير هذا المنطق المُعدَّل على تطبيقك.
اطلب من المستخدم ربط تطبيقك بال النطاق في إعدادات النظام.
إذا كان تطبيقك يستدعي تنفيذ أهداف ويب، يمكنك إضافة طلب أو مربّع حوار يطلب من المستخدم تأكيد الإجراء.
تحسينات في الوضع المجسم للتنقّل بالإيماءات
يجمع نظام التشغيل Android 12 السلوك الحالي لتسهيل تنفيذ المستخدمين لأوامر التنقّل باستخدام الإيماءات أثناء استخدام الوضع immersive. بالإضافة إلى ذلك، يوفر Android 12 سلوك التوافق مع الإصدارات السابقة للوضع المُدمج .
Display#getRealSize وgetRealMetrics: الإيقاف النهائي والقيود
تتوفّر أجهزة Android بأشكال مختلفة، مثل الشاشات الكبيرة
والأجهزة اللوحية والأجهزة القابلة للطي. لعرض المحتوى بشكل مناسب لكل جهاز،
يحتاج تطبيقك إلى تحديد حجم الشاشة أو العرض. وبمرور الوقت، قدّم Android واجهات برمجة تطبيقات مختلفة لاسترداد هذه المعلومات. في Android 11، طرحنا واجهة برمجة التطبيقات WindowMetrics
وأوقِفنا هذه الطرق نهائيًا:
في نظام التشغيل Android 12، سنواصل اقتراح استخدام WindowMetrics
، وسيتم إيقاف الطرق التالية نهائيًا:
للتخفيف من سلوك التطبيقات التي تستخدم واجهات برمجة التطبيقات للعرض لاسترداد
حدود التطبيق، يقيّد نظام 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 ثوانٍ، مع توفّر بعض الاستثناءات. يمنح هذا التغيير فرصة للمهام القصيرة الأجل لإكمالها قبل ظهور إشعاراتها.
الأداء
حزمة التطبيقات المحظورة في وضع الاستعداد
قدّم نظام Android 11 (المستوى 30 لواجهة برمجة التطبيقات) الحزمة المحظورة كحزمة تطبيقات في وضع الاستعداد. بدءًا من الإصدار 12 من Android، يكون هذا الحزمة نشطًا تلقائيًا. يكون للحزمة المحظورة أدنى أولوية (وأعلى قيود) من بين جميع الحِزم. وفيما يلي الحِزم بترتيب الأولوية من الأعلى إلى الأدنى:
- نشط: التطبيق قيد الاستخدام حاليًا أو تم استخدامه مؤخرًا.
- مجموعة العمل: يتم استخدام التطبيق بانتظام.
- متكرر: يتم استخدام التطبيق غالبًا، ولكن ليس كل يوم.
- نادر: لا يتم استخدام التطبيق بشكل متكرر.
- محدود: يستهلك التطبيق قدرًا كبيرًا من موارد النظام أو قد يعرض سلوكًا غير مرغوب فيه.
يأخذ النظام سلوك تطبيقك في الاعتبار، بالإضافة إلى أنماط الاستخدام، لتحديد ما إذا كان سيتم وضع تطبيقك في الحزمة المحظورة.
من غير المرجّح أن يتم وضع تطبيقك في المجموعة المحظورة إذا كان يستخدم موارد النظام بمسؤولية أكبر. ويضع النظام تطبيقك أيضًا في مجموعة أقل تقييدًا إذا تفاعل المستخدم مع تطبيقك مباشرةً.
التحقّق مما إذا كان تطبيقك مضمّنًا في الحزمة المحظورة
للتحقّق مما إذا كان النظام قد وضع تطبيقك في الحزمة المحظورة، يُرجى الاتصال بالرقم 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
. تعذّر تشغيل Conscrypt في وقت سابق.يمكنك إعداد رموز Galaxy/وضع العد التنازلي (GCM) باستخدام حجم آخر أكبر من 12 بايت. يتطلّب تنفيذ مكتبة Conscrypt لخوارزمية
GcmParameterSpec
عملية initialization تبلغ 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
. إذا كان تطبيقك يستهدف الإصدار 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.
الاستثناءات
في الحالات التالية، سيظل بإمكان التطبيق إغلاق مربّعات حوار النظام على الإصدار Android 12 أو الإصدارات الأحدث:
- يُجري تطبيقك اختبار instrumentation .
يستهدف تطبيقك الإصدار 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
اختبار التغيير
يتم تلقائيًا حظر اللمسات غير الموثوق بها على الأجهزة التي تعمل بالإصدار 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 آمنة. يظهر إشعار للمستخدم عندما تكون الأحكام والشروط مطلوبة. يجب أن تطلب التطبيقات التي تقترح شبكات نقطة المرور المُحاطة بالأحكام والشروط واجهة برمجة التطبيقات هذه أولاً للتأكّد من أنّ الجهاز يوفّر هذه الإمكانية. إذا لم يكن الجهاز متوافقًا مع هذه الميزة، لن يتمكّن من الاتصال بهذه الشبكة، ويجب اقتراح شبكة بديلة أو شبكة قديمة.isDecoratedIdentitySupported()
: عند المصادقة على الشبكات التي تتضمّن زخرفة بادئة، تسمح بادئة الهوية المزخرفة لمشغّلي الشبكة بتعديل معرّف الوصول إلى الشبكة (NAI) لإجراء توجيه صريح من خلال عدة خوادم وكيلة داخل شبكة إدارة الهوية وإمكانية الوصول (AAA) (اطّلِع على RFC 7542 للحصول علىمزيد من المعلومات حول هذا الموضوع).ينفِّذ Android 12 هذه الميزة للتوافق مع مواصفات WBA لإضافات PPS-MO. يجب أن تستدعي التطبيقات التي تقترح شبكات نقطة مرور تتطلب هوية مزيّنة واجهة برمجة التطبيقات هذه أولاً للتأكّد من أنّ الجهاز يتيح هذه الميزة. إذا لم يكن الجهاز متوافقًا مع هذه الميزة، لن يتم تزيين الهوية وقد يتعذّر إجراء المصادقة على الشبكة.
لإنشاء اقتراح "نقطة مرور"، يجب أن تستخدم التطبيقات الصفوف
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).