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

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

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

الوظيفة الأساسية

يتضمّن الإصدار 17 من نظام التشغيل Android (المستوى 37 لواجهة برمجة التطبيقات) التغييرات التالية التي تعدّل أو توسّع نطاق الإمكانات الأساسية المختلفة لنظام التشغيل Android.

الحدود القصوى لذاكرة التطبيقات

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

يمكنك تحديد ما إذا كانت جلسة تطبيقك قد تأثّرت من خلال استدعاء getDescription في ApplicationExitInfo. إذا كان تطبيقك متأثرًا، سيكون سبب الخروج هو REASON_OTHER وسيحتوي الوصف على السلسلة "MemoryLimiter:AnonSwap" بالإضافة إلى معلومات أخرى. يمكنك أيضًا استخدام إنشاء الملفات الشخصية المستند إلى المشغّلات مع TRIGGER_TYPE_ANOMALY للحصول على لقطات لأجزاء من الذاكرة يتم جمعها عند الوصول إلى الحدّ الأقصى للذاكرة.

يوفّر مستند إدارة ذاكرة تطبيقك معلومات لمساعدتك في تشخيص مشاكل الذاكرة في تطبيقك وتحسين استهلاك الموارد.

اختبار سلوك تطبيقك في ظل قيود الذاكرة

يمكنك استخدام Android Debug Bridge (adb) لضبط حدود الذاكرة أو إيقافها على أي جهاز يفرضها. يوفّر أمر واجهة الأوامر am ثلاثة أوامر فرعية لتعديل حدود الذاكرة. (ليس لهذه الأوامر أي تأثير على جهاز لا يفرض حدودًا على الذاكرة).

  • am memory-limiter ignore <uid>|none|all
  • am memory-limiter manual <pid> <limit>|max|none
  • am memory-limiter status
ignore

يوجّه هذا الإعداد أداة تقييد الذاكرة لتجاهل بعض العمليات أو جميعها. يؤدي تمرير UID (رقم تعريف مستخدم Android) إلى توجيه أداة تقييد الذاكرة إلى تجاهل إجراء التنفيذ على جميع العمليات المرتبطة برقم التعريف هذا. يمكنك أيضًا تمرير all (تجاهُل جميع التطبيقات) أو none (عدم تجاهُل أي تطبيقات). يؤدي تمرير none إلى إلغاء أي طلبات سابقة إلى am memory-limiter ignore.

إذا طلبت من أداة تقييد الذاكرة تجاهل معرّف UID، سيظل بإمكانك تطبيق حدّ أقصى للذاكرة يدويًا على عملية داخل التطبيق من خلال استدعاء am memory-limiter manual.

manual

يوجّه هذا الأمر النظام إلى فرض قيود على الذاكرة في العملية التي تحمل معرّف العملية (PID) المحدّد. يتم تحديد قيود الذاكرة كعدد صحيح بالميغابايت، على سبيل المثال، يشير تمرير 30 إلى أنّ العملية تقتصر على 30 ميغابايت من الذاكرة. يؤدي ضبط القيمة على max إلى إزالة جميع حدود الذاكرة في هذه العملية. يؤدي تمرير القيمة none إلى إزالة أي حدود قصوى تم ضبطها يدويًا على العملية، ما يؤدي إلى استعادة الحدّ الأقصى التلقائي للنظام (إن توفّر).

status

يُبلغ عن الحالة الحالية لمحدِّد الذاكرة. وتتضمّن الحالة حدود الذاكرة المفروضة على العمليات المرئية وغير المرئية.

الخصوصية

يتضمّن Android 17 التغييرات التالية لتحسين خصوصية المستخدم.

الحماية من خلال كلمة المرور الصالحة لمرة واحدة (OTP) عبر الرسائل القصيرة

اعتبارًا من الإصدار 17 من نظام التشغيل Android، سيتم توسيع نطاق حماية الرسائل القصيرة التي تحتوي على كلمات مرور صالحة لمرة واحدة (OTP).

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

بدءًا من الإصدار Android 17، يتم تطبيق الحماية أيضًا على الرسائل بتنسيق WebOTP. إذا كان التطبيق يملك إذنًا بقراءة رسائل SMS ولكنّه ليس المستلِم المقصود لرسالة WebOTP (كما هو محدّد من خلال عملية التحقّق من النطاق)، لن يتمكّن التطبيق من الوصول إلى الرسالة إلا بعد مرور ثلاث ساعات على استلامها. يهدف هذا التغيير إلى تحسين أمان المستخدم من خلال ضمان أنّ التطبيقات المرتبطة بالنطاق المذكور في الرسالة هي فقط التي يمكنها قراءة رمز التحقّق آليًا.

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

يُستثنى من هذا التأخير بعض التطبيقات، مثل تطبيق المساعد التلقائي للرسائل القصيرة والتطبيقات المصاحبة للأجهزة المتصلة وما إلى ذلك. يجب أن تنتقل جميع التطبيقات التي تعتمد على قراءة رسائل SMS لاستخراج كلمات المرور الصالحة لمرة واحدة إلى استخدام واجهات برمجة التطبيقات SMS Retriever أو SMS User Consent لضمان استمرار عملها.

الأمان

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

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

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

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

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

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

تقييد أذونات الوصول الضمنية إلى معرّفات الموارد المنتظمة (URI)

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

لاكتشاف استخدام هذه الأهداف في تطبيقك، استخدِم StrictMode مع detectImplicitUriPermissionGrant() لتشغيل انتهاك:

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

بدلاً من ذلك، يمكنك مراقبة الاستثناءات المسجّلة التي تحتوي على الرسالة Please set the grant explicitly in the app التي تظهر عندما يمنح النظام الإذن ضمنيًا. يمكنك مراقبة هذه السجلّات باستخدام أمر adb التالي:

adb logcat | grep "Please set the grant explicitly in the app"

لمنح الأذونات اللازمة صراحةً، أضِف العلامة FLAG_GRANT_READ_URI_PERMISSION إلى الغرضَين ACTION_SEND وACTION_SEND_MULTIPLE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

أدرِج علامتَي FLAG_GRANT_READ_URI_PERMISSION وFLAG_GRANT_WRITE_URI_PERMISSION لطلبات ACTION_IMAGE_CAPTURE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

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

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

جارٍ استعادة مستوى الرؤية التلقائي لـ IME بعد التدوير

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

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

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

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

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

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

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

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

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

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

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