التغييرات في السلوك: التطبيقات التي تستهدف الإصدار 15 من نظام التشغيل Android أو الإصدارات الأحدث

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

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

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

يعدّل Android 15 القدرات الأساسية المختلفة لنظام Android أو يوسّعها.

التغييرات على الخدمات التي تعمل في المقدّمة

سنُجري التغييرات التالية على الخدمات التي تعمل في المقدّمة ضمن الإصدار 15 من نظام التشغيل Android.

• نوع الخدمة التي تعمل في المقدّمة لمعالجة الوسائط الجديدة
• القيود المفروضة على BOOT_COMPLETED جهاز استقبال البث الذي يستخدم الخدمات التي تعمل في المقدّمة

سلوك مهلة مزامنة البيانات التي تعمل في المقدّمة

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

يسمح النظام بتشغيل خدمات dataSync للتطبيق لمدة 6 ساعات خلال فترة 24 ساعة، وبعدها يطلب النظام طريقة Service.onTimeout(int, int) خدمة التشغيل (التي تم إطلاقها في Android 15). في الوقت الحالي، لدى الخدمة بضع ثوانٍ للاتصال Service.stopSelf(). عند استدعاء Service.onTimeout()، لا تُعتبر الخدمة خدمة تعمل في المقدّمة. إذا لم تستدعي الخدمة Service.stopSelf()، سيحدث عطل مع رسالة الخطأ هذه: "لم تتوقف خدمة <fgs_type> التي تعمل في المقدّمة خلال مهلتها: <component_name>". في الإصدار التجريبي 2، تظهر رسالة الخطأ على أنّها حالة ANR، ولكن في إصدار تجريبي مستقبلي، ستطرح رسالة الخطأ هذه استثناءًا مخصّصًا.

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

1. اطلب من خدمتك تنفيذ طريقة Service.onTimeout(int, int) الجديدة. عندما يتلقّى تطبيقك معاودة الاتصال، احرص على الاتصال برقم stopSelf() خلال بضع ثوانٍ. (إذا لم توقف التطبيق على الفور، سيفشل النظام.)
2. يُرجى التأكّد من عدم تشغيل خدمات dataSync في تطبيقك لمدة تزيد عن 6 ساعات إجمالاً في أي فترة 24 ساعة (ما لم يتفاعل المستخدم مع التطبيق، ويعيد ضبط الموقّت).
3. بدء الخدمات التي تعمل في المقدّمة في dataSync فقط كنتيجة لتفاعل مباشر من المستخدم، وبما أنّ تطبيقك يعمل في المقدّمة عند بدء الخدمة، ستكون مدة عمل الخدمة الست ساعات كاملة بعد تشغيل التطبيق في الخلفية.
4. بدلاً من استخدام خدمة dataSync التي تعمل في المقدّمة، يمكنك استخدام واجهة برمجة تطبيقات بديلة.

إذا تم تشغيل خدمات dataSync التي تعمل في المقدّمة في تطبيقك لمدة 6 ساعات خلال آخر 24 ساعة، لا يمكنك بدء خدمة dataSync أخرى تعمل في المقدّمة، ما لم يُحضر المستخدم تطبيقك إلى المقدّمة (ما يؤدي إلى إعادة ضبط الموقّت). إذا حاولت بدء خدمة أخرى تعمل في المقدّمة من أجل dataSync، يعرض النظام ForegroundServiceStartNotAllowedException مع رسالة خطأ مثل "تم استنفاد الوقت المحدَّد مسبقًا لمزامنة البيانات لنوع الخدمة التي تعمل في المقدّمة".

نوع خدمة تعمل في المقدّمة لمعالجة الوسائط الجديدة

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

يسمح النظام بتشغيل خدمات mediaProcessing للتطبيق لمدة 6 ساعات خلال 24 ساعة، وبعدها يطلب النظام طريقة Service.onTimeout(int, int) لخدمة التشغيل (التي تم إطلاقها في Android 15). في الوقت الحالي، لدى الخدمة بضع ثوانٍ للاتصال Service.stopSelf(). إذا لم تستدعي الخدمة Service.stopSelf()، سيحدث عطل مع رسالة الخطأ هذه: "لم تتوقف خدمة <fgs_type> التي تعمل في المقدّمة خلال مهلتها: <component_name>". في الإصدار التجريبي 2، تظهر رسالة الخطأ على أنها خطأ ANR، ولكن في إصدار تجريبي مستقبلي، ستطرح رسالة الخطأ هذه استثناءً مخصصًا.

