שינויים בהתנהגות ב-Android 7.0

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

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

סוללה וזיכרון

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

נמנום

הושק ב-Android 6.0 (רמת API 23), Doze משפר את חיי הסוללה על ידי דחיית פעילויות של המעבד (CPU) והרשת כשהמשתמש משאיר מכשיר מנותק מהחשמל, תמיד וכשהמסך כבוי. Android 7.0 יותר מתקדם משפרים את Doze על ידי החלת מגבלות על המעבד (CPU) והרשת כשהמכשיר מנותק כשהמסך כבוי, אבל לא בהכרח במכשיר נייח, לדוגמה, כשטלפון נמצא בכיס של המשתמש.

איור 1. איור של האופן שבו אפליקציית Doze מיישמת רמה ראשונה של הגבלות על הפעילות במערכת, כדי לשפר את חיי הסוללה.

כשהמכשיר פועל באמצעות סוללה והמסך כבוי למשך המכשיר נכנס ל'נמנום' ומחיל את קבוצת המשנה הראשונה של ההגבלות: משבית את הגישה לרשת האפליקציות ודוחה משימות וסנכרונים. אם המכשיר לעמוד למשך זמן מסוים לאחר הכניסה ל'נמנום', המערכת מחילה את שאר ההגבלות של 'נמנום' בPowerManager.WakeLock, AlarmManager התראות, GPS וסריקות Wi-Fi. ללא קשר ל: בין אם חלות חלק מההגבלות של מצב 'נמנום' או את כולן, המערכת מוציאה את המחשב ממצב שינה במכשיר לחלונות תחזוקה קצרים, שבמהלכם מותרות אפליקציות גישה לרשת ויכולה להפעיל משימות/סנכרון שנדחו.

איור 2. איור של האופן שבו Doze מבצע רמה שנייה של הגבלות על הפעילות של המערכת לאחר שהמכשיר נשאר נייח למשך זמן מסוים.

שימו לב שהפעלת המסך או חיבור המכשיר יובילו ליציאה ממצב 'נמנום' ו- מסירה את ההגבלות האלה על העיבוד. ההתנהגות הנוספת לא משפיעה על ההמלצות ועל השיטות המומלצות להתאמת האפליקציה שלכם הגרסה של Doze שהושקה ב-Android 6.0 (רמת API 23), כפי שמתואר ב אופטימיזציה ל'נמנום' ול'מצב המתנה'. עדיין עליך ליישם את ההמלצות האלה, כמו שימוש בהעברת הודעות בענן ב-Firebase (FCM) כדי לשלוח ולקבל הודעות, ולהתחיל לתכנן עדכונים כדי התנהגות נוספת של 'נמנום'.

פרויקט Svelte: אופטימיזציות של רקעים

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

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

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

כדי לפתור את הבעיות האלה, מערכת Android 7.0 מחילה את הכללים הבאים אופטימיזציות:

• אפליקציות שמטרגטות ל-Android 7.0 (רמת API 24) ואילך לא מקבלות CONNECTIVITY_ACTION ישודרו, אם הם להצהיר על מקלט השידור שלהם במניפסט. האפליקציות עדיין יפעלו לקבל שידורים של CONNECTIVITY_ACTION אם הם יירשמו BroadcastReceiver עם Context.registerReceiver() וההקשר הזה עדיין תקף.
• המערכת לא שולחת יותר שידורים של ACTION_NEW_PICTURE או ACTION_NEW_VIDEO. האופטימיזציה הזו משפיעה על כל האפליקציות, לא רק על אפליקציות שמטרגטות ל-Android 7.0.

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

למידע נוסף על אופטימיזציות ברקע ב-Android 7.0 (רמת API) 24) ואיך להתאים את האפליקציה, ראו רקע אופטימיזציות.

שינויים בהרשאות

מערכת Android 7.0 כוללת שינויים בהרשאות שעשויים להשפיע על האפליקציה שלך.

שינויים בהרשאות של מערכת הקבצים

כדי לשפר את האבטחה של קבצים פרטיים, הספרייה הפרטית לאפליקציות שמטרגטות ל-Android 7.0 ואילך יש גישה מוגבלת (0700). ההגדרה הזו מונעת דליפה של מטא-נתונים של קבצים פרטיים, כמו הגודל שלהם. או קיום. לשינוי הזה בהרשאה יש מספר תופעות לוואי:

