תכונות וממשקי API של Android 8.0

ב-Android 8.0 (רמת API‏ 26) יש מגוון תכונות ויכולות חדשות למשתמשים ולמפתחים. במסמך הזה נסקור את החידושים למפתחים.

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

חווית משתמש

מצב תמונה בתוך תמונה

התכונה 'תמונה בתוך תמונה' ב-Android מגרסה 8.0.

ב-Android 8.0 (רמת API‏ 26) אפשר להפעיל פעילויות במצב תמונה בתוך תמונה (PIP). התכונה 'תמונה בתוך תמונה' (PiP) היא סוג מיוחד של מצב 'חלונות מרובים', שמשמשים בעיקר להפעלת סרטונים. מצב PIP היה זמין במקור עבור Android TV בלבד; התכונה Android 8.0 זמינה במכשירי Android אחרים.

כשפעילות נמצאת במצב PIP, היא נמצאת במצב מושהה, אבל התוכן שלה אמור להמשיך להופיע. לכן, חשוב לוודא שהאפליקציה לא משהה את ההפעלה במנהל האירועים onPause(). במקום זאת, צריך להשהות את הסרטון בonStop() ולהמשיך את ההפעלה בעוד onStart(). מידע נוסף זמין במאמר הבא: ריבוי חלונות מחזור חיים.

כדי לציין שהפעילות יכולה להשתמש במצב PIP, מגדירים את הערך של android:supportsPictureInPicture כ-true במניפסט. (החל מגרסה 8.0 של Android, בשביל PIP לא נדרש מאפיין מניפסט android:resizeableActivity. אבל חייבים להגדיר android:resizeableActivity ל-true אם הפעילות שלך תומכת בסוגים אחרים מצבים של ריבוי חלונות.)

Android 8.0 (רמת API 26) כולל אובייקט חדש, PictureInPictureParams, שמעבירים ל-methods של PIP כדי לציין איך פעילות אמורה להתנהג כשהוא במצב PIP. האובייקט הזה מציין מאפיינים כמו יחס הגובה-רוחב המועדף של הפעילות.

עכשיו אפשר להשתמש בשיטות הקיימות של התכונה 'תמונה בתוך תמונה' (PIP) שמתוארות במאמר הוספת התכונה 'תמונה בתוך תמונה' בכל מכשירי Android, ולא רק ב-Android TV. בנוסף, ב-Android מגרסה 8.0 יש את השיטות הבאות לתמיכה במצב PIP:

  • Activity.enterPictureInPictureMode(PictureInPictureParams args): תמקם את הפעילות במצב 'תמונה בתוך תמונה'. args מציין את יחס הגובה-רוחב של הפעילות והגדרות אישיות אחרות. אם שדות כלשהם ב-args ריקים, המערכת תשתמש בערכים שהוגדרו בפעם האחרונה שביצעתם קריאה ל-Activity.setPictureInPictureParams().

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

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

התראות

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

    תפריט של התראה שנלחצים עליה לחיצה ארוכה ב-Android 8.0‏ (רמת API‏ 26).

    משתמשים יכולים ללחוץ לחיצה ארוכה על סמלי מרכז האפליקציות כדי להציג את ההתראות ב-Android 8.0.

  • ערוצי התראות: ב-Android 8.0 מופיעים ערוצי התראות שמאפשרים ליצור ערוץ מותאם אישית לכל סוג של התראה שרוצים להציג. ממשק המשתמש מתייחס לערוצי התראות בתור קטגוריות של התראות. במאמר ניהול ערוצי התראות מוסבר איך מטמיעים ערוצי התראות.
  • נקודות התראות: ב-Android 8.0 יש תמיכה בהצגה נקודות או תגים בסמלים במרכז האפליקציות. סימני ההתראות משקפות את קיימות התראות שהמשתמש עדיין לא סגר או לא ביצע לגביהן פעולות. כדי ללמוד איך לעבוד עם סימני ההתראות, אפשר לעיין במאמרים הבאים: התראה תגים.
  • העברה למצב נודניק: המשתמשים יכולים להעביר התראות למצב נודניק, וכך הן ייעלמו לתקופה מסוימת לפני שיופיעו שוב. ההתראות יופיעו שוב עם אותה רמת חשיבות שבה הן הופיעו בפעם הראשונה. אפליקציות יכולות להסיר או לעדכן התראה במצב נודניק, אבל עדכון התראה של מצב נודניק לא גורם כדי להופיע שוב.
  • זמן קצוב לתפוגה של התראות: אפשר להגדיר זמן קצוב לתפוגה במהלך יצירת התראה באמצעות setTimeoutAfter() אפשר להשתמש בשיטה הזו כדי לציין משך זמן שאחריו תישלח התראה צריך לבטל את ההזמנה. במקרה הצורך, אפשר לבטל התראה לפני יחלוף פרק הזמן הקצוב לתפוגה שהוגדר.
  • הגדרת התראות: אפשר להתקשר setSettingsText() כדי להגדיר את הטקסט שיופיע כשיוצרים קישור אל האפליקציה הגדרה של התראות מהתראה באמצעות Intent מסוג Notification.INTENT_CATEGORY_NOTIFICATION_PREFERENCES. המערכת עשויה לספק את התוספות הבאות מתוך כוונה לסנן ההגדרות שהאפליקציה צריכה להציג למשתמשים: EXTRA_CHANNEL_ID, NOTIFICATION_TAG ו-NOTIFICATION_ID.
  • סגירת התראה: המשתמשים יכולים לסגור התראות בעצמם, וגם אפליקציות יכולות להסיר אותן באופן פרוגרמטי. כדי לקבוע מתי התראה תיסגר ומדוע היא תיסגר, אפשר להטמיע את השיטה onNotificationRemoved() מהקלאס NotificationListenerService.
  • צבעי רקע: ניתן להגדיר צבע רקע ולהפעיל אותו עבור התראה. צריך להשתמש בתכונה הזו רק בהתראות עבור משימות מתמשכות שהן חיוניות שהמשתמש יכול לראות במבט חטוף. עבור לדוגמה, אפשר להגדיר צבע רקע עבור התראות שקשורות אל מסלול נסיעה או שיחת טלפון שמתבצעת. אפשר גם להגדיר את צבע הרקע הרצוי באמצעות setColor(). אם עושים את זה מאפשרת להשתמש ב-setColorized() כדי להפעיל שימוש בצבע רקע עבור התראה.
  • סגנון העברת הודעות: ב-Android 8.0, התראות שמבוססות על תצוגה של הכיתה ב-MessagingStyle עוד תוכן במצב המכווץ. כדאי להשתמש בכיתה MessagingStyle להתראות שקשורות להעברת הודעות. אפשר גם להשתמש שיטה addHistoricMessage() כדי לספק הקשר לשיחה על ידי הוספה הודעות היסטוריות להתראות שקשורות להעברת הודעות.

