שינויים בהתנהגות: אפליקציות שמטרגטות את Android 15 ואילך

בדומה לגרסאות קודמות, Android 15 כולל שינויים בהתנהגות שעשויים להשפיע על האפליקציה שלכם. שינויי ההתנהגות הבאים רלוונטיים רק לאפליקציות שמטרגטות את Android 15 ואילך. אם האפליקציה שלכם מטרגטת את Android מגרסה 15 ואילך, אתם צריכים לשנות את האפליקציה כדי שהיא תתמוך בהתנהגויות האלה, במקרים הרלוונטיים.

חשוב גם לבדוק את רשימת השינויים בהתנהגות שמשפיעים על כל האפליקציות שפועלות ב-Android 15, בלי קשר ל-targetSdkVersion של האפליקציה.

פונקציונליות עיקרית

‫Android 15 משנה או מרחיב יכולות ליבה שונות של מערכת Android.

שינויים בשירותים שפועלים בחזית

我们将对 Android 15 中的前台服务进行以下更改。

数据同步前台服务超时行为

对于以 Android 15（API 级别 35）或更高版本为目标平台的应用，Android 15 为 dataSync 引入了新的超时行为。此行为也适用于新的 mediaProcessing 前台服务类型。

系统允许应用的 dataSync 服务在 24 小时内总共运行 6 小时，之后系统会调用正在运行的服务的 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 服务在任何 24 小时内总运行时间不超过 6 小时（除非用户与应用互动，重置计时器）。
  3. 仅通过直接的用户互动来启动 dataSync 前台服务；由于您的应用在服务启动时位于前台，因此服务会在应用进入后台后的 6 小时内完整运行。
  4. 请改用替代 API，而不是使用 dataSync 前台服务。

如果您的应用的 dataSync 前台服务在过去 24 小时内运行了 6 小时，则您无法启动其他 dataSync 前台服务，除非用户已将您的应用切换到前台（这会重置计时器）。如果您尝试启动其他 dataSync 前台服务，系统会抛出 ForegroundServiceStartNotAllowedException，并显示类似“前台服务类型 dataSync 的时间限制已用尽”的错误消息。

测试

如需测试应用的行为，您可以启用数据同步超时功能，即使应用未以 Android 15 为目标平台也是如此（前提是应用在 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

新的媒体处理前台服务类型

ב-Android 15 מוצג סוג חדש של שירות שפועל בחזית, mediaProcessing. סוג השירות הזה מתאים לפעולות כמו המרת קידוד של קובצי מדיה. לדוגמה, אפליקציית מדיה עשויה להוריד קובץ אודיו ולהמיר אותו לפורמט אחר לפני ההפעלה. אתם יכולים להשתמש בשירות mediaProcessing שפועל בחזית כדי לוודא שההמרה תימשך גם כשהאפליקציה ברקע.

