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

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

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

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

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

שינויים במצב העצירה של החבילה

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

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

אפשר להפעיל את השיטה החדשה ApplicationStartInfo.wasForceStopped() כדי לוודא שהאפליקציה הועברה למצב מושהה.

תמיכה בגודל דף של 16KB

Historically, Android has only supported 4 KB memory page sizes, which has optimized system memory performance for the average amount of total memory that Android devices have typically had. Beginning with Android 15, AOSP supports devices that are configured to use a page size of 16 KB (16 KB devices). If your app uses any NDK libraries, either directly or indirectly through an SDK, then you will need to rebuild your app for it to work on these 16 KB devices.

As device manufacturers continue to build devices with larger amounts of physical memory (RAM), many of these devices will adopt 16 KB (and eventually greater) page sizes to optimize the device's performance. Adding support for 16 KB page size devices enables your app to run on these devices and helps your app benefit from the associated performance improvements. Without recompiling, apps won't work on 16 KB devices in future Android releases.

To help you add support for your app, we've provided guidance on how to check if your app is impacted, how to rebuild your app (if applicable), and how to test your app in a 16 KB environment using emulators (including Android 15 system images for the Android Emulator).

Benefits and performance gains

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

• זמני השקה קצרים יותר של אפליקציות בזמן שהמערכת נמצאת בלחץ על הזיכרון: נמוך ב-3.16% בממוצע, עם שיפורים משמעותיים יותר (עד 30%) בחלק מהאפליקציות שבדקנו
• צריכת חשמל מופחתת במהלך השקת האפליקציה: הפחתה של 4.56% בממוצע
• הפעלה מהירה יותר של המצלמה: הפעלה מתוך הזיכרון (hot start) מהירה יותר ב-4.48% בממוצע, והפעלה מחדש (cold start) מהירה יותר ב-6.60% בממוצע
• זמן הפעלה משופר של המערכת: שיפור של 8% (כ-950 אלפיות השנייה) בממוצע

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

Check if your app is impacted

If your app uses any native code, then you should rebuild your app with support for 16 KB devices. If you are unsure if your app uses native code, you can use the APK Analyzer to identify whether any native code is present and then check the alignment of ELF segments for any shared libraries that you find. Android Studio also provides features that help you to automatically detect alignment issues.

If your app only uses code written in the Java programming language or in Kotlin, including all libraries or SDKs, then your app already supports 16 KB devices. Nevertheless, we recommend that you test your app in a 16 KB environment to verify that there are no unexpected regressions in app behavior.

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

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

כל האפליקציות

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

אפליקציות רפואיות

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

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

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

אפליקציות מרכז האפליקציות

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

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

אפליקציות מרכז האפליקציות שמצהירות על ההרשאה ACCESS_HIDDEN_PROFILES חייבות לטפל בתרחישי השימוש הבאים במרחב הפרטי:

1. לאפליקציה צריך להיות מאגר נפרד במרכז האפליקציות לאפליקציות שמותקנות במרחב הפרטי. משתמשים ב-method‏ getLauncherUserInfo() כדי לקבוע איזה סוג של פרופיל משתמש מנוהל.
2. המשתמש צריך להיות מסוגל להסתיר ולהציג את הקונטיינר של המרחב הפרטי.
3. המשתמש צריך להיות מסוגל לנעול ולפתוח את המרחב הפרטי. משתמשים ב-method‏ requestQuietModeEnabled() כדי לנעול (על ידי העברת true) או לבטל את הנעילה (על ידי העברת false) של המרחב הפרטי.

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

   אפשר גם להשתמש ב-method isQuietModeEnabled() כדי לבדוק אם פרופיל המרחב הפרטי נעול או לא.

אפליקציות מחנות האפליקציות

המרחב הפרטי כולל לחצן 'התקנת אפליקציות' שמפעיל כוונה משתמעת להתקין אפליקציות במרחב הפרטי של המשתמש. כדי שהאפליקציה תקבל את הכוונה המשתמעת הזו, צריך להצהיר על <intent-filter> בקובץ המניפסט של האפליקציה עם <category> של CATEGORY_APP_MARKET.

הוסר גופן אמוג'י מבוסס PNG

קובץ הגופן הקודם של אמוג'י (NotoColorEmojiLegacy.ttf) שמבוסס על קובץ PNG הוסר, ונותר רק הקובץ המבוסס על וקטור. החל מ-Android 13 (רמת API 33), קובץ הגופן של האמוג'י שמשמש את המערכת להצגת אמוג'י השתנה מקובץ מבוסס-PNG לקובץ מבוסס-וקטור. המערכת שמרה את קובץ הגופן הקודם ב-Android 13 וב-Android 14 מסיבות תאימות, כדי שאפליקציות עם מנועי גופן משלהם יוכלו להמשיך להשתמש בקובץ הגופן הקודם עד שהן יוכלו לשדרג.

כדי לבדוק אם האפליקציה שלכם מושפעת, מחפשים בקוד של האפליקציה הפניות לקובץ NotoColorEmojiLegacy.ttf.

יש כמה דרכים להתאים את האפליקציה:

• שימוש ב-API של פלטפורמות לעיבוד טקסט. אפשר להעביר טקסט ל-Canvas שמבוסס על bitmap ולהשתמש בו כדי לקבל תמונה גולמית, אם צריך.
• מוסיפים לאפליקציה תמיכה בגופנים מסוג COLRv1. ספריית FreeType בקוד פתוח תומכת ב-COLRv1 בגרסה 2.13.0 ואילך.
• כחלופה אחרונה, אפשר לצרף את קובץ הגופן הקודם של אמוג'י (NotoColorEmoji.ttf) לקובץ ה-APK, אבל במקרה כזה באפליקציה לא יוצגו עדכוני האמוג'י האחרונים. למידע נוסף, אפשר לעיין בדף הפרויקט של Noto Emoji ב-GitHub.

הגדלנו את גרסת ה-SDK המינימלית לטירגוט מ-23 ל-24

Android 15 builds on the the changes that were made in Android 14 and extends this security further. In Android 15, apps with a targetSdkVersion lower than 24 can't be installed. Requiring apps to meet modern API levels helps to ensure better security and privacy.

Malware often targets lower API levels in order to bypass security and privacy protections that have been introduced in higher Android versions. For example, some malware apps use a targetSdkVersion of 22 to avoid being subjected to the runtime permission model introduced in 2015 by Android 6.0 Marshmallow (API level 23). This Android 15 change makes it harder for malware to avoid security and privacy improvements. Attempting to install an app targeting a lower API level results in an installation failure, with a message like the following one appearing in Logcat:

INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 24, but found 7

On devices upgrading to Android 15, any apps with a targetSdkVersion lower than 24 remain installed.

If you need to test an app targeting an older API level, use the following ADB command:

adb install --bypass-low-target-sdk-block FILENAME.apk

אבטחה ופרטיות

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

כדי לוודא שהאפליקציות שלהם תואמות לשינויים ב-Android 15, המפתחים צריכים לשים לב לנקודות הבאות:

השמטת סיסמה חד-פעמית

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

הגנה על שיתוף המסך

• תוכן ההתראות מוסתר במהלך סשנים של שיתוף מסך כדי לשמור על הפרטיות של המשתמש. אם האפליקציה מטמיעה את setPublicVersion(), מערכת Android מציגה את הגרסה הציבורית של ההתראה, שמשמשת כהתראה חלופית בהקשרים לא מאובטחים. אחרת, תוכן ההתראה יימחק ללא הקשר נוסף.
• תוכן רגיש, כמו הזנת סיסמה, מוסתר מהצופים מרחוק כדי למנוע חשיפת המידע הרגיש של המשתמש.
• פעילויות מאפליקציות ששולחות התראות במהלך שיתוף המסך, שבהן זוהתה OTP, יוסתרו. תוכן האפליקציה מוסתר מהצופה מרחוק כשהיא מופעלת.
• בנוסף לזיהוי האוטומטי של שדות רגישים ב-Android, מפתחים יכולים לסמן באופן ידני חלקים באפליקציה שלהם כתוכן רגיש באמצעות setContentSensitivity. התוכן הזה יהיה מוסתר לצופים מרחוק במהלך שיתוף המסך.
• מפתחים יכולים להחליף את המצב של האפשרות השבתת ההגנות של שיתוף המסך בקטע אפשרויות למפתחים כדי לקבל פטור מההגנות על שיתוף המסך למטרות הדגמה או בדיקה. מכשיר הקלטת המסך שמוגדר כברירת מחדל לא מושפע מהשינויים האלה, כי ההקלטות נשארות במכשיר.

מצלמה ומדיה

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

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

Before Android 15, if an app requested direct or offload audio playback while another app was playing audio and the resource limits were reached, the app would fail to open a new AudioTrack.

Beginning with Android 15, when an app requests direct or offload playback and the resource limits are reached, the system invalidates any currently open AudioTrack objects which prevent fulfilling the new track request.

(Direct and offload audio tracks are typically opened for playback of compressed audio formats. Common use-cases for playing direct audio include streaming encoded audio over HDMI to a TV. Offload tracks are typically used to play compressed audio on a mobile device with hardware DSP acceleration.)

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

‫Android 15 כוללת כמה שינויים שנועדו ליצור חוויית משתמש עקבית ואינטואיטיבית יותר.

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

Beginning in Android 15, the developer option for predictive back animations has been removed. System animations such as back-to-home, cross-task, and cross-activity now appear for apps that have opted in to the predictive back gesture either entirely or at an activity level. If your app is affected, take the following actions:

• Ensure that your app has been properly migrated to use the predictive back gesture.
• Ensure that your fragment transitions work with predictive back navigation.
• Migrate away from animation and framework transitions and use animator and androidx transitions instead.
• Migrate away from back stacks that FragmentManager doesn't know about. Use back stacks managed by FragmentManager or by the Navigation component instead.

הווידג'טים מושבתים כשהמשתמש סוגר אפליקציה בכוח

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

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

מידע נוסף זמין במאמר שינויים במצב 'החבילה הופסקה'.

שבב בשורת הסטטוס של הקרנת מדיה מתריע למשתמשים על שיתוף מסך, הפעלת Cast והקלטה

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

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

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

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

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

הגבלות על גישה לרשת ברקע

In Android 15, apps that start a network request outside of a valid process lifecycle receive an exception. Typically, an UnknownHostException or other socket-related IOException. Network requests that happen outside of a valid lifecycle are usually due to apps unknowingly continuing a network request even after the app is no longer active.

To mitigate this exception, ensure your network requests are lifecycle aware and cancelled upon leaving a valid process lifecycle by using lifecycle aware components. If it is important that the network request should happen even when the user leaves the application, consider scheduling the network request using WorkManager or continue a user visible task using Foreground Service.

הוצאה משימוש

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

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