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

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

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

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

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

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

אנחנו מבצעים את השינויים הבאים בשירותים שפועלים בחזית ב-Android 15.

• התנהגות של זמן קצוב לתפוגה בשירות 'סנכרון נתונים' שפועל בחזית
• סוג חדש של שירות שפועל בחזית לעיבוד מדיה
• הגבלות על מקלטי שידורים מסוג BOOT_COMPLETED שמפעילים שירותים שפועלים בחזית
• הגבלות על הפעלת שירותים שפועלים בחזית בזמן שאפליקציה מחזיקה בהרשאה SYSTEM_ALERT_WINDOW

התנהגות זמן קצוב לתפוגה של שירות בחזית לסנכרון נתונים

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

如果您的应用的 mediaProcessing 前台服务在过去 24 小时内运行了 6 小时，则您无法启动其他 mediaProcessing 前台服务，除非用户将您的应用切换到前台（这会重置计时器）。如果您尝试启动另一个 mediaProcessing 前台服务，系统会抛出 ForegroundServiceStartNotAllowedException，并显示类似于“前台服务类型 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 אסור להפעיל את הסוגים הבאים של שירותים שפועלים בחזית:

• dataSync
• camera
• mediaPlayback
• phoneCall
• mediaProjection
• microphone (ההגבלה הזו חלה על microphone מאז Android 14)

אם מקלט 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 אנחנו ממשיכים את העבודה על רענון ספריות הליבה של Android כדי להתאים אותן לתכונות בגרסאות ה-LTS האחרונות של OpenJDK.

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

• שינויים בממשקי API לעיצוב מחרוזות: האימות של אינדקס הארגומנט, הדגלים, הרוחב והדיוק מחמיר יותר עכשיו כשמשתמשים בממשקי ה-API הבאים: 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]);
  

• שינויים בטיפול בקוד שפה: כשמשתמשים ב-API‏ Locale, קודי השפה לעברית, יידיש ואינדונזית לא מומרים יותר לפורמטים מיושנים (עברית: iw, יידיש: ji ואינדונזית: in). כשמציינים את קוד השפה לאחד מהלוקאלים האלה, צריך להשתמש בקודים מ-ISO 639-1 (עברית: he, יידיש: yi ואינדונזית: id).

• שינויים ברצפים של מספרים אקראיים: בעקבות השינויים שבוצעו בכתובת https://bugs.openjdk.org/browse/JDK-8301574, השיטות הבאות של Random.ints() מחזירות עכשיו רצף שונה של מספרים מהשיטות של Random.nextInt():

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

  בדרך כלל, השינוי הזה לא אמור לגרום להתנהגות שמשבשת את האפליקציה, אבל הקוד לא אמור לצפות שהרצף שנוצר משיטות Random.ints() יתאים ל-Random.nextInt().

ה-API החדש SequencedCollection יכול להשפיע על התאימות של האפליקציה אחרי עדכון compileSdk בתצורת ה-build של האפליקציה לשימוש ב-Android 15 (רמת API 35):

• התנגשות עם פונקציות ההרחבה MutableList.removeFirst() ו-MutableList.removeLast() ב-kotlin-stdlib

  הסוג List ב-Java ממופה לסוג MutableList ב-Kotlin. ממשקי ה-API‏ List.removeFirst() ו-List.removeLast() הוצגו ב-Android 15 (רמת API 35), לכן קומפיילר Kotlin פותר קריאות לפונקציות, למשל list.removeFirst(), באופן סטטי לממשקי ה-API החדשים 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 הקיימת בפלאגין של Android Gradle כדי לזהות את השימושים החדשים ב-API.

  ./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() ב-Kotlin בפונקציות removeAt(0) ו-removeAt(list.lastIndex) בהתאמה. אם אתם משתמשים ב-Android Studio Ladybug | 2024.1.3 או בגרסה מתקדמת יותר, מוצגת גם אפשרות לתיקון מהיר של השגיאות האלה.

  אם האפשרות lint מושבתת, כדאי להסיר את התווים @SuppressLint("NewApi") ו-lintOptions { disable 'NewApi' }.

• התנגשות עם שיטות אחרות ב-Java

  נוספו methods חדשות לסוגים הקיימים, למשל, 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
  

  כדי לתקן את שגיאות ה-build האלה, המחלקה שמטמיעה את הממשקים האלה צריכה לבטל את השיטה עם סוג החזרה תואם. לדוגמה:

  @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, משתמשים בשיטה הבאה:

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

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

חוויית המשתמש וממשק המשתמש של המערכת

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

שינויים בהזחה של חלון

Android 15 中与窗口内边距相关的两项变更：默认强制执行边到边，此外还有配置变更，例如系统栏的默认配置。

全面实施政策

如果应用以 Android 15（API 级别 35）为目标平台，则在搭载 Android 15 的设备上默认以无边框显示。

这是一项重大变更，可能会对应用的界面产生不利影响。这些变更会影响以下界面区域：

• 手势提示条导航栏
  • 默认透明。
  • 底部偏移已停用，因此除非应用了边衬区，否则内容会绘制在系统导航栏后面。
  • setNavigationBarColor 和 R.attr#navigationBarColor 已弃用，不会影响手势导航。
  • setNavigationBarContrastEnforced 和 R.attr#navigationBarContrastEnforced 仍不会影响手势导航。
