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

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

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

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

يتضمّن نظام التشغيل Android 17 (المستوى 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.

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

manual

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

status

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

الخصوصية

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

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

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) إلى استخدام ملف إعداد أمان الشبكات، ما يتيح لك تحديد النطاقات التي يحتاج تطبيقك إلى إجراء اتصالات cleartext بها.

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

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

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

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

في الوقت الحالي، إذا أطلق تطبيق غرضًا باستخدام معرّف موارد منتظم (URI) يتضمّن الإجراء ACTION_SEND أو ACTION_SEND_MULTIPLE أو ACTION_IMAGE_CAPTURE، يمنح النظام تلقائيًا أذونات القراءة والكتابة لمعرّف الموارد المنتظم (URI) إلى التطبيق المستهدف. بدءًا من Android 18، لن يمنح النظام هذه الأذونات تلقائيًا. لهذا السبب، ننصح بأن تمنح التطبيقات بشكل صريح أذونات عناوين 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);

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

Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own. The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps. System apps have a limit of 200,000 keys, regardless of which API level they target.

If an app attempts to create keys beyond the limit, the creation fails with a KeyStoreException. The exception's message string contains information about the key limit. If the app calls getNumericErrorCode() on the exception, the return value depends on what API level the app targets:

  • Apps targeting Android 17 (API level 37) or higher: getNumericErrorCode() returns the new ERROR_TOO_MANY_KEYS value.
  • All other apps: getNumericErrorCode() returns ERROR_INCORRECT_USAGE.

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

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

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

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

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

Beginning with Android 17, when the device's configuration changes (for example, through rotation), and this is not handled by the app itself, the previous IME visibility is not restored.

If your app undergoes a configuration change that it does not handle, and the app needs the keyboard to be visible after the change, you must explicitly request this. You can make this request in one of the following ways:

  • Set the android:windowSoftInputMode attribute to stateAlwaysVisible.
  • Programmatically request the soft keyboard in your activity's onCreate() method, or add the onConfigurationChanged() method.

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

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

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

Beginning with Android 17, if an app requests pointer capture using View.requestPointerCapture() and the user uses a touchpad, the system recognizes pointer movement and scrolling gestures from the user's touches and reports them to the app in the same way as pointer and scroll wheel movements from a captured mouse. In most cases, this removes the need for apps that support captured mice to add special handling logic for touchpads. For more details, see the documentation for View.POINTER_CAPTURE_MODE_RELATIVE.

Previously, the system did not attempt to recognize gestures from the touchpad, and instead delivered the raw, absolute finger locations to the app in a similar format to touchscreen touches. If an app still requires this absolute data, it should call the new View.requestPointerCapture(int) method with View.POINTER_CAPTURE_MODE_ABSOLUTE instead.

الوسائط

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

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

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

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

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

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

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

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

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

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

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

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

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

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