כמו הגרסאות הקודמות, ב-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 שעות, ולאחר מכן המערכת קוראת לשירות הפעיל
השיטה 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
, צריך להשתמש alternative API
אם השירותים בחזית dataSync
של האפליקציה הופעלו ב-6 השעות האחרונות
24, אי אפשר להפעיל שירות נוסף בחזית של dataSync
אלא אם המשתמש
העביר את האפליקציה לחזית המכשיר (פעולה זו מאפסת את הטיימר). אם תנסה
הפעלת שירות חזיתי dataSync
נוסף, המערכת גורמת
ForegroundServiceStartNotAllowedException
עם הודעת שגיאה כמו "מיצית את מגבלת הזמן לשירות שפועל בחזית
typeSync".
בדיקה
כדי לבדוק את התנהגות האפליקציה, אפשר להפעיל זמנים קצובים לתפוגה של סנכרון נתונים גם אם האפליקציה
לא מטרגט את 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
כדי להבטיח שההמרה תמשיך גם בזמן שהאפליקציה נמצאת
רקע.
המערכת מאפשרת להפעיל עד 6 שירותי mediaProcessing
של אפליקציה מסוימת
שעות בפרק זמן של 24 שעות, ולאחר מכן המערכת קוראת לשירות הפעיל
השיטה Service.onTimeout(int, int)
(הושקה ב-Android
15). בשלב הזה, לשירות יש כמה שניות שאפשר להתקשר
Service.stopSelf()
אם השירות לא
קוראים לפונקציה Service.stopSelf()
, המערכת גורמת לחריגה פנימית.
החריגה מתועדת ב-Logcat עם ההודעה הבאה:
Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"
כדי למנוע את החריגה, אפשר לבצע אחת מהפעולות הבאות:
- עליך להטמיע בשירות שלך את השיטה החדשה של
Service.onTimeout(int, int)
. כשהאפליקציה מקבלת את הקריאה החוזרת, צריך להקפיד להתקשר אלstopSelf()
תוך כמה שניות. (אם לא עוצרים את האפליקציה מיד, המערכת יוצרת כשל). - צריך לוודא ששירותי
mediaProcessing
של האפליקציה לא פועלים במשך יותר מ- סה"כ 6 שעות בכל פרק זמן של 24 שעות (אלא אם המשתמש מקיים אינטראקציה עם האפליקציה, איפוס הטיימר). - הפעלת
mediaProcessing
שירותים שפועלים בחזית בלבד כתוצאה ממשתמש ישיר אינטראקציה; מכיוון שהאפליקציה פועלת בחזית כשהשירות מתחיל, השירות פועל תוך 6 שעות מהרגע שבו האפליקציה עוברת לרקע. - במקום להשתמש בשירות שפועל בחזית
mediaProcessing
, אפשר להשתמש בחלופה API, כמו WorkManager.
אם השירותים בחזית mediaProcessing
של האפליקציה פועלים במשך 6 שעות
ב-24 הימים האחרונים, לא ניתן להתחיל שירות נוסף שפועל בחזית 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 为目标平台的应用无法再更改设备上的全局状态或勿扰 (DND) 政策(通过修改用户设置或关闭 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 בפורמט מחרוזות: אימות אינדקס ארגומנטים, דגלים, הרוחב והדיוק מחמירים יותר עכשיו כשמשתמשים ממשקי 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
).שינויים ברצפי int אקראיים: מעקב אחרי השינויים שבוצעו https://bugs.openjdk.org/browse/JDK-8301574, שיטות
Random.ints()
מחזירות עכשיו רצף מספרים שונה מזה השיטותRandom.nextInt()
כן:באופן כללי, השינוי הזה לא אמור להוביל להתנהגות של תקלה באפליקציות. עם זאת, לא אמור להיות צפי לרצף שנוצר מ-
Random.ints()
methods התאמה ל-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), מהדר (compiler) 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
לאיתור שגיאות בקוד בפלאגין של 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()כדי לתקן את החריגה בסביבת זמן הריצה ושגיאות בקוד,
removeFirst()
וגם אפשר להחליף את הקריאות לפונקציות שלremoveLast()
ב-removeAt(0)
וגםremoveAt(list.lastIndex)
בהתאמה ב-Kotlin. אם אתם משתמשים פרת באגים ב-Android Studio | היא גם מספקת תיקון מהיר למצב של השגיאות האלה.אם האפשרות לאיתור שגיאות בקוד הושבתה, כדאי להסיר את
@SuppressLint("NewApi")
ואתlintOptions { disable 'NewApi' }
.התנגשות עם שיטות אחרות ב-Java
נוספו שיטות חדשות לסוגים הקיימים, לדוגמה, הפקודה
List
והפקודהDeque
. יכול להיות שהשיטות החדשות האלה לא תואמות עם אותן methods עם אותו שם וסוגי ארגומנטים בממשקים אחרים. למחלקות השונות. במקרה של התנגשות חתימת שיטה עם חוסר תאימות, פלט המהדר של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.getLast(); }
אבטחה
ב-Android 15 יש שינויים שמקדמים את אבטחת המערכת כדי להגן על אפליקציות ומשתמשים מאפליקציות זדוניות.
השקות של פעילות מאובטחת ברקע
מערכת Android 15 מגינה על המשתמשים מפני אפליקציות זדוניות ומספקת להם יותר שליטה במכשירים שלהם על ידי הוספת שינויים שמונעים מאפליקציות רקע זדוניות הצגת אפליקציות אחרות לחזית, העלאת רמת ההרשאות שלהן וניצול לרעה לאינטראקציה של המשתמשים. ההפעלות של פעילות ברקע הוגבלו מאז Android 10 (רמת API 29).
חסימת האפשרות להפעיל פעילויות של אפליקציות שלא תואמות ל-UID המוביל במקבץ
אפליקציות זדוניות יכולות לבצע פעילות של אפליקציה אחרת במסגרת אותה משימה, ואז
שכבת-על מעל ויוצרת אשליה של להיות האפליקציה. המשימה הזו
פריצה" מתקפה עוקפת את ההגבלות הנוכחיות של הפעלת רקע כי הכול
מתרחשת בתוך אותה משימה גלויה. כדי למזער את הסיכון הזה, Android 15 מוסיפה
דגל שחוסם את ההפעלה של אפליקציות שלא תואמות את ה-UID המוביל בסטאק
פעילויות. כדי להצטרף לכל הפעילויות של האפליקציה, צריך לעדכן את
allowCrossUidActivitySwitchFromBelow
בקובץ AndroidManifest.xml
של האפליקציה:
<application android:allowCrossUidActivitySwitchFromBelow="false" >
אמצעי האבטחה החדשים פעילים אם כל התנאים הבאים יתקיימו:
- האפליקציה שמבצעת את ההשקה מטרגטת את Android 15.
- האפליקציה שנמצאת בראש מקבץ המשימות מטרגטת את Android 15.
- כל הפעילות הגלויה אושרה על ידי המשתמשים במסגרת אמצעי ההגנה החדשים
אם אמצעי האבטחה מופעלים, האפליקציות עשויות לחזור לדף הבית, האפליקציה האחרונה שנראית למשתמש, אם הם משלימים משימה משלהם.
שינויים נוספים
בנוסף להגבלה על ההתאמה של UID, השינויים האלה כלול:
- יש לשנות
PendingIntent
יוצרים כך שלחסום השקות של פעילויות ברקע על ידי ברירת מחדל. זה עוזר למנוע מאפליקציות ליצור בטעותPendingIntent
שעלולים להיות מנוצלים לרעה על ידי גורמים זדוניים. - לא מעבירים אפליקציה לחזית אלא אם השולח של
PendingIntent
מאפשר זאת. השינוי הזה נועד למנוע מאפליקציות זדוניות לנצל לרעה את היכולת להתחיל פעילויות ברקע. כברירת מחדל, מורשים להעביר את מקבץ המשימות לחזית, אלא אם היוצר מאפשר זאת הרשאות השקה של פעילות ברקע או שלשולח יש פעילות ברקע הרשאות השקה. - אתם שולטים באופן שבו הפעילות הראשית במקבץ המשימות יכולה להשלים את המשימה שלה. אם הפעילות המובילה מסתיימת, ו-Android יחזור לאחת מהמשימות שבוצעו פעילות אחרונה. בנוסף, אם משימה שאינה מובילה מסיימת את המשימה, מערכת Android לחזור למסך הבית. היא לא תחסום את הסיומת פעילות.
- למנוע אפשרות להפעיל פעילויות שרירותיות מאפליקציות אחרות במכשיר שלכם משימה זו. השינוי הזה מונע מאפליקציות זדוניות מפני פישינג על ידי יצירת פעילויות שנראות כאילו נשלחו מאפליקציות אחרות.
- חסימת חלונות שאינם נראים לעין כדי שלא יתייחסו לפעילות ברקע השקות. כך ניתן למנוע מאפליקציות זדוניות לנצל לרעה את הרקע מופעלת כדי להציג תוכן לא רצוי או זדוני למשתמשים.
כוונות בטוחות יותר
ב-Android 15 נוספו אמצעי אבטחה חדשים לשיפור הבטיחות של הכוונות חזקים. מטרת השינויים האלה היא למנוע נקודות חולשה פוטנציאליות שימוש לרעה בכוונות שאפשר לנצל על ידי אפליקציות זדוניות. יש שתי שיטות עיקריות: שיפורים באבטחת הכוונות ב-Android 15:
- התאמה למסנני Intent לטירגוט: אובייקטים מסוג Intent שמטורגטים לרכיבים ספציפיים חייבים להתאים בצורה מדויקת למפרט של מסנני Intent היעד. אם שולחים את כוונת המשתמש להפעיל פעילות של אפליקציה אחרת, רכיב היעד של כוונת הרכישה צריך תואמים למסנני Intent שהוצהרו על ידי הפעילות המקבלת.
- אובייקטים מסוג Intent חייבים לכלול פעולות: אובייקטים מסוג Intent ללא פעולה לא יתאימו יותר. כל מסנני Intent. כלומר, כוונות משמשות להתחלת פעילויות, או השירותים חייבים לכלול פעולה מוגדרת בבירור.
- אובייקטים מסוג Intent בהמתנה: היוצר של ה-Intent הממתין הוא יש להתייחס אליו כאל השולח של הכוונה המצורף, ולא כשולח של הבקשה שבהמתנה 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).
זהו שינוי תוכנה שעלול להשפיע לרעה על ממשק המשתמש של האפליקציה שלכם. השינויים משפיעים על התחומים הבאים של ממשק המשתמש:
- סרגל הניווט של הכינוי באמצעות תנועות
- לא סודי כברירת מחדל.
- ההיסט התחתון מושבת, לכן התוכן מוצג מאחורי ניווט המערכת אלא אם מוחלים insets.
setNavigationBarColor
ו-R.attr#navigationBarColor
הם הוצאו משימוש ולא ישפיעו על ניווט באמצעות תנועות.setNavigationBarContrastEnforced
ו-R.attr#navigationBarContrastEnforced
לא משפיעה על ניווט באמצעות תנועות.
- ניווט ב-3 לחצנים
- רמת האטימות מוגדרת ל-80% כברירת מחדל, וייתכן שהצבע תואם לחלון רקע.
- ההיסט התחתון מושבת כך שהתוכן מוצג מאחורי סרגל הניווט של המערכת אלא אם מחילים insets.
setNavigationBarColor
ו-R.attr#navigationBarColor
הם מוגדר כך שיתאים לרקע החלון כברירת מחדל. הרקע של החלון חייב להיות צבע שאפשר לצייר כדי שברירת המחדל הזו תחול. ה-API הזה הוצאה משימוש, אבל תמשיך להשפיע על הניווט ב-3 לחצנים.setNavigationBarContrastEnforced
ו- הפונקציהR.attr#navigationBarContrastEnforced
מוגדרת כברירת מחדל, והיא מוסיפה רקע אטום 80% לניווט ב-3 לחצנים.
- שורת הסטטוס
- לא סודי כברירת מחדל.
- ההיסט העליון מושבת, כך שהתוכן מופיע מאחורי שורת הסטטוס אלא אם מוחלות insets.
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.
מה צריך לבדוק אם האפליקציה כבר מקצה לקצה
אם האפליקציה שלכם כבר מקצה לקצה ומחילה כניסות, כמעט ללא השפעה, מלבד התרחישים הבאים. אבל גם אם אתם חושבים ואין לכך השפעה, מומלץ לבדוק את האפליקציה.
- יש לך חלון לא צף, כמו
Activity
שמשתמשSHORT_EDGES
,NEVER
אוDEFAULT
במקוםLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
אם האפליקציה קורסת בהפעלה, יכול להיות בגלל מסך הפתיחה שלך. ניתן לשדרג את הליבה התלות של מסך הפתיחה ב-1.2.0-alpha01 או מאוחר יותר או להגדירwindow.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always
. - יכול להיות שיש מסכים עם תנועה נמוכה יותר עם ממשק משתמש מוסתר. אימות הפרטים האלה
במסכים שבהם מבקרים פחות מבקרים אין ממשק משתמש מוסתר. מסכים עם פחות תנועה:
- מסכי הצטרפות או כניסה
- דפי הגדרות
מה צריך לבדוק אם האפליקציה עדיין לא מקצה לקצה
אם האפליקציה שלך עדיין לא מקצה לקצה, סביר להניח שתהיה לכך השפעה עליך. לחשבון בנוסף לתרחישים של אפליקציות שכבר מקצה לקצה, צריך כדאי להביא בחשבון את האפשרויות הבאות:
- אם האפליקציה שלך משתמשת ברכיבי Material 3 (
androidx.compose.material3
) בחלונית הכתיבה, למשלTopAppBar
,BottomAppBar
ו-NavigationBar
, סביר להניח שהרכיבים האלה לא מושפעים כי הם מטפלים אוטומטית בהטמעות. - אם האפליקציה שלך משתמשת ברכיבי Material 2 (
androidx.compose.material
) בחלונית 'אימייל חדש', הרכיבים האלה לא מטפלות בערכות inset באופן אוטומטי. אבל אפשר לקבל גישה ל-Insets וליישם אותם באופן ידני. ב-androidx.compose.material 1.6.0 ואחר כך להשתמש בפרמטרwindowInsets
כדי להחיל את הרכיבים הפנימיים באופן ידניBottomAppBar
,TopAppBar
,BottomNavigation
וגםNavigationRail
. באותו אופן, צריך להשתמש בפרמטרcontentWindowInsets
כדיScaffold
. - אם האפליקציה שלך משתמשת בתצוגות מפורטות וברכיבי Material
(
com.google.android.material
), רוב התכנים שמבוססים על צפיות רכיבים כמוBottomNavigationView
,BottomAppBar
NavigationRailView
אוNavigationView
, תומכים בהטמעות ללא צורך עבודה נוספת. עם זאת, עליך להוסיףandroid:fitsSystemWindows="true"
אם משתמשים ב-AppBarLayout
. - בתכנים קומפוזביליים בהתאמה אישית, צריך להחיל את הרכיבים הפנימיים באופן ידני בתור מרווח פנימי. אם
התוכן נמצא בתוך
Scaffold
, אפשר לצרוך כניסות פסקה באמצעותScaffold
ערכי מרווח פנימי. לחלופין, אפשר להחיל מרווח פנימי באמצעות אחדWindowInsets
- אם באפליקציה שלך נעשה שימוש בתצוגות מפורטות וב-
BottomSheet
, ב-SideSheet
או בהתאמה אישית קונטיינרים, החלת מרווח פנימי באמצעותViewCompat.setOnApplyWindowInsetsListener
. עבורRecyclerView
, החלת מרווח פנימי באמצעות ה-listener הזה וגם הוספהclipToPadding="false"
.
מה צריך לבדוק אם האפליקציה חייבת להציע הגנה מותאמת אישית לרקע
אם האפליקציה חייבת להציע הגנה מותאמת אישית ברקע עבור ניווט ב-3 לחצנים, או
משורת הסטטוס, עליך להציב תוכן קומפוזבילי או תצוגה מאחורי סרגל המערכת
באמצעות WindowInsets.Type#tappableElement()
כדי ללחוץ על 3 הלחצנים
הגובה של סרגל הניווט או WindowInsets.Type#statusBars
.
משאבים נוספים מקצה לקצה
אפשר לקרוא מידע נוסף בקטעים Edge to Edge Views וEdge to Edge Compose מדריכים נוספים לשיקולים נוספים בנוגע להחלת insets.
ממשקי API שהוצאו משימוש
ממשקי ה-API הבאים הוצאו משימוש:
R.attr#enforceStatusBarContrast
R.attr#navigationBarColor
R.attr#navigationBarDividerColor
R.attr#statusBarColor
Window#getNavigationBarColor
Window#getNavigationBarDividerColor
Window#getStatusBarColor
Window#isStatusBarContrastEnforced
Window#setDecorFitsSystemWindows
Window#setNavigationBarColor
Window#setNavigationBarDividerColor
Window#setStatusBarColor
Window#setStatusBarContrastEnforced
הגדרה יציבה
אם האפליקציה מטרגטת את 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
, שורת הסטטוס והסרגל העליון לא נכללים יותר. Configuration.smallestScreenWidthDp
מושפע באופן עקיף משינויים ב-screenWidthDp
וב-screenHeightDp
.Configuration.orientation
מושפע באופן עקיף משינויים ב-screenWidthDp
וב-screenHeightDp
במכשירים שצורתם קרובה למרובעת.Display.getSize(Point)
מושפע באופן עקיף מהשינויים ב-Configuration
. האפשרות הזו הוצאה משימוש החל מרמת API 30.Display.getMetrics()
כבר פועל כך החל מרמת API 33.
ערך ברירת המחדל של מאפיין maxTextHeight הוא True
对于以 Android 15 为目标平台的应用,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
הדוגמאות הבאות מראות איך השינויים האלה יכולים לשפר את פריסת הטקסט עבור חלק גופנים ושפות.
גובה שורה המוגדר כברירת מחדל ב-EditText עם מודעות ללוקאל
在以前的 Android 版本中,文本布局拉伸了文本的高度,使其适应与当前语言区域匹配的字体的行高。例如,如果内容是日语,由于日语字体的行高比拉丁字体的行高略大,因此文本的高度就略大了。不过,尽管行高存在这些差异,但无论使用何种语言区域,EditText
元素的大小都是一致的,如下图所示:
对于以 Android 15 为目标平台的应用,系统现在会为 EditText
预留最小行高,以匹配指定语言区域的参考字体,如下图所示:
如果需要,您的应用可以通过将 useLocalePreferredLineHeightForMinimum
属性设置为 false
来恢复之前的行为,并且可以通过 Kotlin 和 Java 中的 setMinimumFontMetrics
API 设置自定义最小行业指标。
מצלמה ומדיה
מערכת Android 15 מבצעת את השינויים הבאים בהתנהגות המצלמה והמדיה באפליקציות שמטרגטות את Android מגרסה 15 ואילך.
הגבלות על בקשה למיקוד אודיו
以 Android 15 为目标平台的应用必须是顶级应用或运行前台服务,才能请求音频焦点。如果应用在不符合其中任何一项要求时尝试请求焦点,该调用将返回 AUDIOFOCUS_REQUEST_FAILED
。
您可以参阅管理音频焦点,详细了解音频焦点。
הגבלות מעודכנות שלא קשורות ל-SDK
מערכת Android 15 כוללת רשימות מעודכנות של רכיבי SDK מוגבלים שאינם SDK שמבוססים על שיתוף פעולה עם מפתחי Android, בדיקה פנימית. כשהדבר אפשרי, אנחנו מוודאים שחלופות ציבוריות לפני שנגביל ממשקים שאינם SDK.
אם האפליקציה שלכם לא מטרגטת ל-Android 15, יכול להיות שחלק מהשינויים האלה לא ישפיעו עליכם באופן מיידי. עם זאת, למרות שהאפליקציה יכולה גישה לממשקים מסוימים שאינם SDK בהתאם לרמת ה-API המטורגטת של האפליקציה, באמצעות כל ערכת SDK שאינה SDK השיטה או השדה תמיד מובילים לסיכון גבוה לגרימת נזק באפליקציה.
אם אתם לא בטוחים אם באפליקציה שלכם נעשה שימוש בממשקים שאינם SDK, תוכלו לבדוק את האפליקציה כדי לברר זאת. אם האפליקציה מסתמכת על מערכות שאינן SDK לכן כדאי להתחיל לתכנן העברה לחלופות SDK. עם זאת, אנחנו מבינים שלחלק מהאפליקציות יש תרחישים תקינים לדוגמה של ולא ממשקי SDK. אם לא מוצאים חלופה לשימוש בגרסה שאינה SDK ממשק של תכונה באפליקציה, לבקש ממשק API ציבורי חדש.
如需详细了解此 Android 版本中的变更,请参阅 Android 15 中有关限制非 SDK 接口的更新。如需全面了解有关非 SDK 接口的详细信息,请参阅对非 SDK 接口的限制。