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

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

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

الأمان

يتضمّن نظام التشغيل Android 17 التحسينات التالية على أمان الأجهزة والتطبيقات.

خطة إيقاف usesClearTraffic نهائيًا

في إصدار مستقبلي، نخطّط لإيقاف العنصر usesCleartextTraffic نهائيًا. يجب أن تنقل التطبيقات التي تحتاج إلى إجراء اتصالات غير مشفَّرة (HTTP) إلى استخدام ملف إعداد أمان الشبكات، والذي يتيح لك تحديد النطاقات التي يحتاج تطبيقك إلى إجراء اتصالات cleartext بها.

يُرجى العِلم أنّ ملفات إعدادات أمان الشبكة لا تتوافق إلا مع المستويات 24 من واجهة برمجة التطبيقات والإصدارات الأحدث. إذا كان الحد الأدنى لمستوى واجهة برمجة التطبيقات في تطبيقك أقل من 24، عليك تنفيذ الإجراءَين التاليَين:

• اضبط السمة usesCleartextTraffic على true
• استخدام ملف إعدادات الشبكة

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

حظر منح معرّفات الموارد المنتظمة الضمنية

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

الحدود القصوى لمخزن المفاتيح لكل تطبيق

يجب أن تتجنّب التطبيقات إنشاء أعداد كبيرة من المفاتيح في Android Keystore، لأنّها مورد مشترك لجميع التطبيقات على الجهاز. بدءًا من Android 17، يفرض النظام حدًا أقصى لعدد المفاتيح التي يمكن أن يمتلكها التطبيق. يبلغ الحدّ الأقصى 50,000 مفتاح للتطبيقات غير التابعة للنظام التي تستهدف الإصدار 17 من نظام التشغيل Android (المستوى 37 من واجهة برمجة التطبيقات) أو الإصدارات الأحدث، و200,000 مفتاح لجميع التطبيقات الأخرى. يبلغ الحد الأقصى لعدد المفاتيح في تطبيقات النظام 200,000 مفتاح، بغض النظر عن مستوى واجهة برمجة التطبيقات الذي تستهدفه.

إذا حاول أحد التطبيقات إنشاء مفاتيح تتجاوز الحدّ الأقصى، سيتعذّر إنشاء المفاتيح وسيظهر الخطأ KeyStoreException. تحتوي سلسلة رسالة الخطأ على معلومات حول الحدّ الأقصى للمفاتيح. إذا كان التطبيق يستدعي getNumericErrorCode() بشأن الاستثناء، تعتمد القيمة المعروضة على مستوى واجهة برمجة التطبيقات الذي يستهدفه التطبيق:

• بالنسبة إلى التطبيقات التي تستهدف الإصدار 17 من نظام التشغيل Android (مستوى واجهة برمجة التطبيقات 37) أو الإصدارات الأحدث، تعرض الدالة getNumericErrorCode() القيمة الجديدة ERROR_TOO_MANY_KEYS.
• جميع التطبيقات الأخرى: تعرض getNumericErrorCode() القيمة ERROR_INCORRECT_USAGE.

تجربة المستخدم وواجهة مستخدم النظام

يتضمّن نظام التشغيل Android 17 التغييرات التالية التي تهدف إلى توفير تجربة استخدام أكثر سلاسةً وسهولةً.

استعادة مستوى رؤية محرر أسلوب الإدخال التلقائي بعد التدوير

بدءًا من Android 17، عندما تتغيّر إعدادات الجهاز (على سبيل المثال، من خلال التدوير)، ولا يعالج التطبيق هذا التغيير، لن تتم استعادة حالة ظهور طريقة الإدخال السابقة.

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

• اضبط السمة android:windowSoftInputMode على stateAlwaysVisible.
• يمكنك طلب لوحة المفاتيح البرمجية في طريقة onCreate() الخاصة بالنشاط، أو إضافة طريقة onConfigurationChanged().

المعلومات المقدَّمة

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

تقدّم لوحات اللمس أحداثًا نسبية تلقائيًا أثناء عملية التقاط المؤشر

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

في السابق، لم يكن النظام يحاول التعرّف على الإيماءات من لوحة اللمس، بل كان يرسل المواضع المطلقة للأصابع إلى التطبيق بتنسيق مشابه للمس الشاشة. إذا كان أحد التطبيقات لا يزال يتطلّب هذه البيانات المطلقة، عليه استدعاء طريقة View.requestPointerCapture(int) الجديدة مع View.POINTER_CAPTURE_MODE_ABSOLUTE بدلاً من ذلك.

الوسائط

يتضمّن نظام التشغيل Android 17 التغييرات التالية على سلوك الوسائط.

تعزيز أمان الصوت في الخلفية

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

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

لمزيد من المعلومات، بما في ذلك استراتيجيات التخفيف من المخاطر، يُرجى الاطّلاع على مقالة تعزيز أمان الصوت في الخلفية.

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

يتضمّن نظام التشغيل Android 17 التغييرات التالية لتحسين إمكانية ربط الأجهزة.

إعادة الإقران التلقائي عند فقدان ربط البلوتوث

يقدّم Android 17 ميزة إعادة الإقران التلقائي، وهي تحسين على مستوى النظام مصمّم لحلّ مشكلة فقدان اتصال البلوتوث تلقائيًا.

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

لن تحتاج معظم التطبيقات إلى تغييرات في الرموز البرمجية، ولكن على المطوّرين الانتباه إلى التغييرات التالية في سلوك حزمة بروتوكول البلوتوث:

• سياق إقران جديد: يتضمّن ACTION_PAIRING_REQUEST الآن الإضافة EXTRA_PAIRING_CONTEXT التي تسمح للتطبيقات بالتمييز بين طلب إقران عادي ومحاولة إعادة إقران تلقائية بدأها النظام.
• تعديلات مشروطة على المفاتيح: لن يتم استبدال مفاتيح الأمان الحالية إلا إذا نجحت عملية إعادة الإقران وكان الاتصال الجديد يفي بمستوى أمان الاتصال السابق أو يتجاوزه.
• تعديل توقيت الغرض: لا يتم الآن بثّ الغرض ACTION_KEY_MISSING إلا إذا فشلت محاولة إعادة الإقران التلقائية. يقلّل ذلك من معالجة الأخطاء غير الضرورية في التطبيق إذا نجح النظام في استعادة الاتصال في الخلفية.
• إشعار المستخدم: يدير النظام عملية إعادة الإقران من خلال إشعارات وطلبات حوار جديدة في واجهة المستخدم. سيُطلب من المستخدمين تأكيد محاولة إعادة الإقران للتأكّد من أنّهم على علم بإعادة الاتصال.

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

• إزالة معلومات الاتصال يدويًا من الجهاز الطرفي
• إلغاء إقران الجهاز يدويًا في: "الإعدادات" > "الأجهزة المتصلة"