מסגרת למילוי אוטומטי

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

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

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

גופנים שניתנים להורדה

ב-Android 8.0 (רמת API‏ 26) וב-Android Support Library 26 אפשר לבקש גופנים מאפליקציית ספק במקום לארוז גופנים ב-APK או לאפשר ל-APK להוריד גופנים. התכונה הזו מקטינה את ה-APK, ומגדילה את האפליקציה שיעור ההצלחה של ההתקנה, ומאפשר לאפליקציות מרובות לשתף את אותו הגופן.

למידע נוסף על הורדת גופנים, עיינו ב גופנים להורדה.

גופנים ב-XML

ב-Android 8.0 (רמת API 26) נוספה תכונה חדשה, 'גופנים ב-XML', שמאפשרת להשתמש בגופנים כמשאבים. כלומר, אין צורך לקבץ גופנים כנכסים. הגופנים מורכבים בקובץ R ומעובדים באופן אוטומטי זמין במערכת בתור משאב. לאחר מכן תוכלו לגשת לגופנים האלה באמצעות סוג משאב חדש, font.

ב-Support Library 26 יש תמיכה מלאה בתכונה הזו במכשירים שפועלות בהם גרסאות API 14 ואילך.

מידע נוסף על שימוש בגופנים כמשאבים ועל אחזור גופנים של מערכת זמין במאמר גופנים ב-XML.

שינוי גודל אוטומטי של TextView

ב-Android 8.0 (רמת API 26) אפשר להגדיר שהטקסט יתרחב או יתכווץ באופן אוטומטי בהתאם לגודל של TextView. כלומר, לבצע אופטימיזציה של גודל הטקסט במסכים שונים או בתוכן דינמי. למידע נוסף על שינוי גודל אוטומטי של TextView ב-Android 8.0, ראו שינוי גודל אוטומטי של TextView.

סמלים מותאמים

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

ניהול צבעים