המערכת מאפשרת לשירותי mediaProcessing של אפליקציה לפעול במשך 6 שעות בסך הכול בתקופה של 24 שעות, ולאחר מכן המערכת קוראת ל-method‏ Service.onTimeout(int, int) של השירות שפועל (הmethod הזה הוצג ב-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, צריך להשתמש בAPI חלופי, כמו WorkManager.

אם שירותי mediaProcessing של האפליקציה פעלו בחזית במשך 6 שעות ב-24 השעות האחרונות, לא תוכלו להפעיל שירות mediaProcessing נוסף בחזית אלא אם המשתמש העביר את האפליקציה לחזית (פעולה שמאפסת את הטיימר). אם תנסו להפעיל שירות mediaProcessing שפועל בחזית, המערכת תשליך את הערך ForegroundServiceStartNotAllowedException עם הודעת שגיאה כמו "Time Limit כבר נשלחת לכל שירות שפועל בחזית מסוג mediaProcessing".

מידע נוסף על סוג השירות mediaProcessing זמין במאמר שינויים בסוגי שירותים בחזית במהדורת Android 15: עיבוד מדיה.

בדיקה

כדי לבדוק את התנהגות האפליקציה, אפשר להפעיל זמן קצוב לתפוגה של עיבוד מדיה גם אם האפליקציה לא מטרגטת ל-Android 15 (כל עוד האפליקציה פועלת במכשיר עם Android 15). כדי להפעיל זמן קצוב לתפוגה, מריצים את הפקודה הבאה ב-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。

测试

如需测试应用的行为，您可以启用这些新限制，即使您的应用并未以 Android 15 为目标平台（只要应用在 Android 15 设备上运行）也是如此。运行以下 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 权限时启动前台服务的限制

בעבר, אם לאפליקציה הייתה הרשאה SYSTEM_ALERT_WINDOW, היא הייתה יכולה להפעיל שירות שפועל בחזית גם אם האפליקציה הייתה כרגע ברקע (כפי שמתואר בקטע פטורים מהגבלות הפעלה ברקע).

אם אפליקציה מטרגטת את Android 15, הפטור הזה מצומצם יותר עכשיו. עכשיו האפליקציה צריכה לקבל את ההרשאה SYSTEM_ALERT_WINDOW וגם להציג חלון שכבת-על גלוי. כלומר, האפליקציה צריכה קודם להפעיל חלון TYPE_APPLICATION_OVERLAY וגם החלון צריך להיות גלוי לפני שמפעילים שירות בחזית.

אם האפליקציה תנסה להפעיל שירות שפועל בחזית מהרקע בלי לעמוד בדרישות החדשות האלה (ואין לה פטור אחר), המערכת תשליך את השגיאה ForegroundServiceStartNotAllowedException.

אם האפליקציה שלכם מצהירה על ההרשאה SYSTEM_ALERT_WINDOW ומפעילה שירותים שפועלים בחזית מהרקע, היא עשויה להיות מושפעת מהשינוי הזה. אם האפליקציה מקבלת את השגיאה ForegroundServiceStartNotAllowedException, צריך לבדוק את סדר הפעולות של האפליקציה ולוודא שכבר יש לה חלון שכבת-על פעיל לפני שהיא מנסה להפעיל שירות בחזית מהרקע. תוכלו לבדוק אם החלון של שכבת-העל גלוי כרגע באמצעות קריאה ל-View.getWindowVisibility(), או לבטל את View.onWindowVisibilityChanged() כדי לקבל התראה בכל פעם שהחשיפה משתנה.

בדיקה

כדי לבדוק את התנהגות האפליקציה, אפשר להפעיל את ההגבלות החדשות האלה גם אם האפליקציה לא מטרגטת ל-Android 15 (כל עוד האפליקציה פועלת במכשיר עם Android 15). כדי להפעיל את ההגבלות החדשות האלה על הפעלת שירותים שפועלים בחזית מהרקע, מריצים את הפקודה הבאה של adb:

adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name

שינויים במועד שבו אפליקציות יכולות לשנות את המצב הגלובלי של המצב 'נא לא להפריע'

אפליקציות שמטרגטות את Android מגרסה 15 ואילך (רמת API 35 ואילך) לא יכולות יותר לשנות את המצב או המדיניות הגלובלית של 'נא לא להפריע' במכשיר (על ידי שינוי ההגדרות של המשתמש או השבתת מצב 'נא לא להפריע'). במקום זאת, האפליקציות צריכות לספק AutomaticZenRule, שהמערכת משלבת במדיניות גלובלית לפי התוכנית הקיימת של 'המדיניות המחמירה ביותר מנצחת'. קריאות ל-APIs קיימים שקודם השפיעו על המצב הגלובלי (setInterruptionFilter,‏ setNotificationPolicy) יוצרות או מעדכנות AutomaticZenRule משתנה נסתר, שמופעל או מושבת בהתאם למחזור הקריאות של קריאות ה-API האלה.

חשוב לזכור שהשינוי הזה משפיע על ההתנהגות הנצפית רק אם האפליקציה מבצעת קריאה ל-setInterruptionFilter(INTERRUPTION_FILTER_ALL) ומצפה שהקריאה הזו תשבית AutomaticZenRule שהבעלים שלו הפעילו בעבר.

שינויים ב-OpenJDK API

Android 15 continues the work of refreshing Android's core libraries to align with the features in the latest OpenJDK LTS releases.

Some of these changes can affect app compatibility for apps targeting Android 15 (API level 35):

  • Changes to string formatting APIs: Validation of argument index, flags, width, and precision are now more strict when using the following String.format() and Formatter.format() APIs:

    For example, the following exception is thrown when an argument index of 0 is used (%0 in the format string):

    IllegalFormatArgumentIndexException: Illegal format argument index = 0

    In this case, the issue can be fixed by using an argument index of 1 (%1 in the format string).

  • Changes to component type of Arrays.asList(...).toArray(): When using Arrays.asList(...).toArray(), the component type of the resulting array is now an Object—not the type of the underlying array's elements. So the following code throws a ClassCastException:

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

    For this case, to preserve String as the component type in the resulting array, you could use Collection.toArray(Object[]) instead:

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

  • Changes to language code handling: When using the Locale API, language codes for Hebrew, Yiddish, and Indonesian are no longer converted to their obsolete forms (Hebrew: iw, Yiddish: ji, and Indonesian: in). When specifying the language code for one of these locales, use the codes from ISO 639-1 instead (Hebrew: he, Yiddish: yi, and Indonesian: id).

  • Changes to random int sequences: Following the changes made in https://bugs.openjdk.org/browse/JDK-8301574, the following Random.ints() methods now return a different sequence of numbers than the Random.nextInt() methods do:

    Generally, this change shouldn't result in app-breaking behavior, but your code shouldn't expect the sequence generated from Random.ints() methods to match Random.nextInt().

The new SequencedCollection API can affect your app's compatibility after you update compileSdk in your app's build configuration to use Android 15 (API level 35):

  • Collision with MutableList.removeFirst() and MutableList.removeLast() extension functions in kotlin-stdlib

    The List type in Java is mapped to the MutableList type in Kotlin. Because the List.removeFirst() and List.removeLast() APIs have been introduced in Android 15 (API level 35), the Kotlin compiler resolves function calls, for example list.removeFirst(), statically to the new List APIs instead of to the extension functions in kotlin-stdlib.

    If an app is re-compiled with compileSdk set to 35 and minSdk set to 34 or lower, and then the app is run on Android 14 and lower, a runtime error is thrown:

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

    The existing NewApi lint option in Android Gradle Plugin can catch these new API usages.

    ./gradlew lint

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

    To fix the runtime exception and lint errors, the removeFirst() and removeLast() function calls can be replaced with removeAt(0) and removeAt(list.lastIndex) respectively in Kotlin. If you're using Android Studio Ladybug | 2024.1.3 or higher, it also provides a quick fix option for these errors.

    Consider removing @SuppressLint("NewApi") and lintOptions { disable 'NewApi' } if the lint option has been disabled.

  • Collision with other methods in Java

    New methods have been added into the existing types, for example, List and Deque. These new methods might not be compatible with the methods with the same name and argument types in other interfaces and classes. In the case of a method signature collision with incompatibility, the javac compiler outputs a build-time error. For example:

    Example error 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

    Example error 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

    Example 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

    To fix these build errors, the class implementing these interfaces should override the method with a compatible return type. For example:

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

אבטחה

‫Android 15 כולל שינויים שמקדמים את אבטחת המערכת כדי לעזור להגן על אפליקציות ומשתמשים מפני אפליקציות זדוניות.

גרסאות TLS מוגבלות

ב-Android 15 יש הגבלה על השימוש ב-TLS בגרסאות 1.0 ו-1.1. הגרסאות האלה הוצאו משימוש ב-Android, אבל עכשיו אסור להשתמש בהן באפליקציות שמטרגטות את Android 15.

הפעלות מאובטחות של פעילות ברקע

‫Android 15 מגן על המשתמשים מפני אפליקציות זדוניות ומעניק להם יותר שליטה במכשירים שלהם. השינויים שנוספו מונעים מאפליקציות זדוניות שפועלות ברקע להעביר אפליקציות אחרות לחזית, להגדיל את ההרשאות שלהן ולנצל לרעה את האינטראקציה עם המשתמש. ההשקה של פעילות ברקע מוגבלת מאז Android 10 (רמת API‏ 29).

שינויים אחרים

  • שינוי ברירת המחדל של יוצרי PendingIntent לחסימת הפעלות של פעילות ברקע. כך אפליקציות לא יוצרות בטעות PendingIntent שגורמים זדוניים יכולים לנצל לרעה.
  • אל תעבירו אפליקציה לחזית אלא אם PendingIntentהשולח מאשר זאת. המטרה של השינוי הזה היא למנוע מאפליקציות זדוניות לנצל לרעה את היכולת להתחיל פעילויות ברקע. כברירת מחדל, לאפליקציות אסור להעביר את ערימת המשימות לחזית, אלא אם היוצר מאשר הרשאות להפעלת פעילות ברקע או שלשולח יש הרשאות להפעלת פעילות ברקע.
  • איך קובעים איך הפעילות העליונה בערימת המשימות יכולה לסיים את המשימה שלה. אם הפעילות העליונה מסיימת משימה, מערכת Android תחזור למשימה האחרונה שהייתה פעילה. בנוסף, אם פעילות שלא נמצאת בחלק העליון מסיימת את המשימה שלה, מערכת Android תחזור למסך הבית ולא תחסום את סיום הפעילות הזו.
  • מניעת הפעלה של פעילויות שרירותיות מאפליקציות אחרות במשימה שלכם. השינוי הזה מונע מאפליקציות זדוניות לבצע פישינג על משתמשים על ידי יצירת פעילויות שנראות כאילו הן מגיעות מאפליקציות אחרות.
  • חסימה של חלונות לא גלויים כך שלא ייכללו בהפעלות של פעילות ברקע. כך אפליקציות זדוניות לא יכולות לנצל לרעה הפעלות של פעילות ברקע כדי להציג למשתמשים תוכן לא רצוי או זדוני.

כוונות רכישה בטוחות יותר

‫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: תצוגה מקצה לקצה נאכפת כברירת מחדל, ויש גם שינויים בהגדרות, כמו הגדרת ברירת המחדל של שורת הסטטוס.

אכיפה מקצה לקצה

אפליקציות מוצגות מקצה לקצה כברירת מחדל במכשירים שפועלים עם Android 15 אם האפליקציה מטרגטת ל-Android 15 (רמת API 35).

אפליקציה שמטרגטת ל-Android 14 ולא מוצגת מקצה לקצה במכשיר עם Android 15.


אפליקציה שמטרגטת ל-Android 15 (רמת API 35) ומוצגת מקצה לקצה במכשיר עם Android 15. האפליקציה הזו משתמשת בעיקר ברכיבי Material 3 Compose שמחילים באופן אוטומטי שוליים פנימיים. המסך הזה לא מושפע לרעה מהאכיפה של תצוגה מקצה לקצה ב-Android 15.

זהו שינוי שעלול לגרום לבעיות, ויכול להיות שתהיה לו השפעה שלילית על ממשק המשתמש של האפליקציה. השינויים ישפיעו על האזורים הבאים בממשק המשתמש:

  • סרגל ניווט עם ידית לתנועות
    • שקוף כברירת מחדל.
    • ההיסט התחתון מושבת, ולכן התוכן מוצג מאחורי סרגל הניווט של המערכת, אלא אם מוחלים שוליים פנימיים.
    • האפשרויות setNavigationBarColor ו-R.attr#navigationBarColor הוצאו משימוש ולא משפיעות על הניווט באמצעות תנועות.
    • setNavigationBarContrastEnforced ו-R.attr#navigationBarContrastEnforced ממשיכים שלא להשפיע על הניווט באמצעות מחוות.
  • ניווט ב-3 כפתורים
    • השקיפות מוגדרת כברירת מחדל ל-80%, והצבע יכול להיות זהה לצבע הרקע של החלון.
    • ההיסט התחתון מושבת, כך שהתוכן מוצג מאחורי סרגל הניווט של המערכת, אלא אם מוחלים שוליים פנימיים.
    • setNavigationBarColor ו-R.attr#navigationBarColor מוגדרים כברירת מחדל כך שיתאימו לרקע של החלון. כדי שברירת המחדל הזו תחול, הרקע של החלון צריך להיות פריט גרפי שניתן להזזה בצבע. ממשק ה-API הזה הוצא משימוש, אבל הוא ממשיך להשפיע על ניווט ב-3 כפתורים.
    • הערך של setNavigationBarContrastEnforced ושל R.attr#navigationBarContrastEnforced הוא TRUE כברירת מחדל, ולכן מתווסף רקע אטום ב-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 (רמת API‏ 35), ולפני ואחרי החלת אזורי inset. הדוגמה הזו לא מקיפה, והמראה שלה עשוי להיות שונה ב-Android Auto.

אפליקציה שמטרגטת ל-Android 14 ולא מוצגת מקצה לקצה במכשיר עם Android 15.
אפליקציה שמטרגטת ל-Android 15 (רמת API 35) ומוצגת מקצה לקצה במכשיר עם Android 15. עם זאת, הרבה רכיבים מוסתרים עכשיו על ידי שורת הסטטוס, ניווט ב-3 כפתורים או מגרעת במסך, בגלל האכיפה של תצוגה מקצה לקצה ב-Android 15. ממשק משתמש מוסתר כולל את סרגל האפליקציות העליון של Material 2, כפתורי פעולה צפים ופריטים ברשימה.
אפליקציה שמטרגטת ל-Android 15 (רמת API 35), מוצגת מקצה לקצה במכשיר Android 15 ומחילת שוליים פנימיים כך שממשק המשתמש לא מוסתר.
מה צריך לבדוק אם האפליקציה כבר מוצגת מקצה לקצה

אם האפליקציה שלכם כבר מכסה את כל המסך ומוגדרים בה שוליים פנימיים, השינוי לא ישפיע עליה ברוב המקרים, למעט בתרחישים הבאים. עם זאת, גם אם אתם חושבים שהאפליקציה שלכם לא מושפעת, מומלץ לבדוק אותה.

  • יש לכם חלון לא צף, כמו 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) ב-Compose, כמו TopAppBar,‏ BottomAppBar ו-NavigationBar, סביר להניח שהרכיבים האלה לא יושפעו כי הם מטפלים באופן אוטומטי ב-insets.
  • אם האפליקציה שלכם משתמשת ברכיבי Material 2 ‏( androidx.compose.material) ב-Compose, הרכיבים האלה לא מטפלים באופן אוטומטי ב-insets. עם זאת, אפשר לקבל גישה לתמונות הממוזערות ולהוסיף אותן באופן ידני. ב-androidx.compose.material מגרסה 1.6.0 ואילך, אפשר להשתמש בפרמטר windowInsets כדי להחיל את השוליים הפנימיים באופן ידני על BottomAppBar, TopAppBar, BottomNavigation ו-NavigationRail. באופן דומה, משתמשים בפרמטר contentWindowInsets עבור Scaffold.
  • אם האפליקציה שלכם משתמשת בתצוגות ורכיבי Material (‏com.google.android.material), רוב רכיבי Material מבוססי-תצוגות, כמו BottomNavigationView,‏ BottomAppBar, ‏ NavigationRailView או NavigationView, מטפלים בשוליים הפנימיים ולא דורשים עבודה נוספת. עם זאת, אם משתמשים ב-AppBarLayout, צריך להוסיף android:fitsSystemWindows="true".
  • לרכיבי composable מותאמים אישית, צריך להחיל את השוליים הפנימיים באופן ידני כריפוד. אם התוכן נמצא בתוך Scaffold, אפשר להשתמש בערכי הריווח הפנימי של Scaffold כדי להגדיר את השוליים הפנימיים. אחרת, מוסיפים ריווח באמצעות אחת מהאפשרויות של WindowInsets.
  • אם האפליקציה שלכם משתמשת בתצוגות וב-BottomSheet, ב-SideSheet או במאגרי תגים בהתאמה אישית, צריך להחיל ריווח פנימי באמצעות ViewCompat.setOnApplyWindowInsetsListener. ב-RecyclerView, מוסיפים מרווח פנימי באמצעות מאזין זה וגם מוסיפים clipToPadding="false".
