ב-Android 10 יש שינויים מעודכנים בהתנהגות המערכת שעשויים להשפיע על האפליקציה שלכם. השינויים שמפורטים בדף הזה רלוונטיים רק לאפליקציות שמטרגטות את API 29 ואילך. אם האפליקציה שלכם מגדירה את targetSdkVersion ל-"29" או יותר, אתם צריכים לשנות את האפליקציה כדי שהיא תתמוך בהתנהגויות האלה כמו שצריך, במקרים הרלוונטיים.
חשוב גם לבדוק את רשימת השינויים בהתנהגות שמשפיעים על כל האפליקציות שפועלות ב-Android 10.
הערה: בנוסף לשינויים שמפורטים בדף הזה, ב-Android 10 יש הרבה שינויים והגבלות שקשורים לפרטיות, כולל:
- נפח אחסון ייעודי לאפליקציות
- גישה למספר הסידורי של התקן ה-USB
- אפשרות להפעיל, להשבית ולהגדיר Wi-Fi
- הרשאות מיקום לממשקי API של קישוריות
השינויים האלה, שמשפיעים על אפליקציות שמטרגטות לרמת ה-API המיועדת 29 ומעלה, משפרים את פרטיות המשתמשים. בדף שינויים בפרטיות מוסבר איך לתמוך בשינויים האלה.
עדכונים לגבי הגבלות על ממשקים שאינם SDK
כדי להבטיח את היציבות והתאימות של האפליקציה, הפלטפורמה התחילה להגביל את ממשקי ה-API שאינם 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 של Android Java כדי ליצור אזורי זיכרון משותפים. השינוי הזה משפר את האבטחה והיציבות כשעובדים עם זיכרון משותף, ומשפר את הביצועים והאבטחה של Android באופן כללי.
הוסרה הרשאת ההפעלה של ספריית הבית של האפליקציה
הפעלה של קבצים מספריית הבית של האפליקציה שניתן לכתוב בה היא הפרה של W^X. אפליקציות צריכות לטעון רק את הקוד הבינארי שמוטמע בקובץ ה-APK של האפליקציה.
אפליקציות לא מהימנות שמטרגטות את Android 10 לא יכולות להפעיל את execve()
ישירות על קבצים בספריית הבית של האפליקציה.
בנוסף, אפליקציות שמטרגטות את Android 10 לא יכולות לשנות בזיכרון קוד הפעלה מקבצים שנפתחו באמצעות dlopen() ולצפות שהשינויים האלה ייכתבו בדיסק, כי לא ניתן למפות את הספרייה PROT_EXEC באמצעות תיאור קובץ שניתן לכתיבה. זה כולל קובצי אובייקטים משותפים (.so) עם העברות טקסט.
סביבת זמן הריצה ל-Android (ART) מקבלת רק קובצי OAT שנוצרו על ידי המערכת
סביבת זמן הריצה ל-Android (ART) לא מפעילה יותר את dex2oat מתהליך האפליקציה. המשמעות של השינוי הזה היא ש-ART יקבל רק קובצי OAT שהמערכת יצרה.
אכיפת התקינות של AOT ב-ART
בעבר, הקימפול לפני הזמן (AOT) שבוצע על ידי סביבת זמן הריצה ל-Android (ART) היה עלול לגרום לקריסות בזמן הריצה אם סביבת ה-classpath לא הייתה זהה בזמן הקימפול ובזמן הריצה. ב-Android מגרסה 10 ואילך, ההקשרים של הסביבות האלה תמיד צריכים להיות זהים, וכתוצאה מכך חלים השינויים הבאים בהתנהגות:
- טועני מחלקות בהתאמה אישית – כלומר, טועני מחלקות שנכתבו על ידי אפליקציות, בניגוד לטועני מחלקות מהחבילה
dalvik.system– לא עוברים הידור AOT. הסיבה לכך היא ש-ART לא יכול לדעת על הטמעה של חיפוש מחלקות בהתאמה אישית בזמן הריצה. - קובצי dex משניים – כלומר, קובצי dex שנטענים באופן ידני על ידי אפליקציות שלא נמצאות ב-APK הראשי – עוברים הידור AOT ברקע. הסיבה לכך היא שהידור בשימוש הראשון עלול להיות יקר מדי, מה שיוביל לזמן אחזור לא רצוי לפני ההפעלה. הערה: באפליקציות, מומלץ להשתמש בפיצולים ולא בקובצי dex משניים.
- ספריות משותפות ב-Android (הרשומות <library> ו-<uses-library> במניפסט של Android) מיושמות באמצעות היררכיה שונה של טוען מחלקות מזו ששימשה בגרסאות קודמות של הפלטפורמה.
שינויים בהרשאות להצגת Intent במסך מלא
באפליקציות שמטרגטות את Android בגרסה 10 ואילך ומשתמשות בהתראות עם כוונות (intent) במסך מלא, צריך לבקש את ההרשאה 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, כדי לתת עדיפות גבוהה יותר לפעילויות שהמשתמש ביצע איתן אינטראקציה לאחרונה. פעילות יכולה להיות במצב top-resumed, אבל לא להיות במוקד (לדוגמה, אם מרכז ההתראות מורחב).
ב-Android 10 (רמת API 29) ואילך, אתם יכולים להירשם לקריאה החוזרת (callback) של onTopResumedActivityChanged() כדי לקבל התראה כשהפעילות שלכם מקבלת או מאבדת את המיקום העליון ביותר של המשך הפעילות. זהו המצב המקביל למצב resumed לפני Android 10, והוא יכול להיות שימושי כרמז אם האפליקציה שלכם משתמשת במשאבים בלעדיים או במשאבים מסוג singleton, שאולי צריך לשתף עם אפליקציות אחרות.
גם ההתנהגות של המאפיין
resizeableActivity
במניפסט השתנתה. אם אפליקציה מגדירה את resizeableActivity=false ב-Android 10 (רמת API 29) ואילך, יכול להיות שהיא תועבר למצב תאימות כשגודל המסך הזמין ישתנה, או אם האפליקציה תעבור ממסך אחד למסך אחר.
אפליקציות יכולות להשתמש במאפיין android:minAspectRatio, שהוצג ב-Android 10, כדי לציין את יחסי המסך שהאפליקציה תומכת בהם.
החל מגרסה 3.5, כלי האמולטור של Android Studio כולל מכשירים וירטואליים בגודל 7.3 אינץ' ו-8 אינץ' לבדיקת הקוד במסכים גדולים יותר.
מידע נוסף זמין במאמר עיצוב אפליקציות למכשירים מתקפלים.