מפתחים של אפליקציות הדמיה ל-Android יכולים עכשיו לנצל מכשירים חדשים הם בעלי מסך רחב עם יכולות צבעים. כדי להציג סולם רחב תמונות, יהיה צורך להפעיל סימון במניפסט של האפליקציות (לכל פעילות) ולטעון מפות סיביות באמצעות פרופיל צבעים רחב מוטמע (AdobeRGB, Pro Photo RGB , DCI-P3 וכו').

ממשקי API של WebView

ב-Android 8.0 יש כמה ממשקי API שעוזרים לנהל WebView האובייקטים שמציגים תוכן מהאינטרנט באפליקציה. ממשקי ה-API האלה, שמשפרים את היציבות והאבטחה של האפליקציה, כוללים את הבאים:

  • Version API
  • ממשק API של Google לגלישה בטוחה
  • ממשק ה-API של ידית הסיום
  • Renderer Importance API

מידע נוסף על אופן השימוש בממשקי ה-API האלה זמין בכתובת ניהול רכיבי WebView.

הכיתה WebView כוללת עכשיו API של גלישה בטוחה לצורך שיפור האבטחה של הגלישה באינטרנט. מידע נוסף זמין במאמר Google Safe Browsing API.

הצמדת ווידג'טים וקיצורי דרך

ב-Android 8.0 (רמת API‏ 26) אפשר להצמיד קיצורי דרך וווידג'טים בתוך האפליקציה. באפליקציה שלך ניתן ליצור קיצורי דרך ווידג'טים מוצמדים במרכזי אפליקציות נתמכים, בכפוף להרשאת המשתמש.

מידע נוסף זמין במדריך למאפיין הצמדת קיצורי דרך וווידג'טים.

יחס הגובה-רוחב המקסימלי של המסך

במערכת Android 8.0 (רמת API 26) יש שינויים באופן ההגדרה של יחס גובה-רוחב מקסימלי באפליקציה.

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

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

תמיכה במספר מסכים

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

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

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

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

ActivityOptions מספק שתי שיטות חדשות לתמיכה במספר מסכים:

setLaunchDisplayId()
ההגדרה קובעת באיזה תצוגה של הפעילות תוצג לאחר ההפעלה.
getLaunchDisplayId()
מחזירה את תצוגת ההפעלה הנוכחית של הפעילות.

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

adb shell start <activity_name> --display <display_id>

שוליים ומרווחי פריסה מאוחדים

ב-Android 8.0 (רמה 26 של API) קל יותר לציין מצבים שבהם בצדדים מנוגדים של רכיב View נעשה שימוש באותו שוליים או רווח. באופן ספציפי, עכשיו אפשר להשתמש במאפיינים הבאים ב-XML של הפריסה קבצים:

הערה: אם אתם מתאימים אישית את הלוגיקה של האפליקציה: תמיכה אחרת ותרבויות שונות, כולל כיוון טקסט, צריך לזכור אינם משפיעים על הערכים של layout_marginStart, layout_marginEnd, paddingStart, או paddingEnd. אפשר להגדיר את הערכים האלה בעצמכם, בנוסף למאפייני הפריסה האנכית והאופקסיאלית החדשים, כדי ליצור התנהגות של פריסה שמבוססת על כיוון הטקסט.

לכידת מצביע

אפליקציות מסוימות, כמו משחקים, Remote Desktop ולקוחות וירטואליזציה, להפיק תועלת משליטה על סמן העכבר. תכונת Pointer capture היא תכונה חדשה ב-Android 8.0 (רמת API 26) שמאפשרת לכם לשלוט בכך על ידי העברת כל אירועי העכבר לתצוגה ממוקדת באפליקציה.

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

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

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

ב-Android 8.0 (רמת API‏ 26) כל אפליקציה יכולה להצהיר על קטגוריה שמתאימה לה, במקרים הרלוונטיים. הקטגוריות האלה משמשות לקיבוץ אפליקציות דומות מטרה או פונקציה כשמציגים אותם למשתמשים, למשל בקטע 'שימוש בנתונים', 'שימוש בסוללה' שימוש בנפח אחסון. אפשר להגדיר קטגוריה לאפליקציה על ידי הגדרת מאפיין android:appCategory ב<application> תג מניפסט.

מרכז האפליקציות ל-Android TV

Android 8.0 (רמת API 26) כולל חוויית מסך בית חדשה של Android TV שמתמקדת בתוכן. היא זמינה באמצעות אמולטור Android TV ותמונת המכשיר של Nexus Player ל-Android 8.0. תוכן הווידאו במסך הבית החדש מחולק לשורות שמתאימות לערוצים, וכל אחת מהן מאוכלסת בתוכניות על ידי אפליקציה במערכת. אפליקציות יכולות לפרסם כמה ערוצים, והמשתמשים יכולים להגדיר אילו ערוצים הם רוצים לראות במסך הבית. מסך הבית של Android TV כולל גם את השורה 'מה כדאי לצפות בו', שמאוכלסת בתוכניות מאפליקציות על סמך הרגלי הצפייה של המשתמש. אפליקציות יכולות גם לספק תצוגות מקדימות של סרטונים, שמופעלות באופן אוטומטי כשהמשתמש מתמקד בתוכנית. ממשקי ה-API של האכלוס של הערוצים והתוכניות הם חלק מממשקי ה-API של TvProvider, שמופצים כ-Android תמיכה במודול הספרייה עם Android 8.0.

קבוצת אנימטורים

החל מגרסה 8.0 של Android (רמת API 26), API של AnimatorSet תומך עכשיו בחיפוש ובהפעלה הפוך. דילוג מאפשר להגדיר את המיקום של קבוצת האנימציה בנקודת זמן ספציפית. הפעלה בסדר הפוך אם האפליקציה כוללת אנימציות בעקבות פעולות שאפשר לבטל. במקום להגדיר שתי קבוצות אנימציה נפרדות, אפשר להפעיל את אותה אנימציה בכיוון ההפוך.

קלט וניווט

אשכולות ניווט של המקלדת

אם בפעילות באפליקציה שלכם נעשה שימוש בהיררכיית תצוגה מורכבת, כמו זו שמוצגת באיור 2, מומלץ לארגן קבוצות של רכיבי ממשק המשתמש באשכולות כדי לנווט בקלות רבה יותר ביניהם באמצעות המקלדת. משתמשים יכולים ללחוץ על Meta+Tab או על Search+Tab במכשירי Chromebook כדי לנווט מאשכול אחד לאשכול אחר. דוגמאות טובות של אשכולות כוללים: חלוניות צדדיות, סרגלי ניווט, אזורי תוכן ראשיים ורכיבים שעלול להכיל הרבה רכיבי צאצא.

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

כדי להפוך אלמנט View או ViewGroup לאשכולות, מגדירים את המאפיין android:keyboardNavigationCluster לערך true בקובץ ה-XML של הפריסה של האלמנט, או מעבירים את הערך true אל setKeyboardNavigationCluster() בלוגיקה של ממשק המשתמש של האפליקציה.

הערה: אי אפשר להוסיף אשכולות בתוך אשכולות, אבל אשכולות לא מוערמים יכולים להופיע ברמות שונות בהיררכיה. אם תנסו אשכולות Nest, ה-framework מתייחס רק את הרכיב ViewGroup כאשכול.

במכשירים עם מסכי מגע, אפשר להגדיר את האלמנט android:touchscreenBlocksFocus של אובייקט ViewGroup שמיועד לאשכולות לערך true כדי לאפשר ניווט בתוך האשכול הזה ומחוצה לו רק בתוך האשכול. אם המערכת תחיל את ההגדרה הזו את ההגדרות האישיות של אשכול, המשתמשים לא יכולים להשתמש במקש Tab או במקשי החיצים כדי לנווט אל האשכול או ממנו; עליהם ללחוץ על הניווט באשכולות במקום זאת,

הצגת מצב הריכוז שמוגדר כברירת מחדל

ב-Android 8.0 (רמת API 26), אפשר להקצות את View קבלת מיקוד לאחר המשך פעילות שנוצרה מחדש והמשתמש לוחץ על לחצן מקש הניווט במקלדת, למשל Tab. כדי להחיל את ההגדרה 'מוקד בברירת מחדל', מגדירים את המאפיין android:focusedByDefault של אלמנט View לערך true בקובץ ה-XML של הפריסה שמכיל את אלמנט ממשק המשתמש, או מעבירים את הערך true אל setFocusedByDefault() בלוגיקה של ממשק המשתמש באפליקציה.

פלט דיבור

פעילויות ושירותים יכולים להשתמש במופעים של TextToSpeech כדי להכתיב ולבטא תוכן. נכון לתאריך Android 8.0 (רמת API 26), האפליקציה שלך יכולה לקבל פרטי תזמון מדויקים יותר בערך שבו מנוע המרת טקסט לדיבור מתחיל לומר מילים בודדות מסונתזות, כל עוד המנוע מספק את המידע הזה. אפשר להשתמש בפונקציונליות הזו להפנות את תשומת הלב למילים ספציפיות בזמן שמנוע המרת הטקסט לדיבור מדבר אותם.

כדי להשתמש בשיפורים האלה במנוע ההמרה של טקסט לדיבור באפליקציה, צריך לרשום מופע של UtteranceProgressListener. כחלק מתהליך הרישום, צריך לכלול טיפול (handler) ל-method‏ onRangeStart().

הקריאות למנוע המרת טקסט לדיבור (TTS) rangeStart() להקלטה נקודת הזמן שבה מצפה הפעלת אודיו של טווח מסוים של טקסט בתור התחלה. כשהאודיו בטווח הטקסט הזה מתחיל לפעול, onRangeStart() מופעלת. האפליקציה יכולה להגיב לקריאה החוזרת הזו, למשל באמצעות הדגשת טווח הטקסט שקשור לביטוי.

לקבלת מידע נוסף על מעקב אחר התקדמות ההפעלה של המרת טקסט לדיבור (TTS) מנוע, ראו את הכיתה UtteranceProgressListener הפניה.

מערכת

מזהי StrictMode חדשים

ב-Android 8.0 (רמת API‏ 26) נוספו שלושה גלאי StrictMode חדשים שיעזרו לזהות באגים פוטנציאליים באפליקציה:

  • המכשיר detectUnbufferedIo() יזהה מתי האפליקציה קוראת או כותבת נתונים ללא אגירת נתונים. הדבר עלול להשפיע באופן משמעותי או של ביצועים.
  • הפעולה או הפעולות שיתבצעו על ידי detectContentUriWithoutPermission() לזהות מתי האפליקציה שוכחת בטעות להעניק הרשאות לאפליקציה אחרת, התחלת פעילות מחוץ לאפליקציה.
  • detectUntaggedSockets() יזהה מקרים שבהם האפליקציה מבצעת תעבורת נתונים ברשת בלי להשתמש ב-setThreadStatsTag(int) כדי לתייג את התנועה למטרות ניפוי באגים.

נתונים בקובץ שמור

ב-Android 8.0 (רמת API‏ 26) יש הנחיות והתנהגויות טובות יותר לגבי נתונים שנשמרו במטמון. כל אחד ניתנת כעת מכסת מקום בכונן לנתונים שנשמרו במטמון, כפי שהוחזר על ידי getCacheQuotaBytes(UUID)

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

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

  • אפשר להשתמש במשתנה StorageManager.setCacheBehaviorAtomic() כדי לציין שספרייה וכל התוכן שלה צריכים למחוק כיחידה אטומית אחת.
  • אפשר להשתמש ב-setCacheBehaviorTombstone(File, boolean) כדי לציין שבמקום למחוק קבצים בספרייה, צריך לקצר אותם כך שאורכם יהיה 0 בייטים, ולהשאיר את הקובץ הריק ללא שינוי.

לבסוף, כשצריך להקצות מקום בכונן לקבצים גדולים, כדאי לשקול להשתמש API של allocateBytes(FileDescriptor, long), שיימחקו באופן אוטומטי קבצים שנשמרו במטמון השייכים לאפליקציות אחרות (לפי הצורך) כדי לעמוד בבקשה שלכם. כדי להחליט אם במכשיר יש מספיק מקום בכונן כדי לשמור את הנתונים החדשים, להתקשר getAllocatableBytes(UUID) במקום להשתמש getUsableSpace(), מפני שהשיטה הראשונה תתייחס לכל נתונים שהמערכת מוכנה לנקות בשמכם.

דפים של ספקי תוכן

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

מידע מפורט על השינויים בספקי התוכן זמין במאמרים ContentProvider ו-ContentProviderClient.

בקשות לרענון תוכן

הכיתות ContentProvider ו-ContentResolver כוללות עכשיו את השיטה refresh(), כך שללקוחות קל יותר לדעת אם המידע שהם מבקשים עדכני.

אפשר להוסיף לוגיקה מותאמת אישית לרענון תוכן באמצעות הרחבה ContentProvider חשוב להגדיר שינוי מברירת המחדל של שיטה אחת (refresh()) להחזרה true, שמציין ללקוחות של הספק שניסיתם לעשות זאת כדי לרענן את הנתונים בעצמכם.

אפליקציית הלקוח יכולה לבקש תוכן מעודכן באופן מפורש על ידי קריאה לשיטה אחרת, שנקראת גם refresh(). כשקוראים לשיטה הזו, מעבירים את ה-URI של הנתונים שרוצים לרענן.

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

שיפורים ב-JobScheduler

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

העדכונים ל-JobScheduler כוללים:

  • עכשיו אפשר לשייך תור בעבודה למשימה מתוזמנת. כדי להוסיף פריט עבודה לתור של משימה, קוראים ל-JobScheduler.enqueue(). כשהמשימה פועלת, היא יכולה להסיר את העבודה שבהמתנה ולעבד אותה. הפונקציונליות הזו מטפלת ברבים מהתרחישים לדוגמה שבעבר היו דורשים הפעלה של שירות ברקע, במיוחד שירותים שמטמיעים את IntentService.
  • ב-Android Support Library 26.0.0 נוספה הכיתה JobIntentService, שמספקת את אותה פונקציונליות כמו IntentService, אבל משתמשת במשימות במקום בשירותים כשהיא פועלת ב-Android 8.0 (רמת API‏ 26) ואילך.
  • עכשיו אפשר להפעיל את הפונקציה JobInfo.Builder.setClipData() כדי לשייך ClipData למשימה. האפשרות הזו מאפשרת לשייך הרשאות URI למשימות, בדומה לאופן שבו אפשר להעביר את ההרשאות האלה אל Context.startService(). אפשר גם להשתמש בהרשאות URI עם כוונות (intents) בתורים של משימות.
  • עכשיו יש תמיכה במספר אילוצים חדשים במשימות מתוזמנות:
    JobInfo.isRequireStorageNotLow()
    המשימה לא פועלת אם נפח האחסון הזמין במכשיר קטן.
    JobInfo.isRequireBatteryNotLow()
    המשימה לא פועלת אם רמת הטעינה של הסוללה נמצאת בסף הקריטי או מתחתיו. זהו הסף שבו מוצגת במערכת תיבת הדו-שיח התראה על סוללה חלשה.
    NETWORK_TYPE_METERED
    למשימה נדרשת חיבור לרשת עם חיוב לפי שימוש בנתונים, כמו רוב חבילת הגלישה לתוכניות.

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

Android 8.0 (רמת API 26) מאפשרת לכם לספק מאגר נתונים בהתאמה אישית להעדפות שלכם, שיכול להיות שימושיות אם האפליקציה מאחסנת את ההעדפות בענן או במסד נתונים מקומי, או אם ההעדפות ספציפיות למכשיר. מידע נוסף על מטמיעים את מאגר הנתונים, מאגר נתונים בהתאמה אישית

שיפורי מדיה

מעצב נפח

יש כיתה חדשה מסוג VolumeShaper. כדאי להשתמש כדי לבצע מעברים אוטומטיים קצרים של עוצמת קול כמו עמעום הדרגתי, עמעום הדרגתי ועמעום הדרגתי. למידע נוסף, ראו שליטה במשרעת באמצעות Volume shaper למידע נוסף.

שיפורי מיקוד אודיו

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

מדדי מדיה

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

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

נגן מדיה

החל מ-Android 8.0 (רמת API 26), MediaPlayer יכול להפעיל מוגן באמצעות DRM חומר ומדיה מוצפנת ברמת HLS.

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

  • הפקודה SEEK_PREVIOUS_SYNC מעבירה את מיקום המדיה לפריים סנכרון (או מפתח) שמשויך למקור נתונים שנמצא ממש לפני המועד הנתון או באותו מועד.
  • SEEK_NEXT_SYNC מעביר את מיקום המדיה למסגרת סנכרון (או מפתח) שמשויכת עם מקור נתונים שנמצא מיד אחרי או בזמן הנתון.
  • SEEK_CLOSEST_SYNC מעביר את מיקום המדיה לפריים סנכרון (או מפתח) שמשויך למקור נתונים שנמצא הכי קרוב לשעה הנתונה או בשעה הנתונה.
  • SEEK_CLOSEST מעביר את מיקום המדיה למסגרת (לא בהכרח סנכרון) או מסגרת מפתח) המשויך למקור הנתונים הקרוב ביותר אליו, או בזמן הנתון.

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