מה צריך לבדוק אם האפליקציה חייבת להציע הגנה מותאמת אישית ברקע

אם האפליקציה שלכם צריכה להציע הגנה מותאמת אישית ברקע לניווט ב-3 כפתורים או לשורת הסטטוס, האפליקציה צריכה למקם רכיב שאפשר להרכיב או תצוגה מאחורי סרגל המערכת באמצעות WindowInsets.Type#tappableElement() כדי לקבל את הגובה של סרגל הניווט עם 3 הלחצנים או WindowInsets.Type#statusBars.

מקורות מידע נוספים על תצוגה מקצה לקצה

במאמרים Edge to Edge Views ו-Edge to Edge Compose מפורטים שיקולים נוספים לגבי החלת שוליים פנימיים.

ממשקי API שהוצאו משימוש

ממשקי ה-API הבאים הוצאו משימוש אבל לא הושבתו:

ממשקי ה-API הבאים הוצאו משימוש והושבתו:

הגדרה יציבה

אם האפליקציה מטרגטת ל-Android 15 (רמת API 35) ומעלה, התג Configuration כבר לא מחריג את סרגלי המערכת. אם אתם משתמשים בגודל המסך במחלקה Configuration לחישוב הפריסה, כדאי להחליף אותו בחלופות טובות יותר כמו ViewGroup, WindowInsets או WindowMetricsCalculator, בהתאם לצורך.