لتجنُّب حدوث خطأ ANR، يمكنك تنفيذ أحد الإجراءات التالية:

1. اطلب من خدمتك تنفيذ طريقة Service.onTimeout(int, int) الجديدة. عندما يتلقّى تطبيقك معاودة الاتصال، احرص على الاتصال برقم stopSelf() خلال بضع ثوانٍ. (إذا لم توقف التطبيق على الفور، سيفشل النظام.)
2. عليك التأكّد من عدم تشغيل خدمات mediaProcessing في تطبيقك لمدة تزيد عن 6 ساعات إجمالاً في أي فترة 24 ساعة (ما لم يتفاعل المستخدم مع التطبيق، ويُعيد ضبط الموقّت).
3. بدء الخدمات التي تعمل في المقدّمة في mediaProcessing فقط كنتيجة لتفاعل مباشر من المستخدم، وبما أنّ تطبيقك يعمل في المقدّمة عند بدء الخدمة، ستكون مدة عمل الخدمة الست ساعات كاملة بعد تشغيل التطبيق في الخلفية.
4. بدلاً من استخدام خدمة mediaProcessing التي تعمل في المقدّمة، يمكنك استخدام واجهة برمجة تطبيقات بديلة، مثل WorkManager.

إذا تم تشغيل خدمات mediaProcessing التي تعمل في المقدّمة ضمن تطبيقك لمدة 6 ساعات خلال آخر 24 ما من، لن تتمكّن من بدء خدمة mediaProcessing أخرى تعمل في المقدّمة، إلا إذا أحضر المستخدم تطبيقك إلى المقدّمة (ما أدّى إلى إعادة ضبط الموقّت). إذا حاولت بدء خدمة mediaProcessing أخرى تعمل في المقدّمة، يعرض النظام الرسالة ForegroundServiceStartNotAllowedException مع ظهور رسالة خطأ، مثل "تم استنفاد الوقت المحدَّد مسبقًا بشأن نوع الخدمة التي تعمل في المقدّمة "mediaProcessing".

لمزيد من المعلومات عن نوع الخدمة mediaProcessing، يمكنك الاطّلاع على التغييرات على أنواع الخدمات التي تعمل في المقدّمة لنظام Android 15: معالجة الوسائط.

القيود المفروضة على BOOT_COMPLETED جهاز استقبال البث الذي يستخدم الخدمات التي تعمل في المقدّمة

هناك قيود جديدة على أجهزة استقبال البث BOOT_COMPLETED التي تشغِّل الخدمات التي تعمل في المقدّمة. لا يُسمح لأجهزة استقبال BOOT_COMPLETED بتشغيل الأنواع التالية من الخدمات التي تعمل في المقدّمة:

• dataSync
• camera
• mediaPlayback
• phoneCall
• mediaProjection
• microphone (تم فرض هذا الشرط على microphone منذ Android 14)

إذا حاول مستلِم BOOT_COMPLETED تشغيل أي من هذه الأنواع من الخدمات التي تعمل في المقدّمة، يطرح النظام ForegroundServiceStartNotAllowedException.

القيود المفروضة على بدء الخدمات التي تعمل في المقدّمة إذا كان أحد التطبيقات يحمل إذن "SYSTEM_ALERT_WINDOW"

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

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

إذا حاول تطبيقك بدء خدمة تعمل في المقدّمة من الخلفية بدون استيفاء هذه المتطلبات الجديدة (ولم يكن له استثناء آخر)، سيطرح النظام ForegroundServiceStartNotAllowedException.

إذا أعلن تطبيقك عن إذن SYSTEM_ALERT_WINDOW وأطلق الخدمات التي تعمل في المقدّمة من الخلفية، قد يتأثّر بهذا التغيير. إذا حصل تطبيقك على ForegroundServiceStartNotAllowedException، تحقّق من ترتيب عمليات التطبيق وتأكَّد من أنّ تطبيقك يتضمّن نافذة نشطة على سطح الفيديو قبل أن يحاول بدء خدمة تعمل في المقدّمة من الخلفية. يمكنك التحقّق ممّا إذا كانت نافذة التراكب مرئية حاليًا من خلال طلب View.getWindowVisibility()، أو يمكنك إلغاء View.onWindowVisibilityChanged() لتلقّي إشعارات كلما تغيّرت مستوى الرؤية.

