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

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

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

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

يعدّل نظام التشغيل Android 15 العديد من الإمكانات الأساسية لنظام Android أو يوسّع نطاقها.

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

We are making the following changes to foreground services with Android 15.

Data sync foreground service timeout behavior

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

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

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type dataSync did not stop within its timeout: [component name]"

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

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

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

الاختبار

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

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

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

adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds

New media processing foreground service type

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

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

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"

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

  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: معالجة الوسائط.

الاختبار

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

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

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

adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds

Restrictions on BOOT_COMPLETED broadcast receivers launching foreground services

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

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

الاختبار

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

adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name

لإرسال بث BOOT_COMPLETED بدون إعادة تشغيل الجهاز، يُرجى اتّباع الخطوات التالية: شغِّل الأمر adb التالي:

adb shell am broadcast -a android.intent.action.BOOT_COMPLETED your-package-name

Restrictions on starting foreground services while an app holds the SYSTEM_ALERT_WINDOW permission

في السابق، إذا كان التطبيق يمتلك إذن SYSTEM_ALERT_WINDOW، كان بإمكانه بدء خدمة تعمل في المقدّمة حتى إذا كان التطبيق قيد التشغيل في الخلفية (كما هو описан في الاستثناءات من القيود المفروضة على بدء التطبيقات في الخلفية).

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

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

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

الاختبار

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

adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name

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

Apps that target Android 15 (API level 35) and higher can no longer change the global state or policy of Do Not Disturb (DND) on a device (either by modifying user settings, or turning off DND mode). Instead, apps must contribute an AutomaticZenRule, which the system combines into a global policy with the existing most-restrictive-policy-wins scheme. Calls to existing APIs that previously affected global state (setInterruptionFilter, setNotificationPolicy) result in the creation or update of an implicit AutomaticZenRule, which is toggled on and off depending on the call-cycle of those API calls.

Note that this change only affects observable behavior if the app is calling setInterruptionFilter(INTERRUPTION_FILTER_ALL) and expects that call to deactivate an AutomaticZenRule that was previously activated by their owners.

التغييرات في واجهة برمجة التطبيقات OpenJDK

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

يمكن أن تؤثّر بعض هذه التغييرات في توافق التطبيقات التي تستهدف الإصدار 15 من نظام التشغيل Android (المستوى 35 لواجهة برمجة التطبيقات):

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

    على سبيل المثال، يتم طرح الاستثناء التالي عند استخدام فهرس وسيطة بقيمة 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-1 بدلاً من ذلك (العبرية: he، واليديشية: yi، والإندونيسية: id).

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

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