MediaRecorder

  • MediaRecorder תומך כעת בפורמט MPEG2_TS השימושי תשודר:

    Kotlin

    mediaRecorder.setOutputFormat(MediaRecorder.OutputFormat.MPEG_2_TS)

    Java

    mediaRecorder.setOutputFormat(MediaRecorder.OutputFormat.MPEG_2_TS);

    ראו MediaRecorder.OutputFormat

  • עכשיו אפשר להשתמש ב-MediaMuxer כדי לטפל בכל מספר של שידורי אודיו ווידאו. הערוץ שלך כבר לא מוגבל לטראק אודיו אחד ו/או לטראק וידאו אחד. שימוש בפורמט addTrack() כדי לשלב כמה טראקים שרוצים.
  • MediaMuxer גם יכול להוסיף טראק אחד או יותר של מטא-נתונים שמכילים כל פריים בהגדרת המשתמש מידע. הפורמט של המטא-נתונים מוגדר על ידי האפליקציה. יש תמיכה בטראק המטא-נתונים רק בקונטיינרים מסוג MP4.

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

כשמוסיפים טראק של מטא-נתונים, פורמט ה-mime של הטראק חייב להתחיל בקידומת "application/ ". כתיבת מטא-נתונים זהה לכתיבת נתוני וידאו/אודיו, מלבד העובדה שהנתונים לא מגיעים מ-MediaCodec. במקום זאת, האפליקציה מעבירה ל-method‏ writeSampleData() את הערך ByteBuffer עם חותמת זמן משויכת. חותמת הזמן חייבת להיות באותו בסיס זמן כמו הטראקים של הסרטון והאודיו.

