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

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

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

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

يعدّل نظام Android 15 أو يوسّع إمكانات نظام Android الأساسية المختلفة.

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

نحن بصدد إجراء التغييرات التالية على الخدمات التي تعمل في المقدّمة في Android 15.

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

يقدّم 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 (ما دام التطبيق يعمل على جهاز يعمل بالإصدار 15 من نظام التشغيل Android). لتفعيل مهلات الانتظار، شغِّل الأمر 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

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

يقدّم 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

القيود المفروضة على تطبيقات BOOT_COMPLETED التي تستخدم مستقبلات البث لتشغيل الخدمات التي تعمل في المقدّمة

هناك قيود جديدة على إطلاق أجهزة استقبال بث 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

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

Previously, if an app held the SYSTEM_ALERT_WINDOW permission, it could launch a foreground service even if the app was currently in the background (as discussed in exemptions from background start restrictions).

If an app targets Android 15, this exemption is now narrower. The app now needs to have the SYSTEM_ALERT_WINDOW permission and also have a visible overlay window. That is, the app needs to first launch a TYPE_APPLICATION_OVERLAY window and the window needs to be visible before you start a foreground service.

If your app attempts to start a foreground service from the background without meeting these new requirements (and it does not have some other exemption), the system throws ForegroundServiceStartNotAllowedException.

If your app declares the SYSTEM_ALERT_WINDOW permission and launches foreground services from the background, it may be affected by this change. If your app gets a ForegroundServiceStartNotAllowedException, check your app's order of operations and make sure your app already has an active overlay window before it attempts to start a foreground service from the background. You can check if your overlay window is currently visible by calling View.getWindowVisibility(), or you can override View.onWindowVisibilityChanged() to get notified whenever the visibility changes.

Testing

To test your app's behavior, you can enable these new restrictions even if your app is not targeting Android 15 (as long as the app is running on an Android 15 device). To enable these new restrictions on starting foreground services from the background, run the following adb command:

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.

يمكن أن تؤثّر بعض هذه التغييرات في توافق التطبيقات التي تستهدف الإصدار Android 15 (المستوى 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 في إعدادات إنشاء تطبيقك لاستخدام Android 15 (المستوى 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 أو إصدار أقدم، ثم تشغيل التطبيق على Android 14 والإصدارات الأقدم، يتم طرح خطأ أثناء التشغيل:

    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. إذا كنت تستخدم IDE IDE Android Studio Ladybug | 2024.1.3 أو إصدارًا أحدث، يتيح لك أيضًا خيارًا لإصلاح هذه الأخطاء بشكل سريع.

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

  • تداخل مع طرق أخرى في 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 تغييرات تعزّز أمان النظام للمساعدة في حماية التطبيقات والمستخدمين من التطبيقات الضارّة.

بدء الأنشطة الآمنة في الخلفية

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

In addition to the restriction for UID matching, these other changes are also included:

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

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

للتحقّق من استجابة تطبيقك لهذه التغييرات، استخدِم StrictMode في تطبيقك. للاطّلاع على سجلّات detailed حول انتهاكات استخدام 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: يتم تطبيق التمويه من الحافة إلى الحافة تلقائيًا، وهناك أيضًا تغييرات في الإعدادات، مثل الإعدادات التلقائية لأشرطة النظام.

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

If your app targets Android 15 (API level 35) or higher, Configuration no longer excludes the system bars. If you use the screen size in the Configuration class for layout calculation, you should replace it with better alternatives like an appropriate ViewGroup, WindowInsets, or WindowMetricsCalculator depending on your need.

Configuration has been available since API 1. It is typically obtained from Activity.onConfigurationChanged. It provides information like window density, orientation, and sizes. One important characteristic about the window sizes returned from Configuration is that it previously excluded the system bars.

The configuration size is typically used for resource selection, such as /res/layout-h500dp, and this is still a valid use case. However, using it for layout calculation has always been discouraged. If you do so, you should move away from it now. You should replace the use of Configuration with something more suitable depending on your use case.

If you use it to calculate the layout, use an appropriate ViewGroup, such as CoordinatorLayout or ConstraintLayout. If you use it to determine the height of the system navbar, use WindowInsets. If you want to know the current size of your app window, use computeCurrentWindowMetrics.

The following list describes the fields affected by this change:

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

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

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

سلوك elegantTextHeight للتطبيقات التي تستهدف الإصدار 14 من نظام التشغيل Android (المستوى 34 لواجهة برمجة التطبيقات) والإصدارات الأقدم
سلوك elegantTextHeight للتطبيقات التي تستهدف الإصدار 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 أو الإصدارات الأحدث.

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

Apps that target Android 15 (API level 35) must be the top app or running a foreground service in order to request audio focus. If an app attempts to request focus when it does not meet one of these requirements, the call returns AUDIOFOCUS_REQUEST_FAILED.

You can learn more about audio focus at Manage audio focus.

قيود غير متعلّقة بحِزم SDK تم تعديلها

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

إذا كان تطبيقك لا يستهدف الإصدار 15 من نظام التشغيل Android، قد لا تسري بعض هذه التغييرات عليك على الفور. ومع أنّه من الممكن أن يتمكّن تطبيقك من الوصول إلى بعض الواجهات غير التابعة لحِزم 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.