בדומה לגרסאות קודמות, Android 15 כולל שינויים בהתנהגות שעשויים להשפיע על האפליקציה שלכם. שינויי ההתנהגות הבאים רלוונטיים רק לאפליקציות שמטרגטות את Android 15 ואילך. אם האפליקציה שלכם מטרגטת את Android מגרסה 15 ואילך, אתם צריכים לשנות את האפליקציה כדי שהיא תתמוך בהתנהגויות האלה, במקרים הרלוונטיים.
חשוב גם לבדוק את רשימת השינויים בהתנהגות שמשפיעים על כל האפליקציות שפועלות ב-Android 15, בלי קשר ל-targetSdkVersion
של האפליקציה.
פונקציונליות עיקרית
Android 15 משנה או מרחיב יכולות ליבה שונות של מערכת Android.
שינויים בשירותים שפועלים בחזית
אנחנו מבצעים את השינויים הבאים בשירותים שפועלים בחזית ב-Android 15.
- התנהגות של זמן קצוב לתפוגה בשירות 'סנכרון נתונים' שפועל בחזית
- סוג חדש של שירות שפועל בחזית לעיבוד מדיה
- הגבלות על מקלטי שידורים מסוג
BOOT_COMPLETED
שמפעילים שירותים שפועלים בחזית - הגבלות על הפעלת שירותים שפועלים בחזית בזמן שאפליקציה מחזיקה בהרשאה
SYSTEM_ALERT_WINDOW
התנהגות זמן קצוב לתפוגה של שירות בחזית לסנכרון נתונים
ב-Android 15 נוספה התנהגות חדשה של זמן קצוב לתפוגה ל-dataSync
באפליקציות שמטרגטות ל-Android 15 (רמת API 35) ואילך. ההתנהגות הזו רלוונטית גם לסוג החדש של שירות mediaProcessing
שפועל בחזית.
המערכת מאפשרת לשירותי dataSync
של אפליקציה לפעול במשך 6 שעות בסך הכול בתקופה של 24 שעות, ולאחר מכן המערכת קוראת ל-method 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
רק כתוצאה מאינטראקציה ישירה של המשתמש. מכיוון שהאפליקציה פועלת בחזית כשהשירות מופעל, השירות פועל במשך 6 שעות בלבד אחרי שהאפליקציה עוברת לרקע. - במקום להשתמש בשירות
dataSync
שפועל בחזית, צריך להשתמש בAPI חלופי.
אם השירותים שפועלים בחזית ב-dataSync
באפליקציה פועלים במשך 6 שעות ב-24 השעות האחרונות, לא ניתן להפעיל שירות נוסף שפועל בחזית של dataSync
אלא אם המשתמש העביר את האפליקציה לחזית האפליקציה (הפעולה הזו מאפסת את הטיימר). אם תנסו להפעיל שירות אחר שפועל בחזית של dataSync
, המערכת תגרור ForegroundServiceStartNotAllowedException
הודעת שגיאה כמו "Time limit limit for data Sync type" (סוג שירות שפועל בחזית).
בדיקה
כדי לבדוק את התנהגות האפליקציה, אפשר להפעיל זמן קצוב לסיום הסנכרון של הנתונים גם אם האפליקציה לא מטרגטת ל-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]"
כדי למנוע את החריגה, אפשר לבצע אחת מהפעולות הבאות:
- עליך להטמיע בשירות שלך את השיטה החדשה של
Service.onTimeout(int, int)
. כשהאפליקציה מקבלת את הקריאה החוזרת, חשוב להקפיד להתקשר ל-stopSelf()
תוך מספר שניות. (אם לא מפסיקים את האפליקציה מיד, המערכת יוצרת כשל). - חשוב לוודא ששירותי
mediaProcessing
של האפליקציה לא פועלים במשך יותר מ-6 שעות בסך הכול בכל תקופה של 24 שעות (אלא אם המשתמש יוצר אינטראקציה עם האפליקציה, ומאפס את הטיימר). - כדאי להפעיל שירותים
mediaProcessing
שפועלים בחזית רק כתוצאה מאינטראקציה ישירה של משתמש. מכיוון שהאפליקציה נמצאת בחזית כשהשירות מופעל, השירות מקבל את שש השעות המלאות אחרי שהאפליקציה עוברת לרקע. - במקום להשתמש בשירות שפועל בחזית
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
אסור להפעיל את
הסוגים הבאים של שירותים שפועלים בחזית:
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)及更高版本为目标平台的应用无法再更改设备上的勿扰 (DND) 功能的全局状态或政策(无论是通过修改用户设置还是关闭勿扰模式)。相反,应用必须提供 AutomaticZenRule
,系统会将其与现有的“最严格的政策优先”方案合并为一个全局政策。对之前会影响全局状态的现有 API 的调用(setInterruptionFilter
、setNotificationPolicy
)会导致创建或更新隐式 AutomaticZenRule
,该 AutomaticZenRule
会根据这些 API 调用的调用周期开启和关闭。
请注意,只有当应用调用 setInterruptionFilter(INTERRUPTION_FILTER_ALL)
并希望该调用停用之前由其所有者激活的 AutomaticZenRule
时,此更改才会影响可观察到的行为。
שינויים ב-OpenJDK API
Android 15 将继续更新 Android 的核心库,以与最新 OpenJDK LTS 版本中的功能保持一致。
以下变更可能会影响以 Android 15(API 级别 35)为目标平台的应用的兼容性:
对字符串格式化 API 进行了更改:现在,使用以下
String.format()
和Formatter.format()
API 时,对实参索引、标志、宽度和精度的验证要求变得更加严格: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
API 时,希伯来语、意第绪语和印度尼西亚语的语言代码不再转换为其过时的形式(希伯来语: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
API 可能会影响您应用的兼容性,具体取决于您是否在应用的 build 配置中更新 compileSdk
以使用 Android 15(API 级别 35):
kotlin-stdlib
中MutableList.removeFirst()
和MutableList.removeLast()
扩展函数的冲突Java 中的
List
类型会映射到 Kotlin 中的MutableList
类型。 由于List.removeFirst()
和List.removeLast()
API 已在 Android 15(API 级别 35)中引入,因此 Kotlin 编译器会将函数调用(例如list.removeFirst()
)静态解析为新的List
API,而不是kotlin-stdlib
中的扩展函数。如果应用重新编译时将
compileSdk
设置为35
,并将minSdk
设置为34
或更低值,然后在 Android 14 及更低版本上运行该应用,则会抛出运行时错误:java.lang.NoSuchMethodError: No virtual method removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;
Android Gradle 插件中现有的
NewApi
lint 选项可以捕获这些新的 API 用法。./gradlew lint
MainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi] list.removeFirst()为了修复运行时异常和 lint 错误,可以在 Kotlin 中将
removeFirst()
和removeLast()
函数调用分别替换为removeAt(0)
和removeAt(list.lastIndex)
。如果您使用的是 Android Studio Ladybug | 2024.1.3 或更高版本,它还会针对这些错误提供快速修复选项。如果已停用 lint 选项,请考虑移除
@SuppressLint("NewApi")
和lintOptions { disable 'NewApi' }
。与 Java 中的其他方法发生冲突
现有类型中添加了新方法,例如
List
和Deque
。这些新方法可能与具有相同名称和实参类型的其他接口和类中的方法不兼容。如果方法签名发生不兼容的冲突,javac
编译器会输出 build 时错误。例如:错误示例 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.
הפעלות מאובטחות של פעילות ברקע
בגרסה 15 של Android נוספו שינויים שמגינים על המשתמשים מפני אפליקציות זדוניות ומעניקים להם יותר שליטה במכשירים. השינויים האלה מונעים מאפליקציות זדוניות שפועלות ברקע להעביר אפליקציות אחרות לחזית, להעלות את ההרשאות שלהן ולנצל לרעה את האינטראקציה של המשתמשים. ההפעלות של פעילות ברקע הוגבלו מאז Android 10 (רמת API 29).
שינויים נוספים
בנוסף להגבלה על ההתאמה של UID, השינויים האלה כלול:
- יש לשנות
PendingIntent
יוצרים כך שלחסום השקות של פעילות ברקע על ידי ברירת מחדל. זה עוזר למנוע מאפליקציות ליצור בטעותPendingIntent
שעלולים להיות מנוצלים לרעה על ידי גורמים זדוניים. - אין להעביר אפליקציה לחזית, אלא אם השולח של
PendingIntent
מאפשרת. מטרת השינוי הזה היא למנוע מאפליקציות זדוניות לנצל לרעה יכולת להתחיל פעילויות ברקע. כברירת מחדל, לאפליקציות אסור להציג את סטאק המשימות בחזית, אלא אם היוצר מאפשר להן הרשאות להפעלת פעילות ברקע או לשולח יש הרשאות להפעלת פעילות ברקע. - אתם שולטים באופן שבו הפעילות הראשית במקבץ המשימות יכולה להשלים את המשימה שלה. אם הפעילות המובילה מסתיימת, ו-Android יחזור לאחת מהמשימות שבוצעו פעילות אחרונה. בנוסף, אם משימה שאינה מובילה מסיימת את המשימה, מערכת Android חזרה למסך הבית. היא לא תחסום את הסיומת פעילות.
- למנוע אפשרות להפעיל פעילויות שרירותיות מאפליקציות אחרות במכשיר שלכם משימה זו. השינוי הזה מונע מאפליקציות זדוניות לבצע פישינג של משתמשים על ידי יצירת פעילויות שנראות כאילו הן מגיעות מאפליקציות אחרות.
- חסימת חלונות שאינם נראים לעין כדי שלא יתייחסו לפעילות ברקע השקות. כך אנחנו יכולים למנוע מאפליקציות זדוניות לנצל לרעה את ההפעלות של פעילויות ברקע כדי להציג למשתמשים תוכן לא רצוי או זדוני.
כוונות רכישה בטוחות יותר
ב-Android 15 נוספו אמצעי אבטחה אופציונליים חדשים כדי לשפר את הבטיחות והעמידות של הכוונות. מטרת השינויים האלה היא למנוע נקודות חולשה פוטנציאליות ושימוש לרעה בכוונות שאפשר לנצל על ידי אפליקציות זדוניות. יש שתי פלטפורמות השיפורים העיקריים באבטחת הכוונות ב-Android 15:
- התאמה למסנני הכוונה של היעד: כוונות שמטרגטות רכיבים ספציפיים חייבות להתאים במדויק למפרטי מסנני הכוונה של היעד. אם שולחים את כוונת המשתמש להפעיל פעילות של אפליקציה אחרת, רכיב היעד של כוונת הרכישה צריך תואמים למסנני Intent שהוצהרו על ידי הפעילות המקבלת.
- לאובייקטים מסוג Intent חייבות להיות פעולות: אובייקטים מסוג Intent ללא פעולה לא יתאימו יותר למסנני Intent. כלומר, כוונות משמשות להתחלת פעילויות או השירותים חייבים לכלול פעולה מוגדרת בבירור.
כדי לבדוק איך האפליקציה מגיבה לשינויים האלה, צריך להשתמש ב-StrictMode
באפליקציה. כדי לראות יומנים מפורטים על הפרות של Intent
, מוסיפים את השיטה הבאה:
Kotlin
fun onCreate() { StrictMode.setVmPolicy(VmPolicy.Builder() .detectUnsafeIntentLaunch() .build() ) }
Java
public void onCreate() { StrictMode.setVmPolicy(new VmPolicy.Builder() .detectUnsafeIntentLaunch() .build()); }
חוויית המשתמש וממשק המשתמש של המערכת
Android 15 כוללת כמה שינויים שנועדו ליצור חוויית משתמש עקבית ואינטואיטיבית יותר.
שינויים בהזחה של חלון
There are two changes related to window insets in Android 15: edge-to-edge is enforced by default, and there are also configuration changes, such as the default configuration of system bars.
אכיפה מקצה לקצה
如果应用以 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
。 - 可能存在流量较低且界面被遮挡的屏幕。验证这些访问频率较低的界面是否没有被遮挡的界面。低流量界面包括:
- 初始配置或登录界面
- “设置”页面
如果您的应用尚未实现全屏显示,需要检查哪些方面
如果您的应用尚未实现全屏显示,则很可能会受到影响。除了已经实现全屏显示的 app 的场景之外,您还应考虑以下事项:
- 如果您的应用在 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
)都会处理边衬区,因此不需要执行额外的操作。不过,如果使用的是AppBarLayout
,则需要添加android:fitsSystemWindows="true"
。 - 对于自定义可组合项,请手动应用边衬区作为内边距。如果您的内容位于
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
(适用于三按钮导航,透明度为 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. Display.getSize(Point)
מושפע באופן עקיף מהשינויים ב-Configuration
. השימוש בשיטה הזו הוצא משימוש החל מרמת API 30.Display.getMetrics()
כבר פועל כך מרמת API 33.
ערך ברירת המחדל של המאפיין elegantTextHeight הוא true
באפליקציות שמטרגטות את Android 15 (רמת API 35), המאפיין TextView
של elegantTextHeight
הופך ל-true
כברירת מחדל, ומחליף את הגופן הקומפקטי שמשמש כברירת מחדל בסקריפטים מסוימים עם מדדים אנכיים גדולים, בגופן שקל יותר לקרוא אותו.
הגופן הקומפקטי הוצג כדי למנוע הפרעה לפריסות. בגרסה Android 13 (רמת API 33) מונעים הרבה מהפרעות כאלה על ידי מתן אפשרות לפריסת הטקסט להתמתח לגובה האנכי באמצעות המאפיין fallbackLineSpacing
.
ב-Android 15, הגופן הקומפקטי עדיין נשאר במערכת, כך שהאפליקציה יכולה להגדיר את elegantTextHeight
ל-false
כדי לקבל את אותה התנהגות כמו קודם, אבל סביר להניח שהוא לא יקבל תמיכה בגרסאות הבאות. לכן, אם האפליקציה תומכת בסקריפטים הבאים: ערבית, לאוס, מיאנמר, טמילית, גוג'ראטית, קנאדה, מליאלאם, אודיה, טלוגו או תאית, צריך לבדוק את האפליקציה על ידי הגדרת elegantTextHeight
לערך true
.

elegantTextHeight
באפליקציות שמיועדות ל-Android 14 (רמת API 34) וגרסאות ישנות יותר.
elegantTextHeight
באפליקציות שמטרגטות את Android 15.שינויים ברוחב של TextView עבור צורות מורכבות של אותיות
בגרסאות קודמות של Android, חלק מגופנים או שפות עם כתב מחובר עם עיצוב מורכב עשויים לצייר את האותיות באזור של התו הקודם או הבא.
במקרים מסוימים, אותיות כאלה נחתכו בנקודת ההתחלה או הסיום.
החל מ-Android 15, TextView
מקצה רוחב לציור מספיק מקום לאותיות כאלה ומאפשר לאפליקציות לבקש תוספת רווח שמימין כדי למנוע חיתוך.
מכיוון שהשינוי הזה משפיע על האופן שבו TextView
מחליט על הרוחב, TextView
מקצה יותר רוחב כברירת מחדל אם האפליקציה מטרגטת ל-Android 15 (רמת API 35) ואילך. אפשר להפעיל או להשבית את ההתנהגות הזו על ידי שליחת קריאה ל-API setUseBoundsForWidth
ב-TextView
.
הוספת רווח פנימי בצד ימין עלולה לגרום לחוסר התאמה של פריסות קיימות, ולכן הוא לא מתווסף כברירת מחדל גם לאפליקציות שמטרגטות את Android מגרסה 15 ואילך.
עם זאת, אפשר להוסיף עוד ריפוד כדי למנוע חיתוך על ידי קריאה ל-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 בהתאם ללוקאל
בגרסאות קודמות של Android, פריסת הטקסט הגדילה את גובה הטקסט כדי להתאים לגובה השורה של הגופן שתואם לאזור הנוכחי. לדוגמה, אם התוכן היה ביפנית, הגובה של הטקסט השתנה מעט כי גובה השורה של הגופן היפני גדול מעט מזה של גופן לטינית. עם זאת, למרות ההבדלים האלה בגובה השורות, הגודל של הרכיב EditText
היה אחיד, ללא קשר לאזור הזמן שבו נעשה שימוש, כפי שמוצג בתמונה הבאה:

EditText
שיכולים להכיל טקסט באנגלית (en), ביפנית (ja) ובבורמזית (my). הגובה של EditText
זהה, למרות שלשפות האלה יש גובה שורות שונה זו מזו.באפליקציות שמטרגטות את Android 15 (רמת API 35), גובה שורה מינימלי מוקצה עכשיו ל-EditText
כדי להתאים לגופן העזר של האזור הגיאוגרפי שצוין, כפי שמוצג בתמונה הבאה:

EditText
שיכולים להכיל טקסט באנגלית (en), ביפנית (ja) ובבורמזית (my). הגובה של EditText
כולל עכשיו מקום שמתאים לגובה השורה שמוגדר כברירת מחדל לגופנים של השפות האלה.אם צריך, אפשר לשחזר את ההתנהגות הקודמת של האפליקציה על ידי ציון הערך false
למאפיין useLocalePreferredLineHeightForMinimum
. אפשר גם להגדיר באפליקציה מדדים מינימליים מותאמים אישית של מודעות רגילות באמצעות ממשק ה-API setMinimumFontMetrics
ב-Kotlin וב-Java.
מצלמה ומדיה
ב-Android 15 בוצעו השינויים הבאים בהתנהגות של מצלמה ומדיה באפליקציות שמטרגטות את Android 15 ואילך.
הגבלות על בקשת מיקוד אודיו
以 Android 15(API 级别 35)为目标平台的应用必须是顶部应用或正在运行前台服务,才能请求音频焦点。如果应用在未满足上述任一要求的情况下尝试请求焦点,调用将返回 AUDIOFOCUS_REQUEST_FAILED
。
如需详细了解音频焦点,请参阅管理音频焦点。
הגבלות מעודכנות שאינן ב-SDK
Android 15 כולל רשימות מעודכנות של ממשקי non-SDK מוגבלים, שמבוססות על שיתוף פעולה עם מפתחי Android ועל הבדיקות הפנימיות האחרונות. כשאפשר, אנחנו מוודאים שיש חלופות ציבוריות לפני שאנחנו מגבילים ממשקים שאינם ב-SDK.
אם האפליקציה שלכם לא מטרגטת ל-Android 15, יכול להיות שחלק מהשינויים האלה לא ישפיעו עליכם באופן מיידי. עם זאת, יכול להיות שהאפליקציה שלך תוכל לגשת לחלק מהממשקים שאינם SDK בהתאם לרמת ה-API לטירגוט של האפליקציה, אבל שימוש בשיטה או בשדה שאינם SDK תמיד כרוך בסיכון גבוה להפסקת פעולת האפליקציה.
אם אתם לא בטוחים אם האפליקציה שלכם משתמשת בממשקים שאינם SDK, אתם יכולים לבצע בדיקה לאפליקציה כדי לגלות זאת. אם האפליקציה שלכם מסתמכת על ממשקים שאינם SDK, כדאי להתחיל לתכנן מעבר לחלופות SDK. עם זאת, אנחנו מבינים שיש אפליקציות שבהן יש תרחישי שימוש לגיטימיים בממשקים שאינם SDK. אם אין לך אפשרות להשתמש בממשק שאינו SDK עבור תכונה באפליקציה, עליך לשלוח בקשה ליצירת API ציבורי חדש.
מידע נוסף על השינויים בגרסה הזו של Android זמין במאמר עדכונים לגבי הגבלות על ממשקים שאינם SDK ב-Android 15. מידע נוסף על ממשקים שאינם ב-SDK זמין במאמר הגבלות על ממשקים שאינם ב-SDK.