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

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

以 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():

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

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

对于以 Android 15 为目标平台的应用，elegantTextHeight TextView 属性默认变为 true，将默认使用的紧凑字体替换为一些具有较大垂直指标的脚本，并且这种字体更易于阅读。紧凑字体的引入是为了防止破坏布局；Android 13（API 级别 33）允许文本布局利用 fallbackLineSpacing 属性拉伸垂直高度，以防止许多此类破坏。

在 Android 15 中，紧凑字体仍保留在系统中，因此您的应用可以将 elegantTextHeight 设置为 false，以获得与之前相同的行为，但即将在未来版本中提供支持。因此，如果您的应用支持以下文字：阿拉伯语、老挝语、缅甸、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语，请将 elegantTextHeight 设置为 true，以测试应用。

以 Android 14（API 级别 34）及更低版本为目标平台的应用的 elegantTextHeight 行为。
以 Android 15 为目标平台的应用的 elegantTextHeight 行为。

שינויי רוחב של TextView לצורות מורכבות של אותיות

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

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

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

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

פריסה רגילה לטקסט באנגלית בגופן חזרתי. חלק מ שהאותיות נחתכו. זהו קוד ה-XML התואם:

<TextView
    android:fontFamily="cursive"
    android:text="java" />
פריסה לאותו טקסט באנגלית עם רוחב נוסף ו מרווח פנימי. זהו קוד ה-XML התואם:

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />
פריסה רגילה לטקסט תאילנדי. חלק מהאותיות נחתכו. זהו קוד ה-XML התואם:

<TextView
    android:text="คอมพิวเตอร์" />
פריסה לאותו טקסט בתאילנדית עם רוחב נוסף ו מרווח פנימי. זהו קוד ה-XML התואם:

<TextView
    android:text="คอมพิวเตอร์"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

גובה שורה המוגדר כברירת מחדל ב-EditText עם מודעות ללוקאל

在以前的 Android 版本中，文本布局拉伸了文本的高度，使其适应与当前语言区域匹配的字体的行高。例如，如果内容是日语，由于日语字体的行高比拉丁字体的行高略大，因此文本的高度就略大了。不过，尽管行高存在这些差异，但无论使用何种语言区域，EditText 元素的大小都是一致的，如下图所示：

三个表示 EditText 元素的框，这些框可以包含英语 (en)、日语 (ja) 和缅甸语 (my) 的文本。EditText 的高度相同，即使这两种语言的行高不同。

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

三个表示 EditText 元素的框，这些框可以包含英语 (en)、日语 (ja) 和缅甸语 (my) 的文本。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 接口的限制。