‫Configuration זמין החל מ-API 1. בדרך כלל הוא מתקבל מ-Activity.onConfigurationChanged. הוא מספק מידע כמו צפיפות החלונות, הכיוון והגדלים. מאפיין חשוב לגבי גדלי החלונות שמוחזרים מ-Configuration הוא שבעבר לא נכללו בהם סרגלי המערכת.

גודל ההגדרה משמש בדרך כלל לבחירת משאבים, כמו /res/layout-h500dp, וזה עדיין תרחיש שימוש תקף. עם זאת, תמיד המלצנו שלא להשתמש בו לחישוב פריסה. אם כן, כדאי להתרחק ממנו עכשיו. צריך להחליף את השימוש ב-Configuration במשהו מתאים יותר בהתאם לתרחיש לדוגמה.

אם משתמשים בו לחישוב הפריסה, צריך להשתמש ב-ViewGroup מתאים, כמו CoordinatorLayout או ConstraintLayout. אם משתמשים בו כדי לקבוע את הגובה של סרגל הניווט של המערכת, צריך להשתמש ב-WindowInsets. אם רוצים לדעת מה הגודל הנוכחי של חלון האפליקציה, משתמשים ב-computeCurrentWindowMetrics.

ברשימה הבאה מפורטים השדות שיושפעו מהשינוי הזה:

  • הגודל של Configuration.screenWidthDp ושל screenHeightDp כבר לא כולל את סרגלי המערכת.
  • השינויים ב-screenWidthDp וב-screenHeightDp משפיעים באופן עקיף על Configuration.smallestScreenWidthDp.
  • השינויים ב-screenWidthDp וב-screenHeightDp משפיעים באופן עקיף על Configuration.orientation במכשירים שהיחס בין האורך לרוחב שלהם קרוב ל-1:1.
  • השינויים ב-Configuration משפיעים באופן עקיף על Display.getSize(Point). החל מרמת API‏ 30, השיטה הזו הוצאה משימוש.
  • Display.getMetrics() כבר פועל כך החל מרמת API‏ 33.

