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

פלטפורמת 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

קובצי עזר

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

אבטחה

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

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

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

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

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

ביטול ההסכמה לטיפול בהפניה ל-Intent

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

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

אפשר להשתמש ישירות ב-method‏ 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) או לגרסאות קודמות

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