בדומה לגרסאות קודמות, Android 15 כולל שינויים בהתנהגות שעשויים להשפיע על האפליקציה שלכם. השינויים הבאים בהתנהגות חלים רק על אפליקציות שמטרגטות ל-Android 15 ואילך. אם האפליקציה שלכם מטרגטת את Android 15 ואילך, אתם צריכים לשנות את האפליקציה כדי לתמוך בהתנהגויות האלה בצורה נכונה, במקרים הרלוונטיים.
חשוב גם לעיין ברשימת השינויים בהתנהגות שמשפיעים על כל האפליקציות שפועלות ב-Android 15, בלי קשר ל-targetSdkVersion
של האפליקציה.
פונקציונליות עיקרית
ב-Android 15 יש שינויים או הרחבות של יכולות ליבה שונות במערכת Android.
שינויים בשירותים שפועלים בחזית
אנחנו מבצעים את השינויים הבאים בשירותים שפועלים בחזית ב-Android 15.
- התנהגות של זמן קצוב לתפוגה בשירות 'סנכרון נתונים' שפועל בחזית
- סוג חדש של שירות שפועל בחזית לעיבוד מדיה
- הגבלות על מקלטי שידורים מסוג
BOOT_COMPLETED
שמפעילים שירותים שפועלים בחזית - הגבלות על הפעלת שירותים שפועלים בחזית בזמן שאפליקציה מחזיקה בהרשאה
SYSTEM_ALERT_WINDOW
התנהגות זמן קצוב לתפוגה של שירות בחזית לסנכרון נתונים
Android 15 introduces a new timeout behavior to dataSync
for apps targeting
Android 15 (API level 35) or higher. This behavior also applies to the new
mediaProcessing
foreground service type.
The system permits an app's dataSync
services to run for a total of 6 hours
in a 24-hour period, after which the system calls the running service's
Service.onTimeout(int, int)
method (introduced in Android
15). At this time, the service has a few seconds to call
Service.stopSelf()
. When Service.onTimeout()
is called, the
service is no longer considered a foreground service. If the service does not
call Service.stopSelf()
, the system throws an internal exception. The
exception is logged in Logcat with the following message:
Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type dataSync did not stop within its timeout: [component name]"
To avoid problems with this behavior change, you can do one or more of the following:
- Have your service implement the new
Service.onTimeout(int, int)
method. When your app receives the callback, make sure to callstopSelf()
within a few seconds. (If you don't stop the app right away, the system generates a failure.) - Make sure your app's
dataSync
services don't run for more than a total of 6 hours in any 24-hour period (unless the user interacts with the app, resetting the timer). - Only start
dataSync
foreground services as a result of direct user interaction; since your app is in the foreground when the service starts, your service has the full six hours after the app goes to the background. - Instead of using a
dataSync
foreground service, use an alternative API.
If your app's dataSync
foreground services have run for 6 hours in the last
24, you cannot start another dataSync
foreground service unless the user
has brought your app to the foreground (which resets the timer). If you try to
start another dataSync
foreground service, the system throws
ForegroundServiceStartNotAllowedException
with an error message like "Time limit already exhausted for foreground service
type dataSync".
Testing
To test your app's behavior, you can enable data sync timeouts even if your app
is not targeting Android 15 (as long as the app is running on an Android 15
device). To enable timeouts, run the following adb
command:
adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name
You can also adjust the timeout period, to make it easier to test how your
app behaves when the limit is reached. To set a new timeout period, run the
following adb
command:
adb shell device_config put activity_manager 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 ואילך) לא יכולות יותר לשנות את המצב או המדיניות הגלובלית של 'נא לא להפריע' במכשיר (על ידי שינוי ההגדרות של המשתמש או השבתת מצב 'נא לא להפריע'). במקום זאת, האפליקציות צריכות לספק 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()
יתאים ל-Random.nextInt()
.
ה-API החדש SequencedCollection
יכול להשפיע על התאימות של האפליקציה אחרי עדכון compileSdk
בהגדרות הבנייה של האפליקציה לשימוש ב-Android 15 (רמת API 35):
התנגשות עם פונקציות של התוספים
MutableList.removeFirst()
ו-MutableList.removeLast()
ב-kotlin-stdlib
הסוג
List
ב-Java ממופה לסוגMutableList
ב-Kotlin. ממשקי ה-APIList.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
נוספו שיטות חדשות לסוגים הקיימים, לדוגמה,
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).
חסימת האפשרות להפעיל פעילויות של אפליקציות שלא תואמות ל-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:
- התאמה למסנני הכוונה של היעד: כוונות שמטרגטות רכיבים ספציפיים חייבות להתאים במדויק למפרטי מסנני הכוונה של היעד. אם שולחים כוונה להפעלת פעילות של אפליקציה אחרת, רכיב הכוונה ליעד צריך להתאים למסנני הכוונה שהוצהרו בפעילות המקבלת.
- ל-Intents חייבות להיות פעולות: Intents ללא פעולה לא יתאימו יותר למסנני 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 כולל כמה שינויים שמטרתם ליצור חוויית משתמש עקבית ואינטואיטיבית יותר.
שינויים בהזחה של חלון
יש שני שינויים שקשורים לחלונות מוטמעים ב-Android 15: תצוגה מקצה לקצה נאכפת כברירת מחדל, ויש גם שינויים בהגדרות, כמו הגדרת ברירת המחדל של שורת הסטטוס.
אכיפה מקצה לקצה
אפליקציות מוצגות מקצה לקצה כברירת מחדל במכשירים שפועלים עם Android 15 אם האפליקציה מטרגטת ל-Android 15 (רמת API 35).

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



מה צריך לבדוק אם האפליקציה כבר מוצגת מקצה לקצה
אם האפליקציה שלכם כבר מכסה את כל המסך ומוגדרים בה שוליים פנימיים, השינוי לא ישפיע עליה ברוב המקרים, למעט בתרחישים הבאים. עם זאת, גם אם אתם חושבים שהאפליקציה שלכם לא מושפעת, מומלץ לבדוק אותה.
- יש לכם חלון לא צף, כמו
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
.
מקורות מידע נוספים על תצוגה מקצה לקצה
במאמרים תצוגות מקצה לקצה ויצירת קומפוזיציה מקצה לקצה מפורטים שיקולים נוספים לגבי החלת שוליים פנימיים.
ממשקי API שהוצאו משימוש
ממשקי ה-API הבאים הוצאו משימוש אבל לא הושבתו:
R.attr#enforceStatusBarContrast
-
R.attr#navigationBarColor
(לניווט ב-3 לחצנים, עם אלפא של 80%) Window#isStatusBarContrastEnforced
-
Window#setNavigationBarColor
(לניווט ב-3 לחצנים, עם שקיפות של 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
For apps targeting Android 15 (API level 35), the
elegantTextHeight
TextView
attribute
becomes true
by default, replacing the compact font used by default with some
scripts that have large vertical metrics with one that is much more readable.
The compact font was introduced to prevent breaking layouts; Android 13 (API
level 33) prevents many of these breakages by allowing the text layout to
stretch the vertical height utilizing the fallbackLineSpacing
attribute.
In Android 15, the compact font still remains in the system, so your app can set
elegantTextHeight
to false
to get the same behavior as before, but it is
unlikely to be supported in upcoming releases. So, if your app supports the
following scripts: Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam,
Odia, Telugu or Thai, test your app by setting elegantTextHeight
to true
.

elegantTextHeight
behavior for apps targeting Android 14 (API level 34) and lower.
elegantTextHeight
behavior for apps targeting Android 15.שינויים ברוחב של TextView עבור צורות מורכבות של אותיות
בגרסאות קודמות של Android, חלק מגופנים או שפות עם כתב מחובר עם עיצוב מורכב עשויים לצייר את האותיות באזור של התו הקודם או הבא.
במקרים מסוימים, אותיות כאלה נחתכו בנקודת ההתחלה או הסיום.
החל מ-Android 15, TextView
מקצה רוחב לציור מספיק מקום לאותיות כאלה ומאפשר לאפליקציות לבקש תוספת רווח שמימין כדי למנוע חיתוך.
מכיוון שהשינוי הזה משפיע על האופן שבו TextView
מחליט על הרוחב, TextView
מקצה יותר רוחב כברירת מחדל אם האפליקציה מטרגטת ל-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 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.
If your app does not target Android 15, some of these changes might not immediately affect you. However, while it's possible for your app to access some non-SDK interfaces depending on your app's target API level, using any non-SDK method or field always carries a high risk of breaking your app.
If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you can't find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.
מידע נוסף על השינויים בגרסה הזו של Android זמין במאמר עדכונים לגבי הגבלות על ממשקים שאינם SDK ב-Android 15. מידע נוסף על ממשקים שאינם ב-SDK זמין במאמר הגבלות על ממשקים שאינם ב-SDK.