• כבר לא הבעלים של הרשאות הגישה לקבצים פרטיים, בניסיון לעשות זאת באמצעות MODE_WORLD_READABLE ו/או MODE_WORLD_WRITEABLE, תפעיל SecurityException.

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

• העברת file:// מזהי URI מחוץ לדומיין החבילה עשויה להשאיר את המקבל דרך נתיב לא נגיש. לכן, מנסה להעביר file:// URI להפעלת טריגר FileUriExposedException. הדרך המומלצת לשתף את תוכן של קובץ פרטי משתמש ברכיב FileProvider.
• לDownloadManager אין יותר אפשרות לשתף באופן פרטי של קבצים מאוחסנים לפי שמות קבצים. יישומים מדור קודם עלולים להוביל נתיב לא נגיש בעת גישה אל COLUMN_LOCAL_FILENAME. טירגוט לאפליקציות מערכת Android מגרסה 7.0 ואילך מפעילה SecurityException כאשר מתבצע ניסיון לגשת COLUMN_LOCAL_FILENAME. אפליקציות מדור קודם שמגדירות את מיקום ההורדה למיקום ציבורי על ידי באמצעות DownloadManager.Request.setDestinationInExternalFilesDir() או DownloadManager.Request.setDestinationInExternalPublicDir() עדיין יכול לגשת לנתיב בתוך COLUMN_LOCAL_FILENAME. עם זאת, ההגדרה הזו מומלץ מאוד להימנע משימוש בשיטות עבודה. הדרך המועדפת לגשת לקובץ שנחשפה על ידי DownloadManager משתמשת ContentResolver.openFileDescriptor().

שיתוף קבצים בין אפליקציות

לגבי אפליקציות שמטרגטות ל-Android 7.0, מערכת Android אוכפת מדיניות ה-API StrictMode שאוסרת על חשיפת URI של file:// מחוץ לאפליקציה. אם אובייקט Intent שמכיל URI של קובץ יוצא מהאפליקציה, האפליקציה תיכשל. עם חריג מסוג FileUriExposedException.

כדי לשתף קבצים בין אפליקציות, צריך לשלוח URI של content:// ותעניק הרשאת גישה זמנית ב-URI. הדרך הקלה ביותר להעניק את ההרשאה הזו היא באמצעות הכיתה FileProvider. אפשר לקבל מידע נוסף בהרשאות ובשיתוף קבצים, ראה שיתוף קבצים.

שיפורי נגישות

Android 7.0 כולל שינויים שנועדו לשפר את נוחות השימוש פלטפורמה למשתמשים עם ליקויי ראייה. השינויים האלה אמורים בדרך כלל לא מחייבים שינויים בקוד באפליקציה, אבל צריך לבדוק את התכונות האלה ולבדוק אותן באפליקציה כדי להעריך את ההשפעות הפוטנציאליות על המשתמשים חוויה אישית.

זום במסך

מערכת Android 7.0 מאפשרת למשתמשים להגדיר גודל תצוגה להגדלת התצוגה או מכווץ את כל האלמנטים במסך, וכך משפר את נגישות המכשיר למשתמשים עם ליקויי ראייה. המשתמשים לא יכולים לשנות את מרחק התצוגה של המסך מעבר למסך מינימלי רוחב של sw320dp, שהוא הרוחב של Nexus 4, טלפון בגודל בינוני נפוץ.

איור 3. המסך שבצד ימין מציג את האפקט של הגדלת התצוגה של מכשיר שבו פועלת תמונת מערכת של Android 7.0.

כשצפיפות המכשיר משתנה, המערכת מודיעה לאפליקציות שפועלות בדרכים הבאות:

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

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

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

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

• הימנעו מציון מידות ביחידות פיקסלים, מכיוון שהן לא מותאמות לעומס (scaling) צפיפות המסך. במקום זאת, ציינו מימדים עם נתונים שלא תלויים בדחיסות פיקסלים (dp).

הגדרות הראייה באשף ההגדרה

מערכת Android 7.0 כוללת את הגדרות הראייה במסך הפתיחה, שמאפשרות למשתמשים קובעים את הגדרות הנגישות הבאות במכשיר חדש: תנועת הגדלה, גודל גופן, גודל התצוגה ו-TalkBack. השינוי הזה הגדלת החשיפה של באגים שקשורים להגדרות מסך שונות. שפת תרגום כדי להעריך את ההשפעה של התכונה הזו, צריך לבדוק את האפליקציות בעזרת ההגדרות מופעלות. ניתן למצוא את ההגדרות בקטע הגדרות > נגישות.