קובץ ה-MP4 שנוצר משתמש ב-TextMetaDataSampleEntry שמוגדר בקטע 12.3.3.2 של ה-ISOBMFF כדי לסמן את פורמט ה-MIME של המטא-נתונים. כשמשתמשים ב-MediaExtractor כדי לחלץ את הקובץ עם הטראק של המטא-נתונים, פורמט ה-MIME של המטא-נתונים ייחלץ אל MediaFormat.

גישה משופרת לקובצי מדיה

Storage Access Framework‏ (SAF) מאפשר לאפליקציות לחשוף DocumentsProvider בהתאמה אישית, שיכול לספק גישה לקבצים במקור נתונים לאפליקציות אחרות. למעשה, ספק מסמכים יכול אפילו לספק גישה לקבצים שנמצאים באחסון רשת או שמשתמשים בפרוטוקול כמו Media Transfer Protocol (MTP).

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

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

כדי להתמודד עם כל האתגרים האלה, בגרסה 8.0 של Android שיפורה מערכת ה-Storage Access Framework.

ספקי מסמכים בהתאמה אישית

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

כדי להשתמש בתכונה הזו, צריך לקרוא ל-method החדש StorageManager.openProxyFileDescriptor(). ה-method openProxyFileDescriptor() מקבלת אובייקט ProxyFileDescriptorCallback כקריאה חוזרת (callback). SAF מפעיל את הפונקציה החוזרת בכל פעם שאפליקציית לקוח מבצעת פעולות קובץ על מתאר הקובץ שהוחזר מספק המסמכים.

