שינויים בהתנהגות: כל האפליקציות

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

חשוב גם לעיין ברשימת השינויים בהתנהגות שמשפיעים רק על אפליקציות שמטרגטות ל-Android 16.

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

‫Android 16 (‏API ברמה 36) כוללת את השינויים הבאים, שמשנים או מרחיבים יכולות ליבה שונות של מערכת Android.

אופטימיזציה של מכסת JobScheduler

החל מ-Android 16, אנחנו משנים את מכסת זמן הריצה של ביצוע משימות רגילות ומזורזות על סמך הגורמים הבאים:

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

השינוי הזה משפיע על משימות שמתוזמנות באמצעות WorkManager,‏ JobScheduler ו-DownloadManager. כדי לנפות באגים ולגלות למה משימה הופסקה, מומלץ לתעד את הסיבה להפסקת המשימה באמצעות קריאה ל-WorkInfo.getStopReason() (למשימות JobScheduler, צריך לקרוא ל-JobParameters.getStopReason()).

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

מומלץ גם להשתמש ב-API החדש JobScheduler#getPendingJobReasonsHistory שהושק ב-Android 16 כדי להבין למה משימה לא בוצעה.

בדיקה

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

כדי להשבית את האכיפה של ההגדרה 'המצב העליון יפעל בהתאם למכסת זמן הריצה של העבודה', מריצים את הפקודה adb הבאה:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

כדי להשבית את האכיפה של 'משימות שמופעלות במקביל לשירות חזיתי יפעלו בהתאם למכסת זמן הריצה של המשימה', מריצים את הפקודה הבאה של adb:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

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

adb shell am set-standby-bucket APP_PACKAGE_NAME active|working_set|frequent|rare|restricted

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

adb shell am get-standby-bucket APP_PACKAGE_NAME

הסיבה להפסקת עבודות ריקות שננטשו

משימה נטושה מתרחשת כשאובייקט JobParameters המשויך למשימה נאסף על ידי מנהל האשפה, אבל לא בוצע קריאה ל-JobService#jobFinished(JobParameters, boolean) כדי לסמן את סיום המשימה. המשמעות היא שהמשימה עשויה לפעול ולהיבחר מחדש ללא ידיעת האפליקציה.

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

אם יהיו מקרים תדירים של הסיבה החדשה להפסקה, המערכת תבצע פעולות כדי לצמצם את תדירות המשימות.

באפליקציות צריך להשתמש בסיבה החדשה להפסקה כדי לזהות משימות שננטשו ולהפחית את מספרן.

אם אתם משתמשים ב-WorkManager, ב-AsyncTask או ב-DownloadManager, השינוי לא ישפיע עליכם כי ממשקי ה-API האלה מנהלים את מחזור החיים של המשימה בשם האפליקציה.

הוצאה מלאה משימוש של JobInfo#setImportantWhileForeground

השיטה JobInfo.Builder#setImportantWhileForeground(boolean) מציינת את מידת החשיבות של משימה בזמן שאפליקציית התזמון נמצאת בחזית או כשהיא פטורה באופן זמני מההגבלות על משימות ברקע.

השיטה הזו הוצאה משימוש בגרסה Android 12 (רמת API ‏31). החל מגרסה Android 16, היא כבר לא פועלת בצורה יעילה והקריאה לשיטה הזו תתעלם.

הסרת הפונקציונליות הזו חלה גם על JobInfo#isImportantWhileForeground(). החל מגרסה Android 16, אם השיטה נקראת, היא מחזירה את הערך false.

ההיקף של סדר העדיפויות של שידורים כבר לא גלובלי

Android apps are allowed to define priorities on broadcast receivers to control the order in which the receivers receive and process the broadcast. For manifest-declared receivers, apps can use the android:priority attribute to define the priority and for context-registered receivers, apps can use the IntentFilter#setPriority() API to define the priority. When a broadcast is sent, the system delivers it to receivers in order of their priority, from highest to lowest.

In Android 16, broadcast delivery order using the android:priority attribute or IntentFilter#setPriority() across different processes will not be guaranteed. Broadcast priorities will only be respected within the same application process rather than across all processes.

Also, broadcast priorities will be automatically confined to the range (SYSTEM_LOW_PRIORITY + 1, SYSTEM_HIGH_PRIORITY - 1). Only system components will be allowed to set SYSTEM_LOW_PRIORITY, SYSTEM_HIGH_PRIORITY as broadcast priority.

Your app might be impacted if it does either of the following:

  1. Your application has declared multiple processes with the same broadcast intent, and has expectations around receiving those intents in a certain order based on the priority.
  2. Your application process interacts with other processes and has expectations around receiving a broadcast intent in a certain order.

If the processes need to coordinate with each other, they should communicate using other coordination channels.

שינויים פנימיים ב-ART

Android 16 includes the latest updates to the Android Runtime (ART) that improve the Android Runtime's (ART's) performance and provide support for additional Java features. Through Google Play System updates, these improvements are also available to over a billion devices running Android 12 (API level 31) and higher.

As these changes are released, libraries and app code that rely on internal structures of ART might not work correctly on devices running Android 16, along with earlier Android versions that update the ART module through Google Play system updates.

Relying on internal structures (such as non-SDK interfaces) can always lead to compatibility problems, but it's particularly important to avoid relying on code (or libraries containing code) that leverages internal ART structures, since ART changes aren't tied to the platform version the device is running on and they go out to over a billion devices through Google Play system updates.

All developers should check whether their app is impacted by testing their apps thoroughly on Android 16. In addition, check the known issues to see if your app depends on any libraries that we've identified that rely on internal ART structures. If you do have app code or library dependencies that are affected, seek public API alternatives whenever possible and request public APIs for new use cases by creating a feature request in our issue tracker.

