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

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

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

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

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

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

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

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

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:

  1. Have your service implement the new Service.onTimeout(int, int) method. When your app receives the callback, make sure to call stopSelf() within a few seconds. (If you don't stop the app right away, the system generates a failure.)
  2. 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).
  3. 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.
  4. 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]"

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

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

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

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

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


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

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

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

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

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

  • יש לכם חלון לא צף, כמו 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 הבאים הוצאו משימוש אבל לא הושבתו:

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

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

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