גישה ישירה למסמכים

החל מגרסה 8.0 של Android‏ (רמת API 26), אפשר להשתמש ב-method‏ getDocumentUri() כדי לקבל URI שמפנה לאותו מסמך כמו mediaUri שצוין. עם זאת, מאחר שה-URI המוחזר מגובה על ידי DocumentsProvider, למנהלי אוסף מדיה יש גישה את המסמך ישירות, בלי שתצטרכו לחצות עצים של ספריות עם הרשאות בהיקף רחב. כתוצאה מכך, מנהלי המדיה יכולים לבצע פעולות קובץ במסמך במהירות רבה יותר.

זהירות: השיטה getDocumentUri() מאתרת רק קובצי מדיה, היא לא מעניקה לאפליקציות הרשאה לגשת לקבצים האלה. מידע נוסף על דרכים לקבלת גישה הרשאה לקובצי מדיה, ראה את מאמרי העזרה.

נתיבים למסמכים

כשמשתמשים ב-Storage Access Framework ב-Android 8.0 (רמת API‏ 26), אפשר להשתמש בשיטה findDocumentPath(), שזמינה גם בכיתה DocumentsContract וגם בכיתה DocumentsProvider, כדי לקבוע את הנתיב מהשורש של מערכת קבצים לפי מזהה המסמך. ה-method מחזירה את הנתיב ב- אובייקט DocumentsContract.Path. במקרים שבהם קובץ יש כמה נתיבים מוגדרים לאותו מסמך, השיטה מחזירה את הנתיב שבו משתמשים בדרך כלל כדי להגיע למסמך עם המזהה הנתון.

הפונקציונליות הזו שימושית במיוחד בתרחישים הבאים:

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

הערה: אם לאפליקציה יש הרשאת גישה רק לחלק מהמסמכים בנתיב, ערך ההחזרה של findDocumentPath() יכלול רק את התיקיות והמסמכים שהאפליקציה יכולה לגשת אליהם.

מעקב אחרי הפעלת האודיו

שירות המערכת AudioManager שומר רשימה של אובייקטים פעילים מסוג AudioPlaybackConfiguration, שכל אחד מהם מכיל מידע על סשן הפעלת אודיו ספציפי. כדי לאחזר את קבוצת ההגדרות האישיות הפעילות, האפליקציה יכולה להפעיל את getActivePlaybackConfigurations().