يمكن أن تؤثّر واجهة برمجة التطبيقات الجديدة SequencedCollection في توافق تطبيقك بعد تعديل compileSdk في إعدادات الإصدار في تطبيقك لاستخدام الإصدار 15 من نظام التشغيل Android (المستوى 35 لواجهة برمجة التطبيقات):

  • تعارض مع دالتَي الإضافة MutableList.removeFirst() وMutableList.removeLast() في kotlin-stdlib

    يتم ربط النوع List في Java بالنوع MutableList في Kotlin. بما أنّه تم طرح واجهتَي برمجة التطبيقات List.removeFirst() وList.removeLast() في نظام التشغيل Android 15 (المستوى 35 لواجهة برمجة التطبيقات)، يحلّل برنامج الترجمة البرمجية في Kotlin استدعاءات الدوال، مثل list.removeFirst()، بشكل ثابت إلى واجهات برمجة التطبيقات الجديدة List بدلاً من دوال الإضافة في kotlin-stdlib.

    إذا تمت إعادة تجميع تطبيق مع ضبط compileSdk على 35 وضبط minSdk على 34 أو إصدار أقدم، ثم تم تشغيل التطبيق على الإصدار 14 من نظام التشغيل Android أو إصدار أقدم، سيتم عرض خطأ وقت التشغيل:

    java.lang.NoSuchMethodError: No virtual method
    removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;
    

    يمكن لخيار NewApi lint الحالي في "المكوّن الإضافي لنظام Gradle المتوافق مع Android" رصد حالات الاستخدام الجديدة لواجهة برمجة التطبيقات.

    ./gradlew lint
    
    MainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi]
          list.removeFirst()
    

    لحلّ خطأ وقت التشغيل وأخطاء Lint، يمكن استبدال استدعاءات الدالتَين removeFirst() وremoveLast() بالدالتَين removeAt(0) وremoveAt(list.lastIndex) على التوالي في Kotlin. إذا كنت تستخدم الإصدار 2024.1.3 من Android Studio Ladybug أو إصدارًا أحدث، سيتوفّر لك أيضًا خيار إصلاح سريع لهذه الأخطاء.

    ننصحك بإزالة @SuppressLint("NewApi") وlintOptions { disable 'NewApi' } إذا تم إيقاف خيار Lint.

  • تعارض مع طرق أخرى في Java

    تمت إضافة طرق جديدة إلى الأنواع الحالية، مثل List وDeque. قد لا تكون هذه الطرق الجديدة متوافقة مع الطرق التي تحمل الاسم نفسه وأنواع الوسيطات في الواجهات والفئات الأخرى. في حال حدوث تعارض في توقيع الطريقة مع عدم التوافق، سيُخرج برنامج التجميع javac خطأ في وقت الإصدار. على سبيل المثال:

    مثال على الخطأ 1:

    javac MyList.java
    
    MyList.java:135: error: removeLast() in MyList cannot implement removeLast() in List
      public void removeLast() {
                  ^
      return type void is not compatible with Object
      where E is a type-variable:
        E extends Object declared in interface List
    

    مثال على الخطأ 2:

    javac MyList.java
    
    MyList.java:7: error: types Deque<Object> and List<Object> are incompatible;
    public class MyList implements  List<Object>, Deque<Object> {
      both define reversed(), but with unrelated return types
    1 error
    

    مثال على الخطأ 3:

    javac MyList.java
    
    MyList.java:43: error: types List<E#1> and MyInterface<E#2> are incompatible;
    public static class MyList implements List<Object>, MyInterface<Object> {
      class MyList inherits unrelated defaults for getFirst() from types List and MyInterface
      where E#1,E#2 are type-variables:
        E#1 extends Object declared in interface List
        E#2 extends Object declared in interface MyInterface
    1 error
    

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

    @Override
    public Object getFirst() {
        return List.super.getFirst();
    }
    

الأمان

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

إصدارات بروتوكول أمان طبقة النقل (TLS) المحظورة

Android 15 restricts the usage of TLS versions 1.0 and 1.1. These versions had previously been deprecated in Android, but are now disallowed for apps targeting Android 15.

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

Android 15 protects users from malicious apps and gives them more control over their devices by adding changes that prevent malicious background apps from bringing other apps to the foreground, elevating their privileges, and abusing user interaction. Background activity launches have been restricted since Android 10 (API level 29).

Other changes

  • Change PendingIntent creators to block background activity launches by default. This helps prevent apps from accidentally creating a PendingIntent that could be abused by malicious actors.
  • Don't bring an app to the foreground unless the PendingIntent sender allows it. This change aims to prevent malicious apps from abusing the ability to start activities in the background. By default, apps are not allowed to bring the task stack to the foreground unless the creator allows background activity launch privileges or the sender has background activity launch privileges.
  • Control how the top activity of a task stack can finish its task. If the top activity finishes a task, Android will go back to whichever task was last active. Moreover, if a non-top activity finishes its task, Android will go back to the home screen; it won't block the finish of this non-top activity.
  • Prevent launching arbitrary activities from other apps into your own task. This change prevents malicious apps from phishing users by creating activities that appear to be from other apps.
  • Block non-visible windows from being considered for background activity launches. This helps prevent malicious apps from abusing background activity launches to display unwanted or malicious content to users.

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

يقدّم نظام التشغيل Android 15 StrictMode للأهداف.

للاطّلاع على سجلّات تفصيلية حول انتهاكات استخدام Intent، استخدِم الطريقة التالية:

Kotlin

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

Java

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

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

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

تغييرات في مساحة العرض داخل النافذة

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

Edge-to-edge enforcement

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

تطبيق يستهدف الإصدار 14 من نظام التشغيل Android ولا يتم عرضه حتى حافة الشاشة على جهاز يعمل بالإصدار 15 من نظام التشغيل Android


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

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

  • شريط التنقل باستخدام مقبض الإيماءات
    • تكون شفافة تلقائيًا.
    • يتم إيقاف الإزاحة السفلية حتى يتم رسم المحتوى خلف شريط التنقّل في النظام ما لم يتم تطبيق هوامش داخلية.
    • تم إيقاف setNavigationBarColor وR.attr#navigationBarColor نهائيًا، ولا يؤثران في التنقّل بالإيماءات.
    • لن يكون setNavigationBarContrastEnforced وR.attr#navigationBarContrastEnforced أي تأثير على التنقّل بالإيماءات.
  • التنقّل باستخدام ثلاثة أزرار
    • يتم ضبط مستوى الشفافية على 80% تلقائيًا، وقد يتطابق اللون مع لون خلفية النافذة.
    • تم إيقاف الإزاحة السفلية كي يتم عرض المحتوى خلف شريط التنقّل في النظام ما لم يتم تطبيق الحواف الداخلية.
    • يتم ضبط setNavigationBarColor وR.attr#navigationBarColor تلقائيًا ليتطابقا مع خلفية النافذة. يجب أن تكون خلفية النافذة قابلة للرسم بلون حتى يتم تطبيق هذا الإعداد التلقائي. تم إيقاف هذه الواجهة، ولكنها لا تزال تؤثر في التنقّل باستخدام 3 أزرار.
    • تكون قيمة 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 كي لا يظهر للمستخدمين شريط أسود بسبب فتحة الشاشة، بل تظهر الصورة من الحافة إلى الحافة.

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

تطبيق يستهدف الإصدار 14 من نظام التشغيل Android ولا يتم عرضه حتى حافة الشاشة على جهاز يعمل بالإصدار 15 من نظام التشغيل Android
تطبيق يستهدف الإصدار 15 من نظام التشغيل Android (المستوى 35 لواجهة برمجة التطبيقات) ويعرض المحتوى من الحافة إلى الحافة على جهاز Android 15. ومع ذلك، يتم الآن إخفاء العديد من العناصر بواسطة شريط الحالة أو شريط التنقّل الذي يتضمّن 3 أزرار أو فتحة الشاشة بسبب عمليات فرض ميزة &quot;العرض حتى حافة الشاشة&quot; في Android 15. تتضمّن واجهة المستخدم المخفية شريط التطبيق العلوي في Material 2 وأزرار الإجراء العائم وعناصر القائمة.
تطبيق يستهدف الإصدار 15 من نظام التشغيل Android (المستوى 35 لواجهة برمجة التطبيقات)، ويتم عرضه من الحافة إلى الحافة على جهاز يعمل بالإصدار 15 من نظام التشغيل Android، ويطبّق عمليات إدراج حتى لا يتم إخفاء واجهة المستخدم.
ما يجب التحقّق منه إذا كان تطبيقك معروضًا من الحافة إلى الحافة

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

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

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

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

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

مراجع إضافية حول العرض من الحافة إلى الحافة

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

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

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

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

Stable configuration

إذا كان تطبيقك يستهدف الإصدار 15 من نظام التشغيل Android (المستوى 35 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث، لن يتم استبعاد أشرطة النظام بعد الآن.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 على الأجهزة التي تكون نسبة العرض إلى الارتفاع فيها قريبة من 1:1.
  • يتأثر Display.getSize(Point) بشكل غير مباشر بالتغييرات في Configuration. تم إيقافها نهائيًا بدايةً من المستوى 30 لواجهة برمجة التطبيقات.
  • كانت Display.getMetrics() تعمل بهذه الطريقة منذ المستوى 33 لواجهة برمجة التطبيقات.

تكون القيمة التلقائية لسمة elegantTextHeight هي true

For apps targeting Android 15 (API level 35), the elegantTextHeight TextView attribute becomes true by default, replacing the compact font used by default with some scripts that have large vertical metrics with one that is much more readable. The compact font was introduced to prevent breaking layouts; Android 13 (API level 33) prevents many of these breakages by allowing the text layout to stretch the vertical height utilizing the fallbackLineSpacing attribute.

In Android 15, the compact font still remains in the system, so your app can set elegantTextHeight to false to get the same behavior as before, but it is unlikely to be supported in upcoming releases. So, if your app supports the following scripts: Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai, test your app by setting elegantTextHeight to true.

elegantTextHeight behavior for apps targeting Android 14 (API level 34) and lower.
elegantTextHeight behavior for apps targeting Android 15.

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

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

وبما أنّ هذا التغيير يؤثر في كيفية تحديد TextView للعرض، TextView يحدّد عرضًا أكبر تلقائيًا إذا كان التطبيق يستهدف الإصدار 15 من نظام التشغيل Android (المستوى 35 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث. يمكنك تفعيل هذا السلوك أو إيقافه من خلال طلب بيانات من واجهة برمجة التطبيقات setUseBoundsForWidth على 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

In previous versions of Android, the text layout stretched the height of the text to meet the line height of the font that matched the current locale. For example, if the content was in Japanese, because the line height of the Japanese font is slightly larger than the one of a Latin font, the height of the text became slightly larger. However, despite these differences in line heights, the EditText element was sized uniformly, regardless of the locale being used, as illustrated in the following image:

Three boxes representing EditText elements that can contain text from English (en), Japanese (ja), and Burmese (my). The height of the EditText is the same, even though these languages have different line heights from each other.

For apps targeting Android 15 (API level 35), a minimum line height is now reserved for EditText to match the reference font for the specified Locale, as shown in the following image:

Three boxes representing EditText elements that can contain text from English (en), Japanese (ja), and Burmese (my). The height of the EditText now includes space to accommodate the default line height for these languages' fonts.

If needed, your app can restore the previous behavior by specifying the useLocalePreferredLineHeightForMinimum attribute to false, and your app can set custom minimum vertical metrics using the setMinimumFontMetrics API in Kotlin and Java.

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

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

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

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

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

تعديل القيود المفروضة على الواجهات غير المتوفرة في حزمة SDK

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

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

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

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 15. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.