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

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

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

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

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

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

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

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

זיכרון משותף

הפורמט של מיפוי 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) יכלה לגרום לקריסות בזמן ריצה אם סביבת classpath לא הייתה זהה בזמן הקומפילציה ובזמן הריצה. ב-Android 10 ואילך, הקשרים של הסביבה צריכים להיות זהים תמיד, ולכן יש שינויים בהתנהגות:

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

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

אפליקציות שמטרגטות ל-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 אינץ' לבדיקת הקוד במסכים גדולים יותר.

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