ערך ברירת המחדל של המאפיין elegantTextHeight הוא true

对于以 Android 15（API 级别 35）为目标平台的应用，elegantTextHeight TextView 属性默认会变为 true，将默认使用的紧凑字体替换为一些具有较大垂直测量的脚本，使其更易于阅读。紧凑字体旨在防止布局中断；Android 13（API 级别 33）允许文本布局利用 fallbackLineSpacing 属性拉伸垂直高度，从而防止许多此类中断。

在 Android 15 中，系统中仍保留了紧凑字体，因此您的应用可以将 elegantTextHeight 设置为 false 以获得与之前相同的行为，但即将发布的版本不太可能支持此字体。因此，如果您的应用支持以下脚本：阿拉伯语、老挝语、缅甸语、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语，请将 elegantTextHeight 设置为 true 以测试您的应用。

针对以 Android 14（API 级别 34）及更低版本为目标平台的应用的 elegantTextHeight 行为。
以 Android 15 为目标平台的应用的 elegantTextHeight 行为。

רוחב TextView משתנה עבור צורות מורכבות של אותיות

בגרסאות קודמות של Android, חלק מגופנים או שפות עם כתב מחובר עם עיצוב מורכב עשויים לצייר את האותיות באזור של התו הקודם או הבא. במקרים מסוימים, אותיות כאלה נחתכו בנקודת ההתחלה או הסיום. החל מ-Android 15, TextView מקצה רוחב לציור מספיק מקום לאותיות כאלה ומאפשר לאפליקציות לבקש תוספת רווח שמימין כדי למנוע חיתוך.

