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

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

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

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

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

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

Android 17 introduces app memory limits based on the device's total RAM to create a more stable and deterministic environment for your apps and Android users. These limits focus on memory leaks and other outliers before they trigger system-wide instability resulting in UI stuttering, higher battery drain, and apps being killed. While we anticipate minimal impact on the vast majority of app sessions, we recommend the following memory best practices, including establishing a baseline for memory.

You can determine if your app session was impacted by calling getDescription in ApplicationExitInfo; if your app was affected, the exit reason will be REASON_OTHER and the description will contain the string "MemoryLimiter:AnonSwap" along with other information. You can also use trigger-based profiling with TRIGGER_TYPE_ANOMALY to get heap dumps that are collected when the memory limit is hit.

The Manage your app's memory documentation gives information to help you diagnose your app's memory issues and optimize its resource consumption.

Test your app's behavior under the memory constraints

You can use Android Debug Bridge (adb) to adjust or disable the memory limits on any device that imposes them. The shell command am provides three subcommands to adjust the memory limits. (These commands have no effect on a device which does not impose memory limits.)

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

Instructs the memory limiter to ignore some or all processes. Passing a UID (Android User ID) instructs the memory limiter to ignore enforcement on all processes associated with that UID. You can also pass all (ignore all apps) or none (do not ignore any apps). Passing none overrides any previous calls to am memory-limiter ignore.

If you instruct the memory limiter to ignore a UID, you can still apply a manual memory limit to a process within the app by calling am memory-limiter manual.

manual

Instructs the system to impose a memory constraint on the process with the specified PID (Process ID). The memory constraint is specified as an integer number of MB; for example, passing 30 specifies that the process is limited to 30 MB of memory. Passing max removes all memory limits on that process. Passing none removes any manual limits set on the process, restoring the system's default limit (if any).

status

Reports the current status of the memory limiter. The status includes the memory limits imposed on visible and non-visible processes.

الخصوصية

يتضمّن نظام التشغيل 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 نهائيًا

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

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

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

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

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

Currently, if an app launches an intent with a URI that has the action ACTION_SEND, ACTION_SEND_MULTIPLE, or ACTION_IMAGE_CAPTURE, the system automatically grants the read and write URI permissions to the target app. Starting in Android 18, the system will no longer automatically grant these permissions. For this reason, we recommend that apps explicitly grant the relevant URI permissions instead of relying on the system to grant them.

To detect the usage of these intents in your app, use StrictMode with detectImplicitUriPermissionGrant() to trigger a violation:

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);

Alternatively, you can monitor for logged exceptions containing the message Please set the grant explicitly in the app that appears when system implicitly sets the grant. You can monitor for these logs using the following adb command:

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

To explicitly grant the necessary permissions, add the FLAG_GRANT_READ_URI_PERMISSION flag to ACTION_SEND and ACTION_SEND_MULTIPLE intents:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Include both FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION flags for ACTION_IMAGE_CAPTURE intents:

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، لأنّها مورد مشترك لجميع التطبيقات على الجهاز. بدءًا من 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.

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

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 التلقائي بعد التدوير

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

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

  • اضبط السمة 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 إلا إذا تعذّرت محاولة إعادة الاقتران التلقائي. يؤدي ذلك إلى تقليل معالجة الأخطاء غير الضرورية في التطبيق إذا استعاد النظام عملية الربط بنجاح في الخلفية.
  • إشعار المستخدم: يدير النظام عملية إعادة الربط من خلال إشعارات واجهة المستخدم الجديدة ومربّعات الحوار. سيُطلب من المستخدمين تأكيد محاولة إعادة الربط للتأكّد من أنّهم على علم بعملية إعادة الاتصال.

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

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