التغييرات التي تطرأ على الحالات التي يمكن فيها للتطبيقات تعديل الحالة العامة لوضع "عدم الإزعاج"

لم يعُد بإمكان التطبيقات التي تستهدف الإصدار 15 من نظام التشغيل Android تغيير الحالة أو السياسة العامة لميزة عدم الإزعاج (DND) على جهاز (إما من خلال تعديل إعدادات المستخدم أو إيقاف وضع DND). بدلاً من ذلك، يجب أن تساهم التطبيقات في السمة AutomaticZenRule، التي يدمجها النظام في سياسة عالمية مع المخطط الحالي الأكثر تقييدًا-policy-wins. إنّ الطلبات الموجّهة إلى واجهات برمجة التطبيقات الحالية والتي كانت تأثرت سابقًا بالحالة العامة (setInterruptionFilter, setNotificationPolicy) تؤدي إلى إنشاء أو تعديل AutomaticZenRuleضمنية، يتم إيقافها وإيقافها بناءً على دورة طلب البيانات من واجهة برمجة التطبيقات هذه.

يُرجى العلم بأنّ هذا التغيير لا يؤثّر إلا في السلوك الملحوظ فقط إذا كان التطبيق يطلب setInterruptionFilter(INTERRUPTION_FILTER_ALL) ويتوقّع أن تؤدي هذه المكالمة إلى إيقاف AutomaticZenRule الذي سبق أن فعَّله مالكو التطبيق.

تغييرات OpenJDK 17

يواصل نظام Android 15 العمل على تحديث مكتبات Android الأساسية للتوافق مع الميزات المتوفّرة في أحدث إصدارات OpenJDK LTS.

يمكن أن يؤثّر أحد هذه التغييرات في توافق التطبيقات التي تستهدف الإصدار 15 من Android:

• التغييرات في واجهات برمجة التطبيقات لتنسيق السلسلة: أصبح التحقق من صحة فهرس الوسيطة والعلامات والعرض والدقة أكثر صرامة الآن عند استخدام واجهتي برمجة التطبيقات String.format() وFormatter.format() التاليين:

  • String.format(String, Object[])
  • String.format(Locale, String, Object[])
  • Formatter.format(String, Object[])
  • Formatter.format(Locale, String, Object[])

  على سبيل المثال، يتم طرح الاستثناء التالي عند استخدام فهرس وسيطة بقيمة 0 (%0 في سلسلة التنسيق):

  IllegalFormatArgumentIndexException: Illegal format argument index = 0
  

  في هذه الحالة، يمكن حلّ المشكلة باستخدام فهرس الوسيطة 1 (%1 في سلسلة التنسيق).

• التغييرات في نوع المكوِّن Arrays.asList(...).toArray(): عند استخدام Arrays.asList(...).toArray()، يصبح نوع المكوِّن في الصفيف الناتج الآن Object، وليس نوع عناصر الصفيفة الأساسية. بالتالي تعرض التعليمة البرمجية التالية ClassCastException:

  String[] elements = (String[]) Arrays.asList("one", "two").toArray();
  

  في هذه الحالة، للاحتفاظ بـ String كنوع المكوِّن في المصفوفة الناتجة، يمكنك استخدام Collection.toArray(Object[]) بدلاً من ذلك:

  String[] elements = Arrays.asList("two", "one").toArray(new String[0]);
  