מכיוון שהשינוי הזה משפיע על האופן שבו TextView מחליט על הרוחב, TextView מקצה יותר רוחב כברירת מחדל אם האפליקציה מטרגטת ל-Android 15 (רמת API 35) ואילך. אפשר להפעיל או להשבית את ההתנהגות הזו על ידי שליחת קריאה ל-API setUseBoundsForWidth ב-TextView.

הוספת רווח פנימי בצד ימין עלולה לגרום לחוסר התאמה של פריסות קיימות, ולכן הוא לא מתווסף כברירת מחדל גם לאפליקציות שמטרגטות את Android מגרסה 15 ואילך. עם זאת, אפשר להוסיף עוד ריפוד כדי למנוע חיתוך על ידי קריאה ל-setShiftDrawingOffsetForStartOverhang.

הדוגמאות הבאות מראות איך השינויים האלה יכולים לשפר את פריסת הטקסט בגופנים ובשפות מסוימים.

פריסה רגילה של טקסט באנגלית בגופן כתב יד. חלק מהאותיות חתוכות. זהו ה-XML התואם:

<TextView
    android:fontFamily="cursive"
    android:text="java" />
פריסה לאותו טקסט באנגלית עם רוחב ומרווח נוספים. זהו ה-XML התואם:

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />
פריסה רגילה של טקסט תאילנדי. חלק מהאותיות חתוכות. זהו קוד ה-XML התואם:

