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

يتضمّن الإصدار 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 التغييرات التالية لتحسين خصوصية المستخدم.

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

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

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

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

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

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

الأمان

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

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

In a future release, we plan to deprecate the usesCleartextTraffic element. Apps that need to make unencrypted (HTTP) connections should migrate to using a network security configuration file, which lets you specify which domains your app needs to make cleartext connections to.

Be aware that network security configuration files are only supported on API levels 24 and higher. If your app has a minimum API level lower than 24, you should do both of the following:

  • Set the usesCleartextTraffic attribute to true
  • Use a network configuration file

If your app's minimum API level is 24 or higher, you can use a network configuration file and you don't need to set 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.

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

Beginning with Android 17, cross-profile loopback traffic is no longer permitted by default. Loopback traffic within the same profile is not affected. This change applies to all apps running on Android 17 or higher, regardless of what API level the app targets.

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

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

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

Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.

If the app tries to call audio APIs while the app is not in a valid lifecycle, the audio playback and volume change APIs fail silently without throwing an exception or providing a failure message. The audio focus API fails with the result code AUDIOFOCUS_REQUEST_FAILED.

For more information, including mitigation strategies, see Background audio hardening.

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

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

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

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

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

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

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

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

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