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

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

מומלץ גם לעיין ברשימת השינויים בהתנהגות שמשפיעים על כל האפליקציות שפועלות ב-Android 10.

עדכונים בהגבלות על ממשקים שאינם ב-SDK

כדי לשמור על יציבות ותאימות של האפליקציות, הפלטפורמה התחילה להגביל את הממשקים שאינם SDK שבהם האפליקציה יכולה להשתמש ב-Android 9 (רמת API 28). מערכת Android 10 כוללת רשימות מעודכנות של ממשקים מוגבלים שאינם SDK, על סמך שיתוף פעולה עם מפתחי Android והבדיקה הפנימית האחרונה. המטרה שלנו היא לוודא שיש חלופות ציבוריות זמינות לפני שנצמצם את הגישה לממשקים שאינם SDK.

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

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

מידע נוסף זמין במאמרים עדכונים לגבי הגבלות על ממשקים שאינם ב-SDK ב-Android 10 והגבלות על ממשקים שאינם ב-SDK.

זיכרון משותף

Ashmem שינה את הפורמט של מפות dalvik ב-/proc/<pid>/maps, משפיע על אפליקציות שמנתחות ישירות את קובץ המפות. מפתחי אפליקציות צריכים לבדוק את הפורמט /proc/<pid>/maps במכשירים עם Android מגרסה 10 ואילך ולנתח אותו בהתאם אם האפליקציה תלויה בפורמטים של מפות dalvik.

אפליקציות שמטרגטות את Android 10 לא יכולות להשתמש ישירות ב-ashmem‏ (‎/dev/ashmem), ובמקום זאת הן צריכות לגשת לזיכרון המשותף דרך הקלאס ASharedMemory של NDK. בנוסף, אפליקציות לא יכולות לבצע קריאות IOCTL ישירות למתארי קבצים קיימים של ashmem, ובמקום זאת הן צריכות להשתמש בכיתה ASharedMemory של NDK או ב-API של Java ל-Android כדי ליצור אזורים של זיכרון משותף. השינוי הזה מגביר את האבטחה והעמידות בעבודה עם זיכרון משותף, ומשפר את הביצועים והאבטחה של Android באופן כללי.

הוסרה ההרשאה להפעלה של ספריית הבית של האפליקציה

ביצוע קבצים מספריית הבית של האפליקציה שניתנת לכתיבה הוא הפרת W^X. אפליקציות צריכות לטעון רק את הקוד הבינארי שמוטמע בקובץ ה-APK של האפליקציה.

אפליקציות לא מהימנות שמטרגטות את Android 10 לא יכולות להפעיל את execve() ישירות בקבצים בספריית הבית של האפליקציה.

בנוסף, אפליקציות שמטרגטות את Android 10 לא יכולות לשנות בזיכרון קוד הפעלה מקובצים שנפתחו באמצעות dlopen() ולצפות שהשינויים האלה ייכתבו בדיסק, כי לא ניתן למפות את הספרייה PROT_EXEC באמצעות מתאר קובץ לכתיבה. זה כולל כל קובץ אובייקט משותף (.so) עם העברות טקסט.

סביבת זמן הריצה של Android מקבלת רק קובצי OAT שנוצרו על ידי המערכת

סביבת זמן הריצה של Android‏ (ART) כבר לא מפעילה את dex2oat מתהליך האפליקציה. המשמעות של השינוי הזה היא שמערכת ART תקבל רק קובצי OAT שנוצרו על ידה.

אכיפת תקינות AOT ב-ART

בעבר, הידור מראש (AOT) שבוצעה על ידי Android Runtime‏ (ART) עלול היה לגרום לקריסות בסביבת זמן הריצה אם סביבת classpath לא הייתה זהה בזמן הידור ובזמן ריצה. ב-Android 10 ואילך, ההקשרים של הסביבה האלה תמיד חייבים להיות זהים, וכתוצאה מכך מתרחשים השינויים הבאים בהתנהגות:

• מערכי טעינה מותאמים אישית של כיתות – כלומר, מערכי טעינה של כיתות שנכתבו על ידי אפליקציות, בניגוד למערכי טעינה של כיתות מחבילת dalvik.system – לא עוברים הידור AOT. הסיבה לכך היא ש-ART לא יכול לדעת על הטמעה מותאמת אישית של חיפוש כיתה בזמן ריצה.
• קובצי dex משניים – כלומר קובצי dex שנטענים באופן ידני על ידי אפליקציות שלא נמצאות ב-APK הראשי – עוברים הידור AOT ברקע. הסיבה לכך היא שהדרישה ל-compilation בשימוש הראשון עשויה להיות יקרה מדי, וכתוצאה מכך זמן האחזור לפני הביצוע יהיה ארוך מדי. חשוב לזכור שבאפליקציות מומלץ להשתמש בחלוקות ולהפסיק להשתמש בקובצי dex משניים.
• ספריות משותפות ב-Android (הרשאות <library> ו-<uses-library> במניפסט של Android) מיושמות באמצעות היררכיה שונה של מעמיס הכיתות מזו שבה נעשה שימוש בגרסאות קודמות של הפלטפורמה.

שינויים בהרשאות של מודעות Intent במסך מלא

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

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

Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission

תמיכה במכשירים מתקפלים

ב-Android 10 יש שינויים שתומכים במכשירים מתקפלים ובמכשירים עם מסך גדול.

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

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

ב-Android 10 (API ברמה 29 ואילך), אפשר להירשם להודעת החזרה (callback) onTopResumedActivityChanged() כדי לקבל התראה כשהפעילות מקבלת או מאבדת את המיקום העליון של הפעילות שהמשך שלה הופעל. זהו המקביל למצב 'המשך' לפני Android 10, והוא יכול לשמש כנקודת התייחסות אם האפליקציה שלכם משתמשת במשאבים בלעדיים או ייחודיים שיכול להיות שצריך לשתף עם אפליקציות אחרות.

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

אפליקציות יכולות להשתמש במאפיין android:minAspectRatio, שהוצג ב-Android 10, כדי לציין את יחסי המסך שהאפליקציה תומכת בהם.

החל מגרסה 3.5, כלי האמולטור של Android Studio כולל מכשירי וירטואליים בגודל 7.3" ו-8" לבדיקה של הקוד במסכים גדולים יותר.

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