<TextView
    android:text="คอมพิวเตอร์" />
פריסה של אותו טקסט בתאילנדית עם רוחב נוסף וריפוי נוסף. זהו קוד ה-XML המתאים:

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

גובה שורה שמוגדר כברירת מחדל ב-EditText בהתאם ללוקאל

在较低版本的 Android 中，文本布局会拉伸文本的高度，以满足与当前语言区域匹配的字体的行高。例如，如果内容是日语，由于日语字体的行高略高于拉丁字体，因此文本的高度会略高。不过，尽管行高存在这些差异，但无论使用的是哪种语言区域，EditText 元素的大小都是统一的，如下图所示：

三个框，表示可以包含英语 (en)、日语 (ja) 和缅甸语 (my) 文本的 EditText 元素。EditText 的高度相同，即使这些语言的行高各不相同。

对于以 Android 15（API 级别 35）为目标平台的应用，现在为 EditText 预留了最小行高，以匹配指定语言区域的参考字体，如下图所示：

三个框，表示可以包含英语 (en)、日语 (ja) 和缅甸语 (my) 文本的 EditText 元素。EditText 的高度现在包含足够的空间来容纳这些语言字体的默认行高。

如有需要，您的应用可以将 useLocalePreferredLineHeightForMinimum 属性指定为 false，以恢复之前的行为；您的应用还可以在 Kotlin 和 Java 中使用 setMinimumFontMetrics API 设置自定义最小垂直指标。

מצלמה ומדיה

ב-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 接口（具体取决于应用的目标 API 级别），但只要您使用任何非 SDK 方法或字段，就很有可能会造成应用功能异常。

如果您不确定自己的应用是否使用了非 SDK 接口，则可以通过 测试该应用来进行确认。如果您的应用依赖非 SDK 接口，则应开始计划迁移到 SDK 替代方案。不过，我们知道某些应用存在使用非 SDK 接口的合理场景。如果您无法为应用中的某项功能找到使用非 SDK 接口的替代方案，则应该请求新的公共 API。

מידע נוסף על השינויים בגרסה הזו של Android זמין במאמר עדכונים לגבי הגבלות על ממשקים שאינם SDK ב-Android 15. מידע נוסף על ממשקים שאינם ב-SDK זמין במאמר הגבלות על ממשקים שאינם ב-SDK.