• تغييرات في التعامل مع رموز اللغة: عند استخدام واجهة برمجة التطبيقات Locale، لم يعُد يتم تحويل رموز اللغات للّغة العبرية واليديشية والإندونيسية إلى صيغ قديمة (العبرية: iw واليديشية: ji والإندونيسية: in). عند تحديد رمز اللغة لإحدى هذه اللغات، استخدِم الرموز من ISO 639 وhe: Ybrew: { والإندونيسية: : Ybrish: Ybrish:yiid

• التغييرات على تسلسلات int العشوائية: بعد إجراء التغييرات في https://bugs.openjdk.org/Browse/JDK-8301574، تعرض طرق Random.ints() التالية الآن تسلسل أرقامًا مختلفًا عن الذي تعرضه طرق Random.nextInt():

  • Random.ints(long)
  • Random.ints(long, int, int)
  • Random.ints(int, int)
  • Random.ints()

  بشكل عام، من المفترَض ألا يؤدي هذا التغيير إلى تعطّل التطبيق، ولكن من غير المفترض أن يؤدي الرمز البرمجي إلى تطابُق التسلسل الذي تم إنشاؤه من خلال Random.ints() مع Random.nextInt().

الأمان

يتضمن Android 15 تغييرات تعزز أمان النظام للمساعدة في حماية التطبيقات والمستخدمين من التطبيقات الضارة.

تم إطلاق الأنشطة الآمنة في الخلفية

يحمي Android 15 المستخدمين من التطبيقات الضارة ويمنحهم مزيدًا من التحكّم في أجهزتهم من خلال إضافة تغييرات تمنع التطبيقات الضارة في الخلفية من عرض تطبيقات أخرى في المقدّمة، وتعزيز امتيازاتها، وإساءة استخدام تفاعل المستخدمين. تم حظر إطلاق الأنشطة في الخلفية منذ Android 10 (المستوى 29 من واجهة برمجة التطبيقات).

حظر التطبيقات التي لا تتطابق مع المعرّف الفريد العلوي في الحزمة من تفعيل الأنشطة

يمكن للتطبيقات الضارة تشغيل نشاط تطبيق آخر ضمن المهمة نفسها، ثم تراكبها في الأعلى، وجعلها وهمية بأنّها ذلك التطبيق. يتجاوز هجوم "استغلال المهام" هذا قيود التشغيل في الخلفية الحالية لأنّه يحدث ضمن المهمة المرئية نفسها. للحدّ من هذه المخاطر، يضيف نظام التشغيل Android 15 علامة تمنع التطبيقات التي لا تتطابق مع المعرّف الفريد العلوي على الحزمة من إطلاق الأنشطة. لتفعيل جميع أنشطة تطبيقك، عليك تعديل السمة allowCrossUidActivitySwitchFromBelow في ملف AndroidManifest.xml الخاص بتطبيقك:

<application android:allowCrossUidActivitySwitchFromBelow="false" >

وتكون إجراءات الأمان الجديدة نشطة في حال استيفاء جميع الشروط التالية:

• يستهدف التطبيق القائم بإطلاق الإصدار Android 15.
• يستهدف التطبيق في أعلى حزمة المهام نظام التشغيل Android 15.
• تم تفعيل إجراءات الحماية الجديدة لأي نشاط مرئي.

في حال تفعيل إجراءات الأمان، قد تعود التطبيقات إلى الشاشة الرئيسية بدلاً من آخر تطبيق مرئي إذا أنهوا مهمتهم.

تغييرات أخرى

بالإضافة إلى القيود المفروضة على مطابقة المعرّف الفريد، يتم أيضًا تضمين هذه التغييرات الأخرى:

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

نوايا أكثر أمانًا

يقدّم Android 15 إجراءات أمان جديدة لجعل الأغراض أكثر أمانًا وقوة. تهدف هذه التغييرات إلى منع الثغرات المحتملة وإساءة استخدام الأغراض التي يمكن أن تستغلها التطبيقات الضارة. هناك تحسينان رئيسيان على أمان الأهداف في Android 15:

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

fun onCreate() {
    StrictMode.setVmPolicy(VmPolicy.Builder()
        .detectUnsafeIntentLaunch()
        .build()
    )
}

public void onCreate() {
    StrictMode.setVmPolicy(new VmPolicy.Builder()
            .detectUnsafeIntentLaunch()
            .build());
}

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

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

التغييرات المتعلّقة بالنافذة الداخلية

هناك تغييران متعلّقان بمساحات النوافذ الداخلية في Android 15: يتم فرض استخدام جميع النوافذ بشكلٍ تلقائي، كما أنّ هناك تغييرات في الإعدادات، مثل الإعدادات التلقائية لأشرطة النظام.

التنفيذ الشامل

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

هذا تغيير قد يؤدي إلى عطل قد يؤثر سلبًا في واجهة مستخدم تطبيقك. تؤثر التغييرات في مناطق واجهة المستخدم التالية:

• شريط التنقل بمقبض الإيماءات
  • شفاف بشكل تلقائي.
  • يتم إيقاف الإزاحة السفلية بحيث يرسم المحتوى خلف شريط تنقل النظام ما لم يتم تطبيق العناصر الداخلية.
  • تم إيقاف setNavigationBarColor وR.attr#navigationBarColor نهائيًا ولا يؤثّران في التنقّل بالإيماءات.
  • ما زال setNavigationBarContrastEnforced وR.attr#navigationBarContrastEnforced لا يؤثّران في التنقّل بالإيماءات.
• التنقُّل باستخدام ثلاثة أزرار
  • يتم تعيين معدل الشفافية على 80٪ افتراضيًا، مع إمكانية مطابقة اللون لخلفية النافذة.
  • تم إيقاف الإزاحة السفلية بحيث يظهر المحتوى خلف شريط تنقل النظام ما لم يتم تطبيق العناصر الداخلية.
  • يتم ضبط setNavigationBarColor وR.attr#navigationBarColor لمطابقة خلفية النافذة تلقائيًا. يجب أن تكون خلفية النافذة بلون قابل للرسم حتى يتم تطبيق هذا الإعداد الافتراضي. تم إيقاف واجهة برمجة التطبيقات هذه نهائيًا، ولكنها ما زالت تؤثر في التنقّل باستخدام ثلاثة أزرار.
  • يتم ضبط setNavigationBarContrastEnforced وR.attr#navigationBarContrastEnforced على "صحيح" تلقائيًا، ما يضيف خلفية معتمة بنسبة 80% خلال التنقّل باستخدام ثلاثة أزرار.
• شريط الحالة
  • شفاف بشكل تلقائي.
  • يتم إيقاف الإزاحة العلوية بحيث يتم رسم المحتوى خلف شريط الحالة ما لم يتم تطبيق الإضافات.
  • تم إيقاف setStatusBarColor وR.attr#statusBarColor نهائيًا ولن يكون لهما أي تأثير في نظام التشغيل Android 15.
  • تم إيقاف التطبيقَين setStatusBarContrastEnforced وR.attr#statusBarContrastEnforced نهائيًا، ولكن ما زالا يؤثران في إصدار Android 15.
• صورة مقطوعة للشاشة
  • يجب أن تكون قيمة layoutInDisplayCutoutMode من النوافذ غير العائمة LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. يتم تفسير SHORT_EDGES وNEVER وDEFAULT على أنّها ALWAYS بحيث لا يظهر للمستخدمين شريط أسود ناتج عن قطع الشاشة ومظهره بالكامل.

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

المعلومات التي يجب التحقُّق ممّا إذا كان تطبيقك متكاملاً معها حاليًا

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

• لديك نافذة غير عائمة، مثل Activity تستخدم SHORT_EDGES أو NEVER أو DEFAULT بدلاً من LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. إذا تعطّل تطبيقك عند التشغيل، فقد يرجع ذلك إلى شاشة البداية. يمكنك إما ترقية الاعتمادية لشاشة البداية الأساسية إلى 1.2.0-alpha01 أو إصدار أحدث أو ضبط window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always.
• قد تكون هناك شاشات لحركة المرور المنخفضة مع واجهة مستخدم مغلقة. تحقق من أن هذه الشاشات الأقل زيارة لا تحتوي على واجهة مستخدم مُغطاة. تشمل الشاشات التي تتلقّى عددًا أقل من الزيارات ما يلي:
  • شاشات الإعداد أو تسجيل الدخول
  • صفحات الإعدادات

المعلومات التي يجب التحقّق منها إذا لم يكن تطبيقك محدَّثًا بالكامل

إذا لم يكن تطبيقك محدَّثًا بالكامل، من المرجح أن تتأثر. إلى جانب سيناريوهات التطبيقات المتطورة تمامًا، ينبغي لك مراعاة ما يلي:

• إذا كان تطبيقك يستخدم مكونات المادة 3 (androidx.compose.material3) في عملية الإنشاء، مثل TopAppBar وBottomAppBar وNavigationBar، من المحتمل ألا تتأثر هذه المكوّنات لأنها تعالج العناصر الداخلية تلقائيًا.
• إذا كان تطبيقك يستخدم مكونات المادة 2 (androidx.compose.material) في Compose، لن تعالج هذه المكونات العناصر الداخلية تلقائيًا. ومع ذلك، يمكنك الوصول إلى الأجزاء الداخلية وتطبيقها يدويًا. في androidx.compose.material 1.6.0 والإصدارات الأحدث، استخدِم المَعلمة windowInsets لتطبيق العناصر الداخلية يدويًا في BottomAppBar وTopAppBar وBottomNavigation وNavigationRail. وبالمثل، استخدِم المعلَمة contentWindowInsets لـ Scaffold.
• إذا كان تطبيقك يستخدم طرق العرض والمكوّنات المادية (com.google.android.material)، ستعالج معظم مكوّنات المادة المستندة إلى المشاهدات، مثل BottomNavigationView أو BottomAppBar أو NavigationRailView أو NavigationView، الأجزاء الداخلية ولا تتطلّب أي جهد إضافي. ومع ذلك، عليك إضافة السمة android:fitsSystemWindows="true" في حال استخدام AppBarLayout.
• بالنسبة إلى العناصر القابلة للإنشاء المخصّصة، طبِّق الأجزاء الداخلية يدويًا كمساحة متروكة. إذا كان المحتوى الخاص بك ضمن Scaffold، يمكنك استهلاك المساحات الداخلية باستخدام قيم المساحة المتروكة في Scaffold. بخلاف ذلك، طبِّق المساحة المتروكة باستخدام إحدى WindowInsets.
• إذا كان تطبيقك يستخدم طرق العرض وBottomSheet أو SideSheet أو حاويات مخصّصة، يمكنك تطبيق مساحة متروكة باستخدام ViewCompat.setOnApplyWindowInsetsListener. بالنسبة إلى RecyclerView، وفِّر مساحة متروكة باستخدام أداة الاستماع هذه وأضِف أيضًا clipToPadding="false".

الإجراءات التي يجب التحقّق منها إذا كان تطبيقك يجب أن يوفّر حماية مخصّصة في الخلفية

إذا كان يجب أن يوفّر تطبيقك حماية مخصّصة للخلفية أثناء التنقّل باستخدام ثلاثة أزرار أو شريط الحالة، يجب أن يعرض التطبيق طبقة قابلة للإنشاء أو العرض خلف شريط النظام باستخدام WindowInsets.Type#tappableElement() للحصول على ارتفاع شريط التنقّل بثلاثة أزرار أو WindowInsets.Type#statusBars.

موارد إضافية شاملة

اطّلع على أدلة طرق العرض من الحافة إلى الحافة ودليلَي الحافة إلى الحافة لمعرفة المزيد من الاعتبارات حول تطبيق العناصر الداخلية.

واجهات برمجة التطبيقات التي تم إيقافها نهائيًا

تم إيقاف واجهات برمجة التطبيقات التالية نهائيًا:

• R.attr#enforceStatusBarContrast
• R.attr#navigationBarColor
• R.attr#navigationBarDividerColor
• R.attr#statusBarColor
• Window#getNavigationBarColor
• Window#getNavigationBarDividerColor
• Window#getStatusBarColor
• Window#isStatusBarContrastEnforced
• Window#setDecorFitsSystemWindows
• Window#setNavigationBarColor
• Window#setNavigationBarDividerColor
• Window#setStatusBarColor
• Window#setStatusBarContrastEnforced

الإعدادات الثابتة

وإذا كان تطبيقك يستهدف الإصدار 15 من نظام التشغيل Android أو الإصدارات الأحدث، لن يستبعد Configuration أشرطة النظام. إذا كنت تستخدم حجم الشاشة في الفئة Configuration لحساب التنسيق، يجب استبدالها ببدائل أفضل، مثل ViewGroup أو WindowInsets أو WindowMetricsCalculator المناسبة حسب احتياجاتك.

"Configuration" متاح منذ واجهة برمجة التطبيقات 1. ويتم الحصول عليها عادةً من Activity.onConfigurationChanged. وهو يوفر معلومات مثل كثافة النوافذ والاتجاه والأحجام. من الخصائص المهمة لأحجام النوافذ التي تم إرجاعها من Configuration أنها استبعدت أشرطة النظام سابقًا.

يُستخدم حجم الإعدادات عادةً لاختيار الموارد، مثل /res/layout-h500dp، ولا تزال هذه الحالة حالة استخدام صالحة. ومع ذلك، لم يكن من المستحسن دائمًا استخدامه لحساب التخطيط. إذا قمت بذلك، فيجب عليك الابتعاد عنها الآن. يجب استبدال استخدام Configuration بشيء آخر أكثر ملاءمة بناءً على حالة الاستخدام.

إذا كنت تستخدمه لحساب التنسيق، استخدِم السمة ViewGroup المناسبة، مثل CoordinatorLayout أو ConstraintLayout. إذا كنت تستخدمه لتحديد ارتفاع شريط تنقل النظام، استخدِم WindowInsets. لمعرفة الحجم الحالي لنافذة التطبيق، استخدِم computeCurrentWindowMetrics.

توضِّح القائمة التالية الحقول المتأثرة بهذا التغيير:

• لم يعد الحجمان Configuration.screenWidthDp وscreenHeightDp يؤديان إلى استبعاد أشرطة النظام.
• تتأثر Configuration.smallestScreenWidthDp بشكل غير مباشر بالتغييرات التي يتم إجراؤها على screenWidthDp وscreenHeightDp.
• تتأثر Configuration.orientation بشكل غير مباشر بالتغييرات التي يتم إجراؤها على screenWidthDp وscreenHeightDp على الأجهزة القريبة.
• تتأثر Display.getSize(Point) بشكل غير مباشر بالتغييرات في Configuration. وقد تم إيقافها نهائيًا بدءًا من المستوى 30 لواجهة برمجة التطبيقات.
• وقد عمل Display.getMetrics() على هذا النحو منذ المستوى 33 من واجهة برمجة التطبيقات.

القيمة التلقائية لسمة smartTextHeight على "صحيح"

في التطبيقات التي تستهدف الإصدار 15 من نظام التشغيل Android، تصبح السمة elegantTextHeight TextView true تلقائيًا، لتستبدل الخط المكثّف المُستخدَم تلقائيًا ببعض النصوص البرمجية ذات المقاييس العمودية الكبيرة بنص أكثر قابلية للقراءة. وقد تم تصميم الخط المكثّف لمنع تعطّل التنسيقات، ويمنع Android 13 (المستوى 33 لواجهة برمجة التطبيقات) العديد من هذه الأعطال من خلال السماح لتنسيق النص بزيادة الارتفاع العمودي باستخدام السمة fallbackLineSpacing.

في نظام التشغيل Android 15، يظل الخط المضغوط موجودًا في النظام، لذلك يمكن لتطبيقك ضبط elegantTextHeight على false للحصول على السلوك نفسه كما في السابق، ولكن من غير المحتمل أن يكون متوافقًا في الإصدارات القادمة. مثلاً، إذا كان تطبيقك متوافقًا مع النصوص التالية: العربية واللاوية وميانمار والتاميلية والغوجاراتية والكنادية والماليالامية أو الأودية أو التيلوغوية أو التايلاندية، يمكنك اختبار تطبيقك من خلال ضبط elegantTextHeight على true.

يتغير عرض TextView لأشكال الأحرف المعقدة.

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

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

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

توضح الأمثلة التالية كيف يمكن لهذه التغييرات أن تحسن تخطيط النص لبعض الخطوط واللغات.

تنسيق عادي للنص الإنجليزي بخط تدوين وبعض هذه الأحرف مقصوصة. إليك ملف XML المقابل:

<TextView
    android:fontFamily="cursive"
    android:text="java" />

تنسيق للنص الإنجليزي نفسه مع عرض إضافي ومساحة متروكة إليك ملف XML المقابل:

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

تنسيق قياسي للنص التايلاندي. بعض الحروف مقصوصة. إليك ملف XML المقابل:

<TextView
    android:text="คอมพิวเตอร์" />

تنسيق للنص التايلاندي نفسه مع عرض إضافي ومساحة متروكة إليك ملف XML المقابل:

<TextView
    android:text="คอมพิวเตอร์"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

ارتفاع السطر التلقائي حسب اللغة في EditText

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

في التطبيقات التي تستهدف الإصدار 15 من Android، يتم الآن تخصيص حد أدنى لارتفاع السطر لـ EditText لمطابقة الخط المرجعي للغة المحددة، كما هو موضّح في الصورة التالية:

وإذا لزم الأمر، يمكن لتطبيقك استعادة السلوك السابق من خلال تحديد السمة useLocalePreferredLineHeightForMinimum على false، ويمكن لتطبيقك ضبط حدّ أدنى مخصّص لمقاييس القطاع باستخدام واجهة setMinimumFontMetrics API في لغتَي Kotlin وJava.

الكاميرا والوسائط

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

القيود المفروضة على طلب التركيز الصوتي

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

تُعتبر الخدمة التي تعمل في المقدّمة مرتبطة بالصوت إذا كان نوعها mediaPlayback أو camera أو microphone أو phoneCall.

يمكنك الاطّلاع على مزيد من المعلومات حول ميزة "التركيز على الصوت" بالانتقال إلى إدارة التركيز الصوتي.

القيود المعدّلة غير التابعة لحزمة تطوير البرامج (SDK)

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

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

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

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