אפליקציות NDK מקושרות לספריות פלטפורמה

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

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

• האפליקציה ניגשת ישירות לספריות של פלטפורמות פרטיות. עליך לעדכן לכלול עותק משלו של הספריות האלה, או להשתמש בממשקי NDK API הציבוריים.
• האפליקציה שלך מתבססת על ספרייה של צד שלישי שיש לה גישה לפלטפורמה פרטית של הספריות. גם אם אין לך ספק שהאפליקציה שלך לא ניגשת לספריות פרטיות ישירות, עדיין צריך לבדוק את האפליקציה בשביל התרחיש הזה.
• האפליקציה מפנה לספרייה שלא כלולה ב-APK שלה. עבור לדוגמה, דבר זה עשוי לקרות אם ניסיתם להשתמש בעותק משלכם של OpenSSL שכחת לצרף אותו ל-APK של האפליקציה שלך. האפליקציה עשויה לפעול כרגיל בגרסאות של פלטפורמת Android שכוללת את libcrypto.so. אבל האפליקציה עלולה לקרוס בגרסאות מאוחרות יותר של Android שלא כוללות את הספרייה הזו (למשל, Android 6.0 ואילך). כדי לפתור את הבעיה, עליכם לוודא שאתם את הספריות שאינן NDK באמצעות ה-APK.

אסור לאפליקציות להשתמש בספריות נייטיב שאינן כלולות ב-NDK כי הם עשויים להשתנות או יוסרו בין גרסאות שונות של Android. מעבר מ-OpenSSL ל-BoringSSL הוא דוגמה לשינוי כזה. כמו כן, כי אין דרישות תאימות לגבי ספריות פלטפורמה. שנכללים ב-NDK, מכשירים שונים עשויים להציע רמות שונות של בתאימות מלאה.

כדי לצמצם את ההשפעה שעשויה להיות להגבלה הזו על אתרים שהושקו, קבוצה של ספריות שיש להן שימוש משמעותי - כמו libandroid_runtime.so, libcutils.so libcrypto.so ו-libssl.so — זמנית זמינים ב-Android 7.0 (רמת API 24) לאפליקציות שמטרגטות לרמת API 23, או נמוכה יותר. אם האפליקציה שלך טוענת את אחת מהספריות האלה, Logcat יוצר אזהרה והודעה קופצת מופיע במכשיר היעד כדי להודיע לכם. אם האלמנטים האלה מוצגים מעל האזהרות, צריך לעדכן את האפליקציה כך שתכלול עותקים שלה ספריות או להשתמש רק בממשקי ה-API הציבוריים של NDK. גרסאות עתידיות של Android עשויה להגביל את השימוש בספריות פרטיות לחלוטין ולגרום לכך לקרוס.

כל האפליקציות מייצרות שגיאת זמן ריצה כשהן מבצעות קריאה ל-API שלא קיים בכלל ציבורי או נגיש באופן זמני. כתוצאה מכך, System.loadLibrary ו-dlopen(3) חוזרים שניהם NULL ועלול לגרום לקריסת האפליקציה. עליך לבדוק את של האפליקציה להסיר את השימוש בממשקי API של פלטפורמה פרטית ולבדוק ביסודיות את האפליקציות שלכם באמצעות מכשיר או אמולטור עם Android 7.0 (רמת API 24). אם אתם לא בטוחים אם האפליקציה שלכם משתמשת בספריות פרטיות, אפשר לבדוק את Logcat כדי לזהות את השגיאה בסביבת זמן הריצה.

הטבלה הבאה מתארת את ההתנהגות שהיית מצפה לראות במהלך האפליקציה, בהתאם לשימוש בספריות מותאמות פרטיות ולממשק ה-API המטורגט שלה רמה (android:targetSdkVersion).

בודקים אם באפליקציה נעשה שימוש בספריות פרטיות

כדי לעזור לך לזהות בעיות בטעינת ספריות פרטיות, Logcat עשוי ליצור אזהרה או שגיאה בתחילת ההפעלה. לדוגמה, אם האפליקציה מטרגטת את רמת ה-API 23, או ומנסה לגשת לספרייה פרטית במכשיר שמערכת ההפעלה שלו היא Android 7.0, יכול להיות שתוצג אזהרה שדומה לזו:

03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120

אזהרות ה-Logcat האלה מציינות איזו ספרייה מנסה לגשת אבל הוא לא יגרום לאפליקציה לקרוס. אם האפליקציה מטורגט לרמת API 24 ומעלה, אבל Logcat יוצר את הדברים הבאים שגיאת זמן ריצה והאפליקציה שלך עלולה לקרוס:

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by
"/system/lib/libnativeloader.so" is not accessible for the namespace
"classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)

יכול להיות שפלטי ה-Logcat האלה יוצגו גם אם האפליקציה משתמשת בספריות של צד שלישי שמקשרות באופן דינמי לממשקי API של הפלטפורמה הפרטית. הכלי Readelf ב-Android 7.0DK אפשר ליצור רשימה של כל הקבצים ששותפו באופן דינמי ספריות של קובץ .so נתון באמצעות הפקודה הבאה:

aarch64-linux-android-readelf -dW libMyLibrary.so

עדכון האפליקציה

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

• אם באפליקציה נעשה שימוש בספריות של פלטפורמה פרטית, צריך לעדכן אותה כך שתכלול עותק משלו של הספריות האלה, או להשתמש בממשקי ה-API הציבוריים של NDK.
• אם באפליקציה נעשה שימוש בספרייה של צד שלישי שיש לה גישה לסמלים פרטיים, צריך ליצור קשר עם מחבר הספרייה כדי לעדכן את הספרייה.
• חשוב לארוז את כל הספריות שאינן NDK עם ה-APK.
• להשתמש בפונקציות JNI רגילות במקום ב-getJavaVM. getJNIEnv מאת libandroid_runtime.so:

  AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
  AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
  JavaVM::AttachCurrentThread from <jni.h>.
  

• יש להשתמש ב-__system_property_get במקום ב-property_get הפרטי מ-libcutils.so. כדי לעשות את זה, צריך להשתמש ב-__system_property_get הם כוללים:

  #include <sys/system_properties.h>
  

  הערה: הזמינות והתוכן של מאפייני המערכת הם לא נבדקו באמצעות CTS. פתרון טוב יותר הוא להימנע משימוש נכסים בסך הכול.

• צריך להשתמש בגרסה מקומית של הסמל SSL_ctrl מ-libcrypto.so. לדוגמה, צריך ליצור קישור סטטי של libcyrpto.a ב- את קובץ .so, או לכלול גרסה של libcrypto.so המקושרת באופן דינמי מ-BoringSSL/OpenSSL ולארוז אותו ב-APK.

Android for Work

מערכת Android 7.0 כוללת שינויים באפליקציות שמטרגטות את Android for Work, כולל שינויים שינויים בהתקנת אישורים, איפוס סיסמה, משתמש משני ניהול וגישה למזהי מכשירים. אם אתם מפתחים אפליקציות בסביבות של Android for Work, עליך לבדוק את השינויים האלה ולשנות בהתאם.