• 三按钮导航
  • 默认情况下，不透明度设置为 80%，颜色可能与窗口背景颜色一致。
  • 底部偏移已停用，因此除非应用了边衬区，否则内容会绘制在系统导航栏后面。
  • setNavigationBarColor 和 R.attr#navigationBarColor 默认设置为与窗口背景颜色一致。窗口背景必须是颜色可绘制对象，才能应用此默认设置。此 API 已弃用，但仍会影响三按钮导航。
  • setNavigationBarContrastEnforced 和 R.attr#navigationBarContrastEnforced 默认值为 true，这会在三按钮导航中添加 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（API 级别 35）为目标平台之前和之后，以及在应用边衬区之前和之后的效果。此示例并不全面，在 Android Auto 上可能会显示不同的效果。

如果您的应用已以无边框显示，需要检查哪些内容

如果您的应用已以 无边框 显示并应用了边衬区，则大部分情况下 不会受到影响，但在以下情形中除外。不过，即使您认为自己不会受到影响，我们也建议您测试应用。

• 您有一个非浮动窗口，例如使用 SHORT_EDGES、NEVER 或 DEFAULT 而不是 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS 的 Activity。如果您的应用在启动时崩溃，可能是因为启动画面所致。您可以将 核心 启动画面 依赖项升级到 1.2.0-alpha01 或更高版本，也可以设置 window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always。
• 可能存在流量较低的屏幕，其界面被遮盖。验证这些访问量较少的屏幕是否没有被遮盖的界面。流量较低的屏幕包括：
  • 新手入门或登录屏幕
  • “设置”页面

如果您的应用尚未以无边框显示，需要检查哪些内容

如果您的应用尚未以无边框显示，则很可能会受到影响。除了已以无边框显示的应用的情形之外，您还应考虑以下情况：

• 如果您的应用在 Compose 中使用了 Material 3 组件 ( androidx.compose.material3)，例如 TopAppBar、 BottomAppBar 和 NavigationBar，这些组件可能不会 受到影响，因为它们会自动处理边衬区。
• 如果应用使用的是 Compose 中的 Material 2 组件 ( androidx.compose.material)，这些组件 本身并不会自动处理边衬区。不过，您可以获得边衬区的访问权限，然后手动应用边衬区。在 androidx.compose.material 1.6.0 及更高版本中，使用 windowInsets 参数可为 BottomAppBar、TopAppBar、 BottomNavigation 和 NavigationRail 手动应用边衬区。 同样，对于 Scaffold，请使用 contentWindowInsets 参数。
• 如果应用使用了视图和 Material 组件 (com.google.android.material)，则大多数基于视图的 Material 组件（例如 BottomNavigationView、BottomAppBar、 NavigationRailView 或 NavigationView）都会处理边衬区，因此不需要执行额外的操作。不过，您需要添加 android:fitsSystemWindows="true" ，如果使用 AppBarLayout。
• 对于自定义可组合项，请手动应用边衬区作为内边距。如果您的 内容位于 Scaffold 中，则可以使用 Scaffold 内边距值来使用边衬区。否则，请使用其中一个 WindowInsets应用内边距。
• 如果应用使用的是视图和 BottomSheet、SideSheet 或自定义 容器，请使用 ViewCompat.setOnApplyWindowInsetsListener应用内边距。对于 RecyclerView，请使用此监听器应用内边距，同时添加 clipToPadding="false"。

如果您的应用必须提供自定义背景保护，需要检查哪些内容

如果您的应用必须为“三按钮”导航或 状态栏提供自定义背景保护，则应用应使用 WindowInsets.Type#tappableElement() 将可组合函数或视图放置在系统栏后面 ，以获取“三按钮” 导航栏高度或 WindowInsets.Type#statusBars。

其他无边框资源

如需了解有关应用边衬区的其他注意事项，请参阅无边框视图和无边框 Compose 指南。

已弃用的 API

以下 API 已弃用，但未停用：

• R.attr#enforceStatusBarContrast
• R.attr#navigationBarColor （适用于三按钮导航，alpha 为 80%）
• Window#isStatusBarContrastEnforced
• Window#setNavigationBarColor （适用于三按钮导航，alpha 为 80%）
• Window#setStatusBarContrastEnforced

以下 API 已弃用并已停用：

• R.attr#navigationBarColor （适用于手势导航）
• R.attr#navigationBarDividerColor
• R.attr#statusBarColor
• Window#setDecorFitsSystemWindows
• Window#getNavigationBarColor
• Window#getNavigationBarDividerColor
• Window#getStatusBarColor
• Window#setNavigationBarColor （适用于手势导航）
• Window#setNavigationBarDividerColor
• Window#setStatusBarColor

稳定配置

אם האפליקציה מטרגטת ל-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 以测试您的应用。

שינויים ברוחב של 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 元素的大小都是统一的，如下图所示：

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

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

מצלמה ומדיה

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

הגבלות על בקשות למיקוד אודיו

以 Android 15（API 级别 35）为目标平台的应用必须是顶部应用或正在运行前台服务，才能请求音频焦点。如果应用在未满足上述任一要求的情况下尝试请求焦点，调用将返回 AUDIOFOCUS_REQUEST_FAILED。

如需详细了解音频焦点，请参阅管理音频焦点。

הגבלות שאינן קשורות ל-SDK עודכנו

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

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

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

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