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

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

כשהאפליקציה פועלת במכשיר עם Android מגרסה 16 ואילך, אם מערכת Android מזהה שהאפליקציה כוללת דפי זיכרון בגודל 4KB, היא משתמשת באופן אוטומטי במצב תאימות ומציגה למשתמש תיבת דו-שיח עם התראה. הגדרת המאפיין android:pageSizeCompat בקובץ AndroidManifest.xml כדי להפעיל את מצב התאימות לאחור תמנע את הצגת תיבת הדו-שיח כשהאפליקציה מופעלת. כדי להשתמש בנכס android:pageSizeCompat, צריך לקמפל את האפליקציה באמצעות Android 16 SDK.

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

תיבת הדו-שיח של מצב התאימות שמופיעה כשהמערכת מזהה שאפליקציה שמותאמת ל-4KB עשויה לפעול בצורה אופטימלית יותר אם היא מותאמת ל-16KB.

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

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

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

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

דוגמאות לחלופות:

• לשינויים משמעותיים בממשק המשתמש, כמו שינויים בחלונות, צריך להשתמש ב-Activity.setTitle(CharSequence) וב-setAccessibilityPaneTitle(java.lang.CharSequence). ב-Compose, משתמשים ב-Modifier.semantics { paneTitle = "paneTitle" }
• כדי להודיע למשתמש על שינויים בממשק המשתמש הקריטי, משתמשים ב-setAccessibilityLiveRegion(int). בחלונית הכתיבה, משתמשים ב-Modifier.semantics { liveRegion = LiveRegionMode.[Polite|Assertive]} . מומלץ להשתמש בהם במשורה, כי הם עלולים ליצור הודעות בכל פעם שנתונים מתעדכנים בתצוגה.
• כדי להודיע למשתמשים על שגיאות, שולחים AccessibilityEvent מסוג AccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR ומגדירים את AccessibilityNodeInfo#setError(CharSequence), או משתמשים ב-TextView#setError(CharSequence).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קובצי עזר

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

אבטחה

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

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

Android 16 provides default security against general Intent redirection attacks, with minimum compatibility and developer changes required.

We are introducing by-default security hardening solutions to Intent redirection exploits. In most cases, apps that use intents normally won't experience any compatibility issues; we've gathered metrics throughout our development process to monitor which apps might experience breakages.

Intent redirection in Android occurs when an attacker can partly or fully control the contents of an intent used to launch a new component in the context of a vulnerable app, while the victim app launches an untrusted sub-level intent in an extras field of an ("top-level") Intent. This can lead to the attacker app launching private components in the context of the victim app, triggering privileged actions, or gaining URI access to sensitive data, potentially leading to data theft and arbitrary code execution.

Opt out of Intent redirection handling

Android 16 introduces a new API that allows apps to opt out of launch security protections. This might be necessary in specific cases where the default security behavior interferes with legitimate app use cases.

Important: Opting out of security protections should be done with caution and only when absolutely necessary, as it can increase the risk of security vulnerabilities. Carefully assess the potential impact on your app's security before using this API.

For applications compiling against Android 16 (API level 36) SDK or higher

You can directly use the removeLaunchSecurityProtection() method on the Intent object.

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }

For applications compiling against Android 15 (API level 35) or lower

While not recommended, you can use reflection to access the removeLaunchSecurityProtection() method.

Caution: Using reflection can make your code more fragile and prone to errors, especially if the underlying API changes in future Android versions. Whenever possible, update your compile SDK to target Android 16 (API level 36) or higher to use the API directly.

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 stack כדי לשפר את הקישוריות עם ציוד היקפי.

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

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

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