• כדי שה-DPC יוכל להגדיר, צריך להתקין מנהל התקנה של אישורים שהוענקה הרשאה לנהל אותם. את זה. באפליקציות של בעלי פרופיל וגם באפליקציות של בעלי מכשיר שמטרגטות את Android 7.0 (רמת API 24), עליך להתקין את מנהל ההתקנה של האישורים המואצלים לפני מדיניות המכשיר קריאות בקר (DPC) DevicePolicyManager.setCertInstallerPackage() אם מנהל ההתקנה עדיין לא מותקן, המערכת גורמת IllegalArgumentException
• איפוס ההגבלות על סיסמאות עבור מנהלי מכשירים חלות עכשיו על הפרופיל בעלים. מנהלי מכשירים כבר לא יכולים להשתמש DevicePolicyManager.resetPassword() כדי למחוק סיסמאות או לשנות אותן שכבר הוגדרו. מנהלי מכשירים עדיין יכולים להגדיר סיסמה, אבל רק כשהמכשיר לא כולל סיסמה, קוד אימות או קו ביטול נעילה.
• בעלי המכשירים והפרופילים יכולים לנהל את החשבונות גם אם חלות עליהם הגבלות הוגדרה. בעלי מכשירים ובעלי פרופילים יכולים לקרוא לממשקי ה-API של ניהול החשבון גם אם חלות DISALLOW_MODIFY_ACCOUNTS הגבלות על המשתמשים.
• בעלי מכשירים יכולים לנהל משתמשים משניים בקלות רבה יותר. כאשר מכשיר פועל במצב 'בעלי המכשיר', ההגבלה DISALLOW_ADD_USER מוגדר באופן אוטומטי. ההגדרה הזו מונעת מהמשתמשים ליצור גרסת משנה לא מנוהלת משתמשים. בנוסף, CreateUser() השיטות של createAndInitializeUser() הוצאו משימוש. החדש השיטה DevicePolicyManager.createAndManageUser() מחליפה אותם.
• בעלי מכשירים יכולים לגשת למזהי המכשירים. בעלי המכשיר יכולים לגשת אל כתובת MAC של Wi-Fi של מכשיר, באמצעות DevicePolicyManager.getWifiMacAddress() אם חיבור ה-Wi-Fi מעולם לא מופעל במכשיר, השיטה הזו מחזירה את הערך null.
• בעזרת ההגדרה 'מצב עבודה' אפשר לשלוט בגישה לאפליקציות לעבודה. כשמצב עבודה מושבת מרכז האפליקציות מציין שאפליקציות לעבודה לא זמינות ומוצגות באפור. מפעיל מצב עבודה חוזר למצב הרגיל.
• כשמתקינים קובץ PKCS #12 שמכיל שרשרת אישורי לקוח המפתח הפרטי התואם מממשק המשתמש של ההגדרות, אישור ה-CA שרשרת לא מותקנת יותר באחסון של פרטי הכניסה המהימנים. זה כן לא משפיעה על התוצאה של KeyChain.getCertificateChain() כשאפליקציות מנסות לאחזר את הלקוח את שרשרת האישורים מאוחר יותר. במקרה הצורך, צריך להתקין את אישור ה-CA לאחסון של פרטי הכניסה המהימנים דרך ממשק המשתמש של ההגדרות בנפרד, עם פורמט בקידוד DER עם סיומת קובץ .crt או .cer
• החל מגרסת Android 7.0, הרישום והאחסון באמצעות טביעת אצבע מנוהלים לכל משתמש. אם לקוח Device Policy (DPC) של הבעלים של הפרופיל מטרגט רמת API לגרסה 23 (או פחות) במכשיר עם Android 7.0 (רמת API 24), המשתמש עדיין יכולים להגדיר טביעת אצבע במכשיר, אבל אפליקציות לעבודה לא יכולות גישה לטביעת האצבע של המכשיר. כשבקר DPC מוגדר לרמת API 24 ומעלה, המשתמש יכול להגדיר טביעת אצבע במיוחד לפרופיל עבודה. לשם כך, עוברים להגדרות > אבטחה > אבטחה של פרופיל העבודה
• סטטוס ההצפנה החדש: ENCRYPTION_STATUS_ACTIVE_PER_USER הוחזר על ידי DevicePolicyManager.getStorageEncryptionStatus(), אל מציין שההצפנה פעילה ומפתח ההצפנה קשור משתמש. הסטטוס החדש מוחזר רק אם בקר DPC מטרגט API ברמה 24 ואילך. באפליקציות שמטרגטות רמות API מוקדמות יותר, ENCRYPTION_STATUS_ACTIVE מוחזר, גם אם מפתח ההצפנה הוא ספציפי למשתמש או לפרופיל.
• ב-Android 7.0, מספר שיטות שבדרך כלל ישפיעו על כל להתנהג באופן שונה אם במכשיר מותקן פרופיל עבודה עם אתגר עבודה נפרד. במקום להשפיע על המכשיר כולו, השיטות האלה רלוונטיות רק לפרופיל העבודה. (הרשימה המלאה של שיטות כאלה במסמכי התיעוד של DevicePolicyManager.getParentProfileInstance()). לדוגמה, DevicePolicyManager.lockNow() נועל רק את פרופיל העבודה, במקום נעילת המכשיר כולו. בכל אחת מהשיטות האלה, אפשר לקבל את באמצעות קריאה ל-method במופע ההורה של DevicePolicyManager; אפשר לקבל את ההורה הזה עד בהתקשרות אל DevicePolicyManager.getParentProfileInstance(). לדוגמה, אם התקשרתם lockNow() של מופע ההורה אמצעית, המכשיר כולו נעול.