מצב תאימות לגודל דף של 16KB

Android 15 introduced support for 16 KB memory pages to optimize performance of the platform. Android 16 adds a compatibility mode, allowing some apps built for 4 KB memory pages to run on a device configured for 16 KB memory pages.

When your app is running on a device with Android 16 or higher, if Android detects that your app has 4 KB aligned memory pages, it automatically uses compatibility mode and display a notification dialog to the user. Setting the android:pageSizeCompat property in the AndroidManifest.xml to enable the backwards compatibility mode will prevent the display of the dialog when your app launches. To use the android:pageSizeCompat property, compile your app using the Android 16 SDK.

For best performance, reliability, and stability, your app should still be 16 KB aligned. Check out our recent blog post on updating your apps to support 16 KB memory pages for more details.

The compatibility mode dialog that displays when the system detects that a 4 KB-aligned app could run more optimally if 16 KB aligned.

חוויית המשתמש וממשק המשתמש של המערכת

‫Android 16 (‏API ברמה 36) כוללת את השינויים הבאים, שנועדו ליצור חוויית משתמש עקבית ואינטואיטיבית יותר.

הוצאה משימוש של הודעות נגישות מפריעות

Android 16 deprecates accessibility announcements, characterized by the use of announceForAccessibility or the dispatch of TYPE_ANNOUNCEMENT accessibility events. These can create inconsistent user experiences for users of TalkBack and Android's screen reader, and alternatives better serve a broader range of user needs across a variety of Android's assistive technologies.

Examples of alternatives:

The reference documentation for the deprecated announceForAccessibility API includes more details about suggested alternatives.

תמיכה בניווט באמצעות 3 לחצנים

ב-Android 16 יש תמיכה בתכונה 'חזרה חזותית' בניווט ב-3 לחצנים באפליקציות שהועברו כראוי ל'חזרה חזותית'. לחיצה ארוכה על לחצן החזרה מפעילה אנימציה חזותית של תנועת החזרה, שמאפשרת לכם לראות תצוגה מקדימה של המקום שאליו תגיעו אם תמשיכו להחליק לאחור.

ההתנהגות הזו חלה על כל האזורים במערכת שתומכים באנימציות חיזוי של תנועת החזרה, כולל אנימציות המערכת (חזרה למסך הבית, בין משימות ובין פעילויות).

האנימציות החיזוניות של תנועת החזרה במצב ניווט ב-3 לחצנים.

סמלי אפליקציות מעוצבים באופן אוטומטי

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

גורמי צורה של מכשירים

‫Android 16 (‏API ברמה 36) כוללת את השינויים הבאים באפליקציות כשהן מוצגות במסכים על ידי בעלי מכשירים וירטואליים.

ביטול הגדרות של בעלי מכשיר וירטואלי

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

הבעלים של המכשיר הווירטואלי בטלפון יוצר מכשיר וירטואלי שמקרין את האפליקציה לתצוגה מרוחקת.

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

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

שינויי תוכנה נפוצים שעלולים לגרום לכשלים

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

קובצי עזר

סטרימינג באפליקציה נלווית

אבטחה

‫Android 16 (‏API ברמה 36) כוללת שינויים שמקדמים את אבטחת המערכת כדי לעזור להגן על אפליקציות ומשתמשים מפני אפליקציות זדוניות.

אבטחה משופרת להגנה מפני התקפות של הפניית כוונות

‫Android 16 מספק אבטחה כברירת מחדל מפני Intentהתקפות כלליות של הפניה אוטומטית, עם דרישות מינימליות של תאימות ושינויים למפתחים.

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

הפניה אוטומטית של Intent ב-Android מתרחשת כשהאקר יכול לשלוט באופן חלקי או מלא בתוכן של Intent שמשמש להפעלת רכיב חדש בהקשר של אפליקציה פגיעה, בזמן שאפליקציית הקורבן מפעילה Intent לא מהימן ברמת משנה בשדה תוספות של Intent ("ברמה העליונה"). הדבר עלול להוביל להפעלת רכיבים פרטיים בהקשר של אפליקציית הקורבן על ידי אפליקציית התוקף, להפעלת פעולות עם הרשאות מיוחדות או לקבלת גישת URI לנתונים רגישים, ועלול להוביל לגניבת נתונים ולהרצת קוד שרירותי.

ביטול ההסכמה לטיפול בהפניה אוטומטית של Intent

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

לאפליקציות שעוברות הידור (compilation) עם SDK של Android 16 (רמת API 36) ומעלה

אפשר להשתמש ישירות בשיטה removeLaunchSecurityProtection() באובייקט Intent.

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }
לאפליקציות שמתבצעת בהן קומפילציה מול Android 15 (רמת API‏ 35) ומטה

אפשר להשתמש ברפלקציה כדי לגשת לשיטה removeLaunchSecurityProtection(), אבל לא מומלץ לעשות את זה.

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent", Intent::class.java)
try {
    val removeLaunchSecurityProtection = Intent::class.java.getDeclaredMethod("removeLaunchSecurityProtection")
    removeLaunchSecurityProtection.invoke(iSublevel)
} catch (e: Exception) {
    // Handle the exception, e.g., log it
} // Opt-out from the security hardening using reflection
iSublevel?.let { startActivity(it) }

אפליקציות נלוות לא מקבלות יותר הודעות על פסק זמן של גילוי

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

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

קישוריות

‫Android 16 (‏API ברמה 36) כוללת את השינויים הבאים במערך Bluetooth כדי לשפר את הקישוריות למכשירים היקפיים.

טיפול משופר באובדן של אג'ח

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

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