החל מגרסה 8.0 של Android (רמת API 26), אפשר לרשום קריאה חוזרת (callback) שתודיע לאפליקציה כשאובייקט AudioPlaybackConfiguration אחד או יותר ישתנה. כדי לעשות את זה, קוראים לפונקציה registerAudioPlaybackCallback(), מעבירים במופע של AudioManager.AudioPlaybackCallback. המחלקה AudioManager.AudioPlaybackCallback מכילה את השיטה onPlaybackConfigChanged(), שהמערכת קוראת לה כשיש שינוי בהגדרות של הפעלת האודיו.

קישוריות

עם חיבור ל-Wi-Fi

ב-Android 8.0 (רמת API‏ 26) נוספה תמיכה ב-Wi-Fi Aware, שמבוסס על המפרט של Neighbor Awareness Networking‏ (NAN). במכשירים עם ציוד ל-Wi-Fi Aware, אפליקציות ומכשירים בקרבת מקום יכולים לגלות ולתקשר בחיבור Wi-Fi ללא נקודת גישה לאינטרנט. אנחנו עובדים עם שותפי החומרה שלנו כדי להוסיף את הטכנולוגיה של Wi-Fi Aware למכשירים בהקדם האפשרי. עבור מידע על שילוב Wi-Fi Aware באפליקציה שלך זמין במאמר Wi-Fi Aware.

‫Bluetooth

גרסת Android 8.0 (רמת API 26) מעשירה את התמיכה ב-Bluetooth של הפלטפורמה על ידי הוספת הקוד הבא תכונות:

  • תמיכה בתקן AVRCP 1.4, שמאפשר גלישה בספריית השירים.
  • תמיכה בתקן Bluetooth עם צריכת אנרגיה נמוכה (BLE) 5.0.
  • שילוב של קודק LDAC של Sony בסטאק של Bluetooth.

התאמת מכשיר נלווה

ב-Android 8.0 (רמת API 26) יש ממשקי API שמאפשרים להתאים אישית את תיבת הדו-שיח של בקשת ההתאמה כשמנסים להתאים מכשירי לוויין באמצעות Bluetooth,‏ BLE ו-Wi-Fi. מידע נוסף זמין במאמר הבא: מכשיר נלווה התאמה.

למידע נוסף על השימוש ב-Bluetooth ב-Android, אפשר לעיין במאמר מדריך ל-Bluetooth. עבור לשינויים ב-Bluetooth שהם ספציפיים ל-Android 8.0 (רמת API 26), כדאי לעיין הקטע Bluetooth ב- הדף שינויים בהתנהגות ב-Android 8.0.

שיתוף

שיתוף חכם

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

השיתוף החכם פועל בסוגי תוכן שהם לא image, כמו audio, video, text, URL, וכו'

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

Kotlin

val annotations: ArrayList<String> = arrayListOf(
        "topic1",
        "topic2",
        "topic3"
)

intent.putStringArrayListExtra(
        Intent.EXTRA_CONTENT_ANNOTATIONS,
        annotations
)

Java

ArrayList<String> annotations = new ArrayList<>();

annotations.add("topic1");
annotations.add("topic2");
annotations.add("topic3");

intent.putStringArrayListExtra(
    Intent.EXTRA_CONTENT_ANNOTATIONS,
    annotations
);

מידע מפורט על הערות לשיתוף חכם זמין במאמר EXTRA_CONTENT_ANNOTATIONS

מסווג טקסט

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

נגישות

ב-Android 8.0 (רמת API‏ 26) יש תמיכה בכמה תכונות נגישות חדשות למפתחים שיוצרים שירותי נגישות משלהם:

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

אבטחה ופרטיות

הרשאות

ב-Android 8.0 (רמת API‏ 26) נוספו כמה הרשאות חדשות שקשורות לטלפוניה:

שתי ההרשאות האלה מסווגות כמסוכנות, ושתיהן נכללות בקבוצת ההרשאות PHONE.

ממשקי API חדשים לגישה לחשבון ו-Discovery

ב-Android 8.0 (רמת API‏ 26) יש כמה שיפורים לגבי האופן שבו אפליקציות מקבלות גישה לחשבונות משתמשים. לגבי החשבונות שהם מנהלים, מאמתים יכולים להשתמש במדיניות שלהם כדי להחליט אם להסתיר חשבונות מאפליקציה או לחשוף חשבונות לאפליקציה. מערכת Android עוקבת אחרי אפליקציות שיש להן גישה לחשבון מסוים.

בגרסאות קודמות של Android, אפליקציות שרצינו לעקוב אחרי רשימת חשבונות המשתמשים שלהן היו צריכות לקבל עדכונים לגבי כל החשבונות, כולל חשבונות מסוגים שונים. ב-Android 8.0 נוספה השיטה addOnAccountsUpdatedListener(android.accounts.OnAccountsUpdateListener, android.os.Handler, boolean, java.lang.String[]), שמאפשרת לאפליקציות לציין רשימה של סוגי חשבונות שעבורם צריך לקבל עדכונים לגבי שינויים בחשבון.

שינויים ב-API

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

ב-Android 8.0 (רמת API 26) נוספו שני ערכים מיוחדים של שם החבילה כדי לציין רמות חשיפה לאפליקציות שלא הוגדרו באמצעות השיטה setAccountVisibility(android.accounts.Account, java.lang.String, int). ערך החשיפה PACKAGE_NAME_KEY_LEGACY_VISIBLE חל על אפליקציות שיש להן את ההרשאה GET_ACCOUNTS, שמטרגטות גרסאות של Android שקדמו ל-Android 8.0 או שהחתימות שלהן תואמות למאמת שמטרגט כל גרסה של Android. PACKAGE_NAME_KEY_LEGACY_NOT_VISIBLE מספק ערך ברירת מחדל של חשיפה לאפליקציות שלא הוגדרו בעבר ולא חלה עליהן ההגדרה PACKAGE_NAME_KEY_LEGACY_VISIBLE.

למידע נוסף על ממשקי ה-API החדשים לגישה לחשבון ולגילוי, אפשר לעיין ב הפניה ל- AccountManager והקבוצה OnAccountsUpdateListener.

בדיקה

בדיקת אינסטרומנטציה

ב-Android 8.0 (רמת API‏ 26) יש תמיכה נוספת בבדיקות של כלי המדידה באפליקציה.

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

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

כדי להגדיר אינסטרומנטציה לתהליך שאינו ברירת מחדל, יש לעבור למניפסט ואז לקובץ הרצוי רכיב <instrumentation>. מוסיפים את המאפיין android:targetProcess ומגדירים את הערך שלו לאחד מהערכים הבאים:

  • השם של תהליך מסוים.
  • רשימה של שמות תהליך שמופרדים בפסיקים.
  • תו כללי לחיפוש ("*"), שמאפשר להפעיל את המכשיר בכל תהליך מופעל שמריץ קוד בחבילה שצוינה במאפיין android:targetPackage.

בזמן שבדיקת האינסטרומנטציה מתבצעת, אפשר לבדוק איזה תהליך הוא בודק באמצעות הפעלה של getProcessName().

דיווח על התוצאות במהלך בדיקה

עכשיו אפשר לדווח על תוצאות בזמן שבדיקת האינסטרומנטציה מתבצעת, ולא לאחר מכן, בהתקשרות אל addResults().

כוונות מדומה לצורך בדיקות

כדי שיהיה קל יותר ליצור בדיקות ממשק משתמש מבודדות ועצמאיות לאפליקציות פעילויות, Android 8.0 (רמת API 26) מציגה אמצעי תשלום אחד (onStartActivity()). כדי לטפל בכוונה מסוימת שכיתה הבדיקה מפעילה, מבטלים את הגדרת ברירת המחדל של השיטה הזו בתת-כיתה בהתאמה אישית של הכיתה Instrumentation.ActivityMonitor.

כשכיתת הבדיקה מפעילה את Intent, השיטה מחזירה stub אובייקט Instrumentation.ActivityResult במקום להפעיל את הכוונה עצמה. אם תשתמשו בהדמיה של הכוונה המדומה בבדיקות שלכם, תוכלו להתמקד לגבי האופן שבו הפעילות שלכם מתכוננת ומטפלת בכוונתכם להעביר פעילות אחרת לגמרי או לאפליקציה אחרת לגמרי.

זמן ריצה כלים

אופטימיזציות של פלטפורמה

ב-Android 8.0 (רמת API‏ 26) יש אופטימיזציות של זמן ריצה ואופטימיזציות אחרות בפלטפורמה, שמניבות מספר שיפורים בביצועים. האופטימיזציות האלה כוללות איסוף אשפה בעקבות דחיסה בו-זמנית, לשימוש יעיל יותר בזיכרון ובסביבת קוד.

האופטימיזציות האלה מאפשרות זמן הפעלה מהיר יותר, וגם ביצועים טובים יותר במערכת ההפעלה ובאפליקציות.

עודכנה תמיכה בשפת Java

במערכת Android 8.0 (רמת API 26) נוספת תמיכה בכמה ממשקי API נוספים של OpenJDK Java:

מידע נוסף על הכיתות והשיטות בחבילות החדשות האלה זמין במסמכי העזרה של ה-API.

אם אתם רוצים להשתמש בתכונות השפה של Java 8 ב-Android Studio, עליכם להוריד את גרסת התצוגה המקדימה האחרונה.

ממשקי API מעודכנים של Android Framework של ICU4J

ב-Android 8.0 (רמת API 26) יש הרחבה של ממשקי ה-API של Android Framework של ICU4J – שהם קבוצת משנה של ממשקי ה-API של ICU4J – למפתחי אפליקציות, לשימוש בחבילה android.icu. ממשקי ה-API האלה משתמשים בנתוני התאמה לשוק המקומי קיימת במכשיר, כך שתוכל לצמצם את טביעת הרגל הפחמנית שלך על ידי אי הידור ספריות ICU4J ב-APK.

טבלה 1. גרסאות ICU, CLDR ו-Unicode שבהן נעשה שימוש ב-Android.

רמת ה-API ב-Android גרסת ה-ICU גרסת CLDR גרסת Unicode
Android 7.0‏ (רמת API 24), Android 7.1‏ (רמת API 25) 56 28 8.0
Android 8.0 (רמת API 26) 58.2 30.0.3 9.0

אפשר לקרוא מידע נוסף על התאמה לשוק הבינלאומי ב-Android, כולל לתמיכת ICU4J: התאמה לשוק הבינלאומי ב-Android

Android Enterprise

הוספנו תכונות וממשקי API חדשים לארגונים למכשירים עם Android 8.0 (רמת API‏ 26). בין התכונות המרכזיות:

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

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