שמירת הערות

מערכת Android 7.0 מתקנת באג שבמסגרתו המערכת מתעלמת מהצגת ההערות. הבעיה הזו אפשרה לסביבת זמן הריצה לגשת להערות שלא היו אמורות להופיע שאפשר. ההערות האלה כללו את:

• VISIBILITY_BUILD: מיועדת להיות גלויה רק בזמן ה-build.
• VISIBILITY_SYSTEM: נועד להיות גלוי בזמן ריצה, אבל רק במערכת הבסיסית.

אם האפליקציה שלך הסתמכה על ההתנהגות הזו, עליך להוסיף מדיניות שמירת נתונים להערות שחובה יהיו זמינים בזמן הריצה. אפשר לעשות את זה באמצעות @Retention(RetentionPolicy.RUNTIME).

שינויים בהגדרות ברירת המחדל של TLS/SSL

ב-Android 7.0 מתבצעים השינויים הבאים בהגדרות ברירת המחדל של TLS (אבטחת שכבת התעבורה)/SSL משמש אפליקציות ל-HTTPS ולתנועת TLS/SSL אחרת:

• סטים של אלגוריתמים להצפנה (cipher suite) מסוג RC4 מושבתים עכשיו.
• סטים של אלגוריתמים להצפנה (cipher suite) מסוג CHACHA20-POLY1305 מופעלים עכשיו.

השבתת RC4 כברירת מחדל עלולה לגרום לשיבושים ב-HTTPS או ב-TLS/SSL קישוריות כאשר השרת לא מנהל משא ומתן על סטים מודרניים של אלגוריתמים להצפנה (cipher suite). התיקון המועדף הוא לשפר את תצורת השרת כדי ועוד סטים של אלגוריתמים להצפנה (cipher suite) ופרוטוקולים מודרניים יותר. במצב אידיאלי, TLSv1.2 ו-AES-GCM צריך להיות מופעל, וסטים של אלגוריתמים להצפנה (cipher suite) מסוג Forward Secrecy (ECDHE) צריכים להיות מופעלים. להיות מופעלת ומועדפת.

לחלופין, אפשר לשנות את האפליקציה כך שתשתמש ב-SSLSocketFactory בהתאמה אישית לצורך תקשורת עם השרת. צריך ליצור במפעל SSLSocket כדי ליצור שכוללים חלק מחבילות ההצפנה שנדרשות על ידי השרת מופעלת בנוסף לחבילות ברירת המחדל של אלגוריתמים להצפנה (cipher suite).

הערה: השינויים האלה לא חלים על WebView.

אפליקציות שמטרגטות את Android 7.0

השינויים האלה בהתנהגות חלים רק על אפליקציות שמטרגטות Android מגרסה 7.0 (רמת API 24) ואילך. אפליקציות שעברו הידור (compile) ל-Android 7.0, או להגדיר את targetSdkVersion ל-Android 7.0 ואילך חייבים לשנות את האפליקציות שלהם כך שיתמכו בהתנהגויות האלה באופן תקין, במקרים שבהם הן רלוונטיות.

שינויים בעריכה בסדרה

מערכת Android 7.0 (רמת API 24) תיקנה באג בחישוב של ברירת המחדל substituteVersionUID כאשר הוא לא תואם למפרט.

מחלקות שמטמיעות את Serializable ולא לציין שדה serialVersionUID מפורש, לראות שינוי בברירת המחדל של robotsVersionUID, שיכול לגרום לחריגה לזרוק כשמנסים לבצע deserialize למופעים של המחלקה שהיו עבר סריאליזציה לגרסה קודמת או עבר סריאליזציה באמצעות אפליקציה שמטרגטת גרסה קודמת . הודעת השגיאה תיראה כך:

local class incompatible: stream classdesc serialVersionUID = 1234, local class serialVersionUID = 4567

כדי לפתור את הבעיות האלה צריך להוסיף את השדה serialVersionUID אל כל מחלקה המושפעת עם הערך stream classdesc serialVersionUID מהודעת השגיאה. למשל 1234 אינץ' במקרה הזה. השינוי הזה תואם לכל ההמלצות לשיטות מומלצות כתיבת קוד בהמשכים. הקוד יפעל בכל הגרסאות של Android.

הבאג הספציפי שתוקן היה קשור לנוכחות של אלמנטים סטטיים שיטות מאתחל, למשל <clinit>. לפי לציין את הנוכחות או היעדר של שיטת מאתחל סטטי ה-class ישפיע על ברירת המחדל סידורי ה-SeriesUID המחושב עבור המחלקה הזו. לפני תיקון הבאג, החישוב היה גם בודק את מחלקת העל של מאתחל סטטי אם למחלקה לא היה כזה.

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

נקודות חשובות נוספות

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

  עליך לבדוק את האפליקציה כדי לוודא שהתנהגות כזו לא תתרחש. אפשר לעשות זאת על ידי יצירת קריסה זהה בעת סגירת האפליקציה באופן ידני באמצעות DDMS.

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

• אפליקציות ב-Android 7.0 צריכות להיות מסוגלות לטפל באלגנטיות בשינויי הגדרות אישיות והיא לא אמורה לקרוס בהפעלות הבאות. אפשר לאמת את התנהגות האפליקציה על ידי שינוי גודל הגופן (הגדרה > Display > גודל הגופן), ולאחר מכן שחזור את האפליקציה מהקטע 'אחרונים'.
• עקב באג בגרסאות קודמות של Android, המערכת לא סימנה את הכתיבה לשקע TCP ב-thread הראשי כהפרה של מצב מחמיר. מערכת Android 7.0 מתקנת את הבאג הזה. אפליקציות שמפגנות את ההתנהגות הזו גורמות עכשיו ל-android.os.NetworkOnMainThreadException. באופן כללי, לא כדאי לבצע פעולות רשת ב-thread הראשי כי הפעולות האלה בדרך כלל יש זמן אחזור ארוך שגורם לשגיאות ANR ולבעיות בממשק.
• ברירת המחדל של משפחת השיטות Debug.startMethodTracing() היא שמירת הפלט בספרייה הספציפית לחבילה שלך באחסון משותף, במקום ברמה העליונה של כרטיס ה-SD. כלומר, אפליקציות לא יצטרכו יותר לבקש הרשאה ל-WRITE_EXTERNAL_STORAGE כדי להשתמש בממשקי ה-API האלה.
• הרבה ממשקי API של פלטפורמות התחילו עכשיו לבדוק אם נשלחים מטענים ייעודיים (payloads) גדולים ב-Binder עסקאות, המערכת מבצעת עכשיו הדפסה מחדש של TransactionTooLargeExceptions בתור RuntimeExceptions, במקום לרשום או להסתיר אותן בטעות. אחת למשל, אחסון יותר מדי נתונים Activity.onSaveInstanceState(), שגורם ל-ActivityThread.StopInfo לזרוק RuntimeException כשהאפליקציה מטרגטת את Android 7.0.
• אם אפליקציה מפרסמת Runnable משימות ב-View, וגם View לא מחובר לחלון, המערכת להוסיף את המשימה Runnable לרשימת הבאים בתור View. המשימה Runnable לא תתבצע עד הקובץ View מצורף לחלון. הפעולה הזו מתקנת את הבאגים הבאים:
  • אם אפליקציה פרסמה פוסט ב-View משרשור שונה מזה שהתכוונתם אליו בשרשור של ממשק המשתמש של החלון, יכול להיות שה-Runnable יפעל בשרשור הלא נכון.
  • אם המשימה Runnable פורסמה משרשור שהוא לא שרשור בלופ, האפליקציה יכולה לחשוף את המשימה Runnable.
• אם אפליקציה ב-Android 7.0 עם DELETE_PACKAGES מנסה למחוק חבילה, אבל אפליקציה אחרת התקינה את החבילה, המערכת דורשת אישור משתמש. בתרחיש הזה, אפליקציות צריכות לצפות STATUS_PENDING_USER_ACTION בתור סטטוס ההחזרה בזמן ההפעלה PackageInstaller.uninstall().
• ספק ה-JCA שנקרא Crypto הוצא משימוש, כי הוא SHA1PRNG, הוא חלש מבחינה קריפטוגרפית. אפליקציות כבר לא יכולות להשתמש SHA1PRNG למפתחות (בצורה לא מאובטחת) של מפתחות, כי הספק הזה כבר לא קיים זמינים. מידע נוסף זמין בבלוג פרסום אבטחה "Crypto" הספק הוצא משימוש ב-Android N.