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

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

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

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

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

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

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

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

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

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

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

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

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

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

manual

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

status

يعرض هذا الأمر الحالة الحالية لأداة تحديد الذاكرة. تشمل الحالة حدود الذاكرة المفروضة على العمليات المرئية وغير المرئية.

الخصوصية

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

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

Beginning with Android 17, Android is expanding its protection for SMS messages containing one-time passwords (OTP).

In previous versions of Android, this protection was primarily focused on the SMS Retriever format. Delivery of messages containing an SMS retriever hash was delayed for most apps for three hours. However, certain apps (like the default SMS handler) were exempt from the delay, and the app that owned the hash was also exempted.

Beginning with Android 17, the protection is also applied to WebOTP format messages. If an app has permission to read SMS messages but is not the intended recipient of a WebOTP message (as determined by domain verification), the message is not accessible to the app until three hours after the message's receipt. This change is intended to improve user security by ensuring that only apps associated with the domain mentioned in the message can programmatically read the verification code.

During this three hour delay, the SMS_RECEIVED_ACTION broadcast is withheld and SMS provider database queries are filtered. The SMS message is available to these apps after the delay. This change applies to all apps, regardless of their target API level.

Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.

الأمان

يتضمّن نظام التشغيل 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 ذات الصلة بدلاً من الاعتماد على النظام لمنحها.

لرصد استخدام هذه الـ intents في تطبيقك، استخدِم 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"، لأنّه مورد مشترك لجميع التطبيقات على الجهاز. بدءًا من Android 17، يفرض النظام حدًا أقصى لعدد المفاتيح التي يمكن أن يملكها التطبيق. الحدّ الأقصى هو 50,000 مفتاح للتطبيقات غير التابعة للنظام التي تستهدف Android 17 (المستوى 37 من واجهة برمجة التطبيقات) أو الإصدارات الأحدث، و200,000 مفتاح لجميع التطبيقات الأخرى. يبلغ الحدّ الأقصى للتطبيقات التابعة للنظام 200,000 مفتاح، بغض النظر عن مستوى واجهة برمجة التطبيقات الذي تستهدفه.

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

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

حظر الزيارات المكرّرة بين الملفات الشخصية

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

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

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

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

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

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

  • اضبط السمة 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 التغييرات التالية على سلوك الوسائط.

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

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

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

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

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

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

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

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

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

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

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

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

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