מערכת Android 10 כוללת שינויים מעודכנים בהתנהגות המערכת שעשויים להשפיע על האפליקציה שלכם. השינויים שמפורטים בדף הזה חלים אך ורק על אפליקציות שמטרגטות את API מגרסה 29 ואילך. אם באפליקציה שלכם הערך של targetSdkVersion מוגדר ל-'29' או יותר, עליכם לשנות את האפליקציה כך שתתמוך בהתנהגויות האלה בצורה תקינה, במקרים הרלוונטיים.
מומלץ גם לעיין ברשימת השינויים בהתנהגות שמשפיעים על כל האפליקציות שפועלות ב-Android 10.
הערה: בנוסף לשינויים שמפורטים בדף הזה, ב-Android 10 יש מספר רב של שינויים והגבלות שמבוססים על פרטיות, כולל:
- נפח אחסון ייעודי לאפליקציות
- גישה למספר הסידורי של מכשיר USB
- יכולת להפעיל, להשבית ולהגדיר את ה-Wi-Fi
- הרשאות מיקום לממשקי API של קישוריות
השינויים האלה, שמשפיעים על אפליקציות שמטרגטות לרמת API 29 ואילך, משפרים את פרטיות המשתמשים. למידע נוסף על התמיכה בשינויים האלה, אפשר לעיין בדף שינויים בנושא פרטיות.
עדכונים בהגבלות על ממשקים שאינם ב-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 של Android Java כדי ליצור אזורי זיכרון משותפים. השינוי הזה מגביר את האבטחה והעמידות בעבודה עם זיכרון משותף, ומשפר את הביצועים והאבטחה של 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) מיושמות באמצעות היררכיה שונה של מעמיס הכיתות מזו שבה נעשה שימוש בגרסאות קודמות של הפלטפורמה.
שינויים בהרשאות ל-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, והוא יכול לשמש כנקודת התייחסות אם האפליקציה שלכם משתמשת במשאבים בלעדיים או ייחודיים שיכול להיות שתצטרכו לשתף עם אפליקציות אחרות.
גם ההתנהגות של מאפיין המניפסט resizeableActivity השתנתה. אם אפליקציה מגדירה את resizeableActivity=false ב-Android 10 (רמת API 29) ואילך, יכול להיות שהיא תעבור למצב תאימות
כשגודל המסך הזמין משתנה, או אם האפליקציה עוברת ממסך אחד לאחר.
אפליקציות יכולות להשתמש במאפיין android:minAspectRatio, שהוצג ב-Android 10, כדי לציין את יחסי המסך שהאפליקציה תומכת בהם.
החל מגרסה 3.5, כלי האמולטור של Android Studio כולל מכשירי וירטואליים בגודל 7.3" ו-8" לבדיקה של הקוד במסכים גדולים יותר.
מידע נוסף זמין במאמר תכנון אפליקציות למכשירים מתקפלים.