على غرار الإصدارات السابقة، يتضمّن Android 15 تغييرات في السلوك قد تؤثّر في تطبيقك. تنطبق تغييرات السلوك التالية حصريًا على التطبيقات التي تستهدف Android 15 أو الإصدارات الأحدث. إذا كان تطبيقك يستهدف Android 15 أو الإصدارات الأحدث، عليك تعديله ليتوافق مع هذه السلوكيات بشكلٍ صحيح، حيثما ينطبق ذلك.
احرص أيضًا على مراجعة قائمة تغييرات السلوك التي تؤثّر في جميع التطبيقات
التي تعمل على Android 15 بغض النظر عن targetSdkVersion في تطبيقك.
الوظيفة الأساسية
يعدّل Android 15 أو يوسّع إمكانات أساسية مختلفة في نظام Android.
تغييرات على الخدمات التي تعمل في المقدّمة
We are making the following changes to foreground services with Android 15.
- Data sync foreground service timeout behavior
- New media processing foreground service type
- Restrictions on
BOOT_COMPLETEDbroadcast receivers launching foreground services - Restrictions on starting foreground services while an app holds the
SYSTEM_ALERT_WINDOWpermission
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]"
لتجنُّب المشاكل المتعلّقة بهذا التغيير في السلوك، يمكنك اتّخاذ إجراء أو أكثر من الإجراءات التالية:
- يجب أن تنفِّذ خدمتك طريقة
Service.onTimeout(int, int)الجديدة. عندما يتلقّى تطبيقك المكالمة المُعاد توجيهها، احرص على الاتصال بالرقمstopSelf()في غضون بضع ثوانٍ. (إذا لم توقف التطبيق على الفور، سيُنشئ النظام حالة تعطُّل.) - تأكَّد من أنّ خدمات
dataSyncفي تطبيقك لا تعمل لأكثر من إجمالي 6 ساعات في أي فترة 24 ساعة (ما لم يتفاعل المستخدم مع التطبيق، يؤدي ذلك إلى إعادة ضبط الموقّت). - لا تبدأ
dataSyncالخدمات التي تعمل في المقدّمة إلا نتيجةً لتفاعل مباشر من العميل، لأنّ تطبيقك يكون في المقدّمة عند بدء الخدمة، ويكون لدى خدمتك ست ساعات كاملة بعد انتقال التطبيق إلى الخلفية. - بدلاً من استخدام خدمة
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 introduces a new foreground service type, mediaProcessing. This
service type is appropriate for operations like transcoding media files. For
example, a media app might download an audio file and need to convert it to a
different format before playing it. You can use a mediaProcessing foreground
service to make sure the conversion continues even while the app is in the
background.
The system permits an app's mediaProcessing services to run for a total of 6
hours in a 24-hour period, after which the system calls the running service's
Service.onTimeout(int, int) method (introduced in Android
15). At this time, the service has a few seconds to call
Service.stopSelf(). If the service does not
call Service.stopSelf(), the system throws an internal exception. The
exception is logged in Logcat with the following message:
Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"
To avoid having the exception, you can do one of the following:
- Have your service implement the new
Service.onTimeout(int, int)method. When your app receives the callback, make sure to callstopSelf()within a few seconds. (If you don't stop the app right away, the system generates a failure.) - Make sure your app's
mediaProcessingservices don't run for more than a total of 6 hours in any 24-hour period (unless the user interacts with the app, resetting the timer). - Only start
mediaProcessingforeground services as a result of direct user interaction; since your app is in the foreground when the service starts, your service has the full six hours after the app goes to the background. - Instead of using a
mediaProcessingforeground service, use an alternative API, like WorkManager.
If your app's mediaProcessing foreground services have run for 6 hours in the
last 24, you cannot start another mediaProcessing foreground service unless
the user has brought your app to the foreground (which resets the timer). If you
try to start another mediaProcessing foreground service, the system throws
ForegroundServiceStartNotAllowedException
with an error message like "Time limit already exhausted for foreground service
type mediaProcessing".
For more information about the mediaProcessing service type, see Changes to
foreground service types for Android 15: Media processing.
Testing
To test your app's behavior, you can enable media processing timeouts even if
your app is not targeting Android 15 (as long as the app is running on an
Android 15 device). To enable timeouts, run the following adb command:
adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name
You can also adjust the timeout period, to make it easier to test how your
app behaves when the limit is reached. To set a new timeout period, run the
following adb command:
adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds
Restrictions on BOOT_COMPLETED broadcast receivers launching foreground services
There are new restrictions on BOOT_COMPLETED broadcast receivers launching
foreground services. BOOT_COMPLETED receivers are not allowed to launch the
following types of foreground services:
dataSynccameramediaPlaybackphoneCallmediaProjectionmicrophone(this restriction has been in place formicrophonesince Android 14)
If a BOOT_COMPLETED receiver tries to launch any of those types of foreground
services, the system throws ForegroundServiceStartNotAllowedException.
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). Run the following adb command:
adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name
To send a BOOT_COMPLETED broadcast without restarting the device,
run the following adb command:
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
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.
يمكن أن تؤثّر بعض هذه التغييرات في توافق التطبيقات التي تستهدف الإصدار 15 من نظام التشغيل Android (المستوى 35 لواجهة برمجة التطبيقات):
تغييرات على واجهات برمجة التطبيقات الخاصة بتنسيق السلاسل: أصبح التحقّق من صحة فهرس الوسيطات والعلامات والعرض والدقة أكثر صرامة عند استخدام واجهتَي برمجة التطبيقات
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-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;يمكن لخيار
NewApilint الحالي في المكوّن الإضافي لنظام Gradle المتوافق مع Android رصد حالات الاستخدام الجديدة لواجهات برمجة التطبيقات../gradlew lintMainActivity.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 Ladybug أو إصدارًا أحدث، سيتوفّر لك أيضًا خيار إصلاح سريع لهذه الأخطاء.ننصحك بإزالة
@SuppressLint("NewApi")وlintOptions { disable 'NewApi' }إذا تم إيقاف خيار Lint.التعارض مع طرق أخرى في Java
تمت إضافة طرق جديدة إلى الأنواع الحالية، مثل
ListوDeque. قد لا تكون هذه الطرق الجديدة متوافقة مع الطرق التي تحمل الاسم نفسه وأنواع الوسيطات في الواجهات والفئات الأخرى. في حال حدوث تعارض في توقيع الطريقة مع عدم التوافق، سيُخرج برنامج التجميعjavacخطأ في وقت الإصدار. على سبيل المثال:مثال على الخطأ 1:
javac MyList.javaMyList.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.javaMyList.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.javaMyList.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
PendingIntentcreators to block background activity launches by default. This helps prevent apps from accidentally creating aPendingIntentthat could be abused by malicious actors. - Don't bring an app to the foreground unless the
PendingIntentsender 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
Apps are edge-to-edge by default on devices running Android 15 if the app is targeting Android 15 (API level 35).
This is a breaking change that might negatively impact your app's UI. The changes affect the following UI areas:
- Gesture handle navigation bar
- Transparent by default.
- Bottom offset is disabled so content draws behind the system navigation bar unless insets are applied.
setNavigationBarColorandR.attr#navigationBarColorare deprecated and don't affect gesture navigation.setNavigationBarContrastEnforcedandR.attr#navigationBarContrastEnforcedcontinue to have no effect on gesture navigation.
- 3-button navigation
- Opacity set to 80% by default, with color possibly matching the window background.
- Bottom offset disabled so content draws behind the system navigation bar unless insets are applied.
setNavigationBarColorandR.attr#navigationBarColorare set to match the window background by default. The window background must be a color drawable for this default to apply. This API is deprecated but continues to affect 3-button navigation.setNavigationBarContrastEnforcedandR.attr#navigationBarContrastEnforcedis true by default, which adds an 80% opaque background across 3-button navigation.
- Status bar
- Transparent by default.
- The top offset is disabled so content draws behind the status bar unless insets are applied.
setStatusBarColorandR.attr#statusBarColorare deprecated and have no effect on Android 15.setStatusBarContrastEnforcedandR.attr#statusBarContrastEnforcedare deprecated but still have an effect on Android 15.
- Display cutout
layoutInDisplayCutoutModeof non-floating windows must beLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS.SHORT_EDGES,NEVER, andDEFAULTare interpreted asALWAYSso that users don't see a black bar caused by the display cutout and appear edge-to-edge.
The following example shows an app before and after targeting Android 15 (API level 35), and before and after applying insets. This example is not comprehensive, this might appear differently on Android Auto.
What to check if your app is already edge-to-edge
If your app is already edge-to-edge and applies insets, you are mostly unimpacted, except in the following scenarios. However, even if you think you aren't impacted, we recommend you test your app.
- You have a non-floating window, such as an
Activitythat usesSHORT_EDGES,NEVERorDEFAULTinstead ofLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. If your app crashes on launch, this might be due to your splashscreen. You can either upgrade the core splashscreen dependency to 1.2.0-alpha01 or later or setwindow.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always. - There might be lower-traffic screens with occluded UI. Verify these
less-visited screens don't have occluded UI. Lower-traffic screens include:
- Onboarding or sign-in screens
- Settings pages
What to check if your app is not already edge-to-edge
If your app is not already edge-to-edge, you are most likely impacted. In addition to the scenarios for apps that are already edge-to-edge, you should consider the following:
- If your app uses Material 3 Components (
androidx.compose.material3) in compose, such asTopAppBar,BottomAppBar, andNavigationBar, these components are likely not impacted because they automatically handle insets. - If your app is using Material 2 Components (
androidx.compose.material) in Compose, these components don't automatically handle insets. However, you can get access to the insets and apply them manually. In androidx.compose.material 1.6.0 and later, use thewindowInsetsparameter to apply the insets manually forBottomAppBar,TopAppBar,BottomNavigation, andNavigationRail. Likewise, use thecontentWindowInsetsparameter forScaffold. - If your app uses views and Material Components
(
com.google.android.material), most views-based Material Components such asBottomNavigationView,BottomAppBar,NavigationRailView, orNavigationView, handle insets and require no additional work. However, you need to addandroid:fitsSystemWindows="true"if usingAppBarLayout. - For custom composables, apply the insets manually as padding. If your
content is within a
Scaffold, you can consume insets using theScaffoldpadding values. Otherwise, apply padding using one of theWindowInsets. - If your app is using views and
BottomSheet,SideSheetor custom containers, apply padding usingViewCompat.setOnApplyWindowInsetsListener. ForRecyclerView, apply padding using this listener and also addclipToPadding="false".
What to check if your app must offer custom background protection
If your app must offer custom background protection to 3-button navigation or
the status bar, your app should place a composable or view behind the system bar
using WindowInsets.Type#tappableElement() to get the 3-button
navigation bar height or WindowInsets.Type#statusBars.
Additional edge-to-edge resources
See the Edge to Edge Views and Edge to Edge Compose guides for additional considerations on applying insets.
Deprecated APIs
The following APIs are deprecated but not disabled:
R.attr#enforceStatusBarContrastR.attr#navigationBarColor(for 3 button navigation, with 80% alpha)Window#isStatusBarContrastEnforcedWindow#setNavigationBarColor(for 3 button navigation, with 80% alpha)Window#setStatusBarContrastEnforced
The following APIs are deprecated and disabled:
R.attr#navigationBarColor(for gesture navigation)R.attr#navigationBarDividerColorR.attr#statusBarColorWindow#setDecorFitsSystemWindowsWindow#getNavigationBarColorWindow#getNavigationBarDividerColorWindow#getStatusBarColorWindow#setNavigationBarColor(for gesture navigation)Window#setNavigationBarDividerColorWindow#setStatusBarColor
Stable configuration
إذا كان تطبيقك يستهدف Android 15 (المستوى 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على الأجهزة القريبة من المربّع.Display.getSize(Point)يتأثّر بشكل غير مباشر بالتغييرات فيConfiguration. تم إيقاف هذه الطريقة نهائيًا بدءًا من المستوى 30 لواجهة برمجة التطبيقات.- تعمل
Display.getMetrics()بهذه الطريقة منذ المستوى 33 لواجهة برمجة التطبيقات.
القيمة التلقائية للسمة elegantTextHeight هي "صحيح"
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.
توضح الأمثلة التالية كيف يمكن لهذه التغييرات تحسين تخطيط النص لبعض الخطوط واللغات.
<TextView android:fontFamily="cursive" android:text="java" />
<TextView android:fontFamily="cursive" android:text="java" android:useBoundsForWidth="true" android:shiftDrawingOffsetForStartOverhang="true" />
<TextView android:text="คอมพิวเตอร์" />
<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:
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:
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 التغييرات التالية على سلوك الكاميرا والوسائط للتطبيقات التي تستهدف Android 15 أو الإصدارات الأحدث.
القيود المفروضة على طلب أولويّة الصوت
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)
يتضمّن 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.