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

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

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

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

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

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

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

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

ב-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]"

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

  1. עליך להטמיע בשירות שלך את השיטה החדשה של Service.onTimeout(int, int). כשהאפליקציה מקבלת את הקריאה החוזרת, צריך להקפיד להתקשר אל stopSelf() תוך כמה שניות. (אם לא עוצרים את האפליקציה מיד, המערכת יוצרת כשל).
  2. צריך לוודא ששירותי dataSync באפליקציה לא פועלים במשך יותר ממספר כולל 6 שעות בכל פרק זמן של 24 שעות (אלא אם המשתמש מקיים אינטראקציה עם האפליקציה, איפוס הטיימר).
  3. הפעלת dataSync שירותים שפועלים בחזית בלבד כתוצאה ממשתמש ישיר אינטראקציה; מכיוון שהאפליקציה פועלת בחזית כשהשירות מתחיל, השירות פועל תוך 6 שעות מהרגע שבו האפליקציה עוברת לרקע.
  4. במקום להשתמש בשירות שפועל בחזית 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]"

כדי למנוע את החריגה, אפשר לבצע אחת מהפעולות הבאות:

  1. עליך להטמיע בשירות שלך את השיטה החדשה של Service.onTimeout(int, int). כשהאפליקציה מקבלת את הקריאה החוזרת, צריך להקפיד להתקשר אל stopSelf() תוך כמה שניות. (אם לא עוצרים את האפליקציה מיד, המערכת יוצרת כשל).
  2. צריך לוודא ששירותי mediaProcessing של האפליקציה לא פועלים במשך יותר מ- סה"כ 6 שעות בכל פרק זמן של 24 שעות (אלא אם המשתמש מקיים אינטראקציה עם האפליקציה, איפוס הטיימר).
  3. הפעלת mediaProcessing שירותים שפועלים בחזית בלבד כתוצאה ממשתמש ישיר אינטראקציה; מכיוון שהאפליקציה פועלת בחזית כשהשירות מתחיל, השירות פועל תוך 6 שעות מהרגע שבו האפליקציה עוברת לרקע.
  4. במקום להשתמש בשירות שפועל בחזית 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 אסור להפעיל את הסוגים הבאים של שירותים שפועלים בחזית:

אם מקלט 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

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

Apps that target Android 15 (API level 35) and higher can no longer change the global state or policy of Do Not Disturb (DND) on a device (either by modifying user settings, or turning off DND mode). Instead, apps must contribute an AutomaticZenRule, which the system combines into a global policy with the existing most-restrictive-policy-wins scheme. Calls to existing APIs that previously affected global state (setInterruptionFilter, setNotificationPolicy) result in the creation or update of an implicit AutomaticZenRule, which is toggled on and off depending on the call-cycle of those API calls.

Note that this change only affects observable behavior if the app is calling setInterruptionFilter(INTERRUPTION_FILTER_ALL) and expects that call to deactivate an AutomaticZenRule that was previously activated by their owners.

שינויים ב-OpenJDK API

מערכת Android 15 ממשיכה ברענון ספריות הליבה של Android כדי ליישר קו עם התכונות בגרסאות האחרונות של OpenJDK LTS.

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

  • שינויים בממשקי ה-API בפורמט מחרוזות: אימות אינדקס ארגומנטים, דגלים, הרוחב והדיוק מחמירים יותר עכשיו כשמשתמשים ממשקי API של String.format() ו-Formatter.format():

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

שינויים בצד החלון

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, אם מטרגטת ל-Android 15 (רמת API 35).

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


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

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

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

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

הגדרה יציבה

אם האפליקציה מטרגטת את 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

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

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

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

In previous versions of Android, the text layout stretched the height of the text to meet the line height of the font that matched the current locale. For example, if the content was in Japanese, because the line height of the Japanese font is slightly larger than the one of a Latin font, the height of the text became slightly larger. However, despite these differences in line heights, the EditText element was sized uniformly, regardless of the locale being used, as illustrated in the following image:

Three boxes representing EditText elements that can contain text from English (en), Japanese (ja), and Burmese (my). The height of the EditText is the same, even though these languages have different line heights from each other.

For apps targeting Android 15 (API level 35), a minimum line height is now reserved for EditText to match the reference font for the specified Locale, as shown in the following image:

Three boxes representing EditText elements that can contain text from English (en), Japanese (ja), and Burmese (my). The height of the EditText now includes space to accommodate the default line height for these languages' fonts.

If needed, your app can restore the previous behavior by specifying the useLocalePreferredLineHeightForMinimum attribute to false, and your app can set custom minimum vertical metrics using the setMinimumFontMetrics API in Kotlin and Java.

מצלמה ומדיה

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

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

Apps that target Android 15 (API level 35) must be the top app or running a foreground service in order to request audio focus. If an app attempts to request focus when it does not meet one of these requirements, the call returns AUDIOFOCUS_REQUEST_FAILED.

You can learn more about audio focus at Manage audio focus.

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

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

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

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

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 15. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.