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

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

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

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

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

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

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

מידע נוסף זמין במאמרים Updates to non-SDK interface restrictions in Android 10 וRestrictions on non-SDK interfaces.

זיכרון משותף

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

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

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

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

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

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

‫Android runtime מקבל רק קובצי OAT שנוצרו על ידי המערכת

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

אכיפת נכונות של AOT ב-ART

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

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

שינויים בהרשאות להצגת Intent במסך מלא

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

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

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, ויכול להיות שימושי כרמז אם האפליקציה שלכם משתמשת במשאבים בלעדיים או במשאבים מסוג singleton שאולי צריך לשתף עם אפליקציות אחרות.

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

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

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

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