נתוני הגרסה של Android 9

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

Build

תמונת מערכת גנרית (GSI)

קובץ אימג' מערכת גנרי (GSI) הוא קובץ אימג' מערכת עם הגדרות מותאמות למכשירי Android. Generic System Image‏ (GSI) כולל פרטים על ההבדלים בין קובצי GSI למכשירים שמופעלת בהם Android 9 לבין קובצי GSI למכשירים שמשודרגים ל-Android 9.

ארכיטקטורה

שכבת הפשטת חומרה (HAL)

תאימות לאחור של מסגרת HIDL

אימות התאימות לאחור של מסגרת HIDL היא שיטה לאימות התאימות לאחור של המסגרת.

ממשקי HAL זמינים באופן דינמי

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

HIDL

HIDL MemoryBlock

HIDL MemoryBlock הוא שכבה מופשט שנבנה על hidl_memory,‏ HIDL @1.0::IAllocator ו-HIDL @1.0::IMapper. הוא מיועד לשירותי HIDL שיש להם כמה בלוקים של זיכרון שמשתמשים באותו אשכול זיכרון.

שכבות-על של פירוט מבנה המכשיר (DT)

שכבות-על דחוסות

ב-Android 9 ואילך יש תמיכה בשכבות-על דחוסות בתמונה של שכבת-העל של blob של עץ המכשיר (DTBO) כשמשתמשים בגרסה 1 של הכותרת של טבלת עץ המכשיר.

עדכונים ב-DTO

ב-Android 9 ואילך, מערך האתחול צריך להעביר את ה-blob המאוחד של עץ המכשיר לליבה לפני שינוי המאפיינים שמוגדרים בשכבות-העל של עץ המכשיר (DTO).

ניהול גרסאות של כותרות של קובצי אימג' של DTBO

Android מגרסה 9 ואילך כולל שדה גרסה בכותרת של קובץ האימג' של DTBO.

אימות DTBO

כדי להשתמש ב-Android מגרסה 9 ואילך, נדרש מחיצה מסוג DTBO. כדי להוסיף צמתים או לבצע שינויים בנכסים ב-DT של SoC, מנהל האתחול צריך להוסיף באופן דינמי DT ספציפי למכשיר מעל ל-DT של SoC. למידע נוסף, ראו הדרכה ל-Compiling & Verifying.

תאימות לליבה

ב-Android מגרסה 9 ואילך יש דרישות שמשפיעות על הליבה, על הממשקים שלה ועל השימוש ב-DTBO. מידע נוסף זמין בדפים הבאים:

NDK של הספק

שינויים בעיצוב

מידע על השינויים בעיצוב של VNDK ב-Android מגרסה 9 ואילך זמין בדפים הבאים:

בדיקת ABI

בדף ABI Stability מתואר הכלי לבדיקת ממשק הבינארי של האפליקציה (ABI), שמבטיח שהשינויים שבוצעו בספריות VNDK יישמרו את תאימות ה-ABI.

קובצי snapshot של VNDK

קובץ אימג' של מערכת יכול להשתמש בקובצי snapshot של VNDK כדי לספק את ספריות VNDK הנכונות לקובצי אימג' של ספקים, גם אם קובצי האימג' של המערכת ושל הספקים נוצרו מגרסאות שונות של Android.

אובייקט של ממשק הספק (אובייקט VINTF)

בדפים הבאים בקטע Vendor Interface Object מתוארים עדכונים ב-Android מגרסה 9 ואילך:

לוח הזמנים להוצאה משימוש של HIDL

בדפים הבאים מוסבר איך Android מפסיקה את השימוש ב-HIDL HALs ומסירה אותם:

תוכנת אתחול

מחיצות מוצרים

ב-Android מגרסה 9 ואילך יש תמיכה ביצירת מחיצות /product באמצעות מערכת ה-build של Android. בעבר, ב-Android 8.x נאכף ההפרדה בין רכיבים ספציפיים למערכת על שבב (SoC) מהמחיצה /system למחיצה /vendor, בלי להקצות מקום לרכיבים ספציפיים ליצרני ציוד מקורי (OEM) שנוצרו ממערכת ה-build של Android.

תאימות של הסיבה לטעינה

בדף Canonical Boot Reason מתוארים השינויים במפרט של סיבות האתחול של מנהל האתחול ב-Android מגרסה 9 ואילך.

מערכת כ-root

כל המכשירים שמושקעים עם Android מגרסה 9 ואילך חייבים להשתמש ב-system-as-root, שממזג את ramdisk.img עם system.img (נקרא גם no-ramdisk), שממוטב בתור rootfs.

ניהול גרסאות של כותרות של קובצי אימג' לאתחול

ב-Android 9 ואילך, הכותרת של קובץ האימג' לאתחול מכילה שדה לציון גרסת הכותרת. מנהל האתחול צריך לבדוק את שדה הגרסה הזה ולנתח את הכותרת בהתאם.

DTBO בשחזור

כדי למנוע כשלים בעדכון OTA עקב אי-התאמות בין קובץ האימג' לשחזור לבין המחיצה DTBO במכשירים שאינם A/B, קובץ האימג' לשחזור חייב להכיל מידע מקובץ האימג' של DTBO.

תצוגה

מגרעות במסך

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

הצעות לסיבוב

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

מעברים מסונכרנים בין אפליקציות

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

סיווג טקסט (לשעבר TEXTCLASSIFIER)

ב-Android מגרסה 9 ואילך יש שירות סיווג טקסט, שהיא הדרך המומלצת להטמיע סיווג טקסט, והטמעת שירות שמוגדרת כברירת מחדל.

צבע בטווח רחב

ב-Android 9 ואילך יש תמיכה בצבעים רחבי-טווח, כולל:

  • טווח דינמי גבוה (HDR)
  • עיבוד תוכן במרחב הצבעים BT2020, אבל לא כמרחב נתונים יעד

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

תאימות

מסמך הגדרת התאימות ל-Android

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

הגדרות

ווידג'טים משופרים של אפליקציות

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

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

חשוב לדעת שהתכונה פועלת מקצה לקצה רק כשממשקי האפליקציות לניהול האפליקציות מטמיעים אותה כמצופה. AOSP כולל הטמעה לדוגמה. הקוד לדוגמה מופיע ב-AOSP Change-Id Iccd6f965fa3d61992244a365efc242122292c0ca.

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

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

קוד המקור של ההתראות על שינוי סטטוס המכשיר נמצא במיקומים הבאים בקטע platform/frameworks/base:

  • api/system-current.txt
  • core/java/android/content/Intent.java
  • core/res/AndroidManifest.xml
  • services/core/java/com/android/server/am/ActivityManagerService.java

ארכיטקטורת מידע

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

בדיקות

Atest

כלי שורת הפקודה Atest מאפשר ליצור, להתקין ולהריץ בדיקות Android באופן מקומי, ומאיץ מאוד את ההרצות החוזרות של הבדיקות בלי צורך בידע לגבי אפשרויות שורת הפקודה של ערכת הבדיקות של Trade Federation.

חבילה לבדיקות תאימות (CTS)

הורדות של CTS

חבילות של חבילה לבדיקות תאימות (CTS) שתומכות ב-Android 9 זמינות בדף CTS Downloads. אפשר לסנכרן את קוד המקור של הבדיקות הכלולות עם התג android-cts-9.0_r1 בעץ הקוד הפתוח.

אפשרויות CTS

ב-Android 9, נוספו ל-CTS v2 הפקודה והארגומנט הבאים:

  • run retry מנסה שוב את כל הבדיקות שנכשלו או שלא בוצעו מהסשנים הקודמים.
  • ‘--shard-count מפצל את הפעלת ה-CTS למספר נתחים עצמאיים, כדי להריץ אותה במספר מכשירים במקביל.

בנוסף, הפקודה --retry-type שלא תועדה בעבר נוספה לאותה הפנייה לפקודות במסוף של CTS v2.

שירות רכיב מאובטח (SE)

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

תיבת מיזוג נתונים של חיישנים

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

מערכת ITS-in-a-box עם שדה ראייה רחב

Wide field of view ITS-in-a-box היא מערכת אוטומטית שנועדה לבדוק מערכות מצלמה עם שדה ראייה רחב (WFoV) ועם שדה ראייה רגיל (RFoV) ב-ITS של המצלמה.

חבילה לבדיקת ספקים

ארכיטקטורת Host Controller

ארכיטקטורת הבקר המארח של Vendor Test Suite ‏ (VTS) היא הארכיטקטורה של מסגרת הבדיקה של VTS שמשולבת עם שירות הענן להרצת הבדיקות.

בדיקת HAL עם התמקדות בשם השירות

בדיקת HAL שמודעת לשם השירות ב-VTS תומכת בהצגת שם השירות של מכונה נתונה של HAL על סמך המכשיר שבו פועלות בדיקות VTS.

בדיקת יכולת הבדיקה של HAL

בדיקת יכולת הבדיקה של HAL ב-VTS כוללת שיטה בסביבת זמן הריצה שמשתמשת בהגדרות המכשיר כדי לזהות אילו בדיקות VTS צריך לדלג עליהן עבור יעד המכשיר הזה.

תשתית לבדיקות אוטומטיות

תשתית הבדיקה האוטומטית היא תשתית VTS לבדיקות אוטומטיות של VTS,‏ CTS או בדיקות אחרות במכשירי שותפים שפועלת בהם תמונת המערכת הגנרית (GSI) של AOSP.

ניפוי באגים

טלמטריה מתקדמת

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

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

פרטים נוספים זמינים במאמר frameworks/base/cmds/statsd/.

תכונות אבטחה

חתימה על אפליקציות

סכמת החתימה של APK בגרסה 3 תומכת בסיבוב מפתחות של APK.

תמיכה בנתונים ביומטריים

מערכת Android 9 כוללת את הכיתה הציבורית BiometricPrompt, שבאמצעותה אפליקציות יכולות לשלב תמיכה באימות ביומטרי באופן בלתי תלוי במכשיר ובשיטת האימות. מידע נוסף על שילוב של BiometricPrompt בסטאק הביומטרי זמין במאמר ביומטריה.

ניתוח דינמי

ב-Android 9 יש תמיכה בכלים נוספים לניתוח ולצמצום של נקודות חולשה.

תקינות של בקרת זרימה (CFI)

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

Kernel CFI

בנוסף ל-CFI במערכת, שמופעל כברירת מחדל, ב-Android מגרסה 9 ואילך יש תמיכה בשלמות בקרת תהליך הליבה (CFI).

הצפנה

הצפנה מבוססת-קבצים

הצפנה מבוססת-קבצים (FBE) עודכנה כך שתעבוד עם אחסון שניתן לאימוץ. במכשירים חדשים כדאי להשתמש בהצפנה מבוססת-קובץ במקום בהצפנה מלאה של הדיסק.

הצפנת מטא-נתונים

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

מאגר מפתחות

מערכת Android מגרסה 9 ואילך כוללת את Keymaster 4, שמכיל את התכונות האלה.

StrongBox

ב-Android 9 ואילך יש תמיכה במפתחות של Android Keystore שנשמרים ומשמשים ב-CPU נפרד פיזית שנועד במיוחד לאפליקציות עם אבטחה גבוהה, כמו רכיב מאובטח (SE) מוטמע. StrongBox Keymaster הוא הטמעה של HAL של Keymaster בחומרה מאובטחת נפרדת. ב-StrongBox יש:

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

ייבוא מפתחות מאובטח

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

תמיכה ב-3DES

‏Keymaster 4 כולל 3DES לתאימות למערכות מדור קודם שמשתמשות ב-3DES.

קישור לגרסה

כדי לתמוך במבנה המודולרי של Treble ולבטל את הקישור של system.img ל-boot.img, ב-Keymaster 4 השתנו המודל של קישור גרסאות המפתחות כך שיכלול רמות תיקון נפרדות לכל מחיצה. כך אפשר לעדכן כל מחיצה בנפרד ועדיין לספק הגנה מפני חזרה לאחור.

Android Protected Confirmation API

במכשירים נתמכים שמגיעים עם Android 9 מותקנת, למפתחים יש אפשרות להשתמש ב-Android Protected Confirmation API. באמצעות ה-API הזה, אפליקציות יכולות להשתמש במכונה של ConfirmationPrompt כדי להציג למשתמש הנחיה לאשר הצהרה קצרה. ההצהרה הזו מאפשרת לאפליקציה לאשר מחדש שהמשתמש רוצה להשלים עסקה עם מידע אישי רגיש, כמו ביצוע תשלום.

SELinux

ארגז חול של SELinux לכל אפליקציה

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

שינויים ב-SELinux ב-Treble

עדכונים ל-Treble SELinux ב-Android 9 ואילך מתועדים בכמה דפים בקטע SELinux.

Vendor init

Vendor init סוגר את החור בממשק Treble שמפריד בין המערכת לבין הספק באמצעות דומיין SELinux נפרד להרצת פקודות /vendor עם הרשאות ספציפיות לספק.

מאפייני מערכת

ב-Android 9 יש הגבלה על מאפייני המערכת, כך שלא יתבצע שיתוף מיותר שלהם בין המחיצות system ו-vendor, ויש שיטה להבטחת עקביות בין מאפייני המערכת המשותפים.

בדיקות של מאפייני SELinux

Android 9 כולל בדיקות חדשות בזמן ה-build שמבטיחות שלכל הקבצים במיקומים ספציפיים יש את המאפיינים המתאימים. לדוגמה, לכל הקבצים ב-sysfs יש את המאפיין הנדרש sysfs_type.

אודיו

אפקטים קוליים ברזולוציה גבוהה

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

מצלמה

מצלמות USB חיצוניות

ב-Android 9 ואילך יש תמיכה בשימוש במצלמות USB מסוג plug-and-play (כלומר מצלמות אינטרנט) באמצעות Android Camera2 API הסטנדרטי וממשק ה-HIDL של המצלמה.

מעקב אחר תנועה

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

תמיכה במספר מצלמות

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

פרמטרים של סשנים

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

מאגר של יוצר יחיד ומספר צרכנים

Single producer, multiple consumer camera buffer transport היא קבוצה של שיטות שמאפשרות ללקוחות מצלמה להוסיף ולהסיר משטחי פלט באופן דינמי בזמן שסשן הצילום פעיל והסטרימינג של המצלמה נמשך.

קישוריות

שיחות והודעות

הטמעת חבילות גלישה

ב-Android מגרסה 9 ואילך יש תמיכה משופרת לספקים שמטמיעים חבילות גלישה באמצעות ממשקי ה-API של SubscriptionPlan.

אפליקציות צד שלישי לשיחות

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

ספק

זיהוי הספק

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

eSIM

כרטיס SIM מוטמע (eSIM או eUICC) הוא הטכנולוגיה העדכנית ביותר שמאפשרת למשתמשי טלפונים ניידים להוריד פרופיל ספק ולהפעיל את השירות של הספק בלי כרטיס SIM פיזי. ב-Android מגרסה 9 ואילך, מסגרת Android מספקת ממשקי API רגילים לגישה ל-eSIM ולניהול פרופילי מינויים ב-eSIM. מידע נוסף זמין במאמרים הבאים:

תמיכה בכרטיסי SIM מרובים להגדרות IMS

ב-Android מגרסה 9 ואילך יש שיפורים בהגדרות המשתמש של תת-מערכת מולטימדיה ב-IP‏ (IMS). אתם יכולים להגדיר את השירותים Voice over LTE‏ (VoLTE), שיחות וידאו ושיחות Wi-Fi בנפרד לכל מינוי, במקום לשתף את ההגדרות האלה בין כל המינויים.

שידורים של מצב כרטיס ה-SIM

ב-Android מגרסה 9 ואילך, האירוע Intent.ACTION_SIM_STATE_CHANGED הוצא משימוש, והוספו שני שידורים נפרדים למצב הכרטיס ולמצב האפליקציה של הכרטיס: TelephonyManager.ACTION_SIM_CARD_STATE_CHANGED ו-TelephonyManager.ACTION_SIM_APPLICATION_STATE_CHANGED.

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

שתי השידורים החדשים הם @SystemApis והם לא מוצמדים. רק מכשירים עם ההרשאה READ_PRIVILEGED_PHONE_STATE יכולים לקבל את השידור.

כשמוסיפים את המכשיר ל-Google Home, המערכת לא משדרת מחדש את הכוונות. מקלטים שמסתמכים על שידורים שנשלחו לפני ביטול הנעילה חייבים להשתמש ב-directBootAware, או לבצע שאילתה לגבי המצב אחרי ביטול הנעילה על ידי המשתמש. אפשר לשלוח שאילתות לגבי המצבים באמצעות ממשקי ה-API המתאימים ב-TelephonyManager, ‏ getSimCardState() ו-getSimApplicationState().

Wi-Fi

Wi-Fi של ספק

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

רנדומיזציה של כתובות MAC

רנדומיזציה של כתובות MAC מאפשרת למכשירים להשתמש בכתובות MAC אקראיות כשהם מחפשים רשתות חדשות, אם הם לא משויכים כרגע לרשת. ב-Android מגרסה 9 ואילך, אפשר להפעיל אפשרות למפתחים כדי לגרום למכשיר להשתמש בכתובת MAC אקראית בהתחברות לרשת Wi-Fi.

הפעל Wi‑Fi באופן אוטומטי

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

זמן הלוך ושוב ב-Wi-Fi

זמן הנסיעה הלוך ושוב (RTT) ב-Wi-Fi מאפשר למכשירים למדוד את המרחק למכשירים תומכים אחרים, בין אם מדובר בנקודות גישה (AP) או ברשתות Wi-Fi Aware (אם יש תמיכה ב-Wi-Fi Aware במכשיר). התכונה הזו מבוססת על פרוטוקול IEEE 802.11mc ומאפשרת לאפליקציות להשתמש ברמת דיוק מיקום ובזיהוי מיקום משופרים.

שיפורים בסימון של רשתות Wi-Fi

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

בודקים ומכווננים את ערכי ה-RSSI במקורות המידע של config.xml, במיוחד את הערכים הבאים:

  • config_wifi_framework_wifi_score_bad_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_bad_rssi_threshold_24GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_24GHz

בו-זמניות של STA/AP ב-Wi-Fi

ביצוע בו-זמנית של STA/AP ב-Wi-Fi היא היכולת של מכשירים לפעול במצבים של תחנה (STA) ונקודת גישה (AP) בו-זמנית. במכשירים שתומכים ב-Wi-Fi בו-זמנית בשני תדרים (DBS), היכולות האלה מאפשרות, למשל, לא להפריע ל-Wi-Fi של STA כשמשתמש רוצה להפעיל נקודה לשיתוף אינטרנט (SoftAP).

שיפורים ב-WiFiStateMachine

WifiStateMachine היא המחלקה הראשית שמשמשת לניהול הפעילות ב-Wi-Fi, לתיאום הקלט של המשתמש (מצבי הפעלה: נקודה לשיתוף אינטרנט, סריקה, חיבור או כבוי) ולשליטה בפעולות של רשתות Wi-Fi (כמו סריקה או חיבור).

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

באופן כללי,WifiStateMachine מאפשר ל-Wi-Fi להיות באחד מארבעה מצבים:

  • מצב לקוח (אפשר להתחבר ולסרוק)
  • מצב סריקה בלבד
  • מצב SoftAP (נקודת Wi-Fi לשיתוף אינטרנט)
  • מושבת (ה-Wi-Fi כבוי לגמרי)

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

עדכונים של הרשאות Wi-Fi

ב-Android מגרסה 9 ואילך, הרשאת האפליקציה CHANGE_WIFI_STATE מופעלת כברירת מחדל. אפשר להשבית את ההרשאה לכל אפליקציה בדף ההגדרות, בקטע הגדרות > אפליקציות והתראות > גישה מיוחדת לאפליקציות > בקרת Wi-Fi.

האפליקציות צריכות להיות מסוגלות לטפל במקרים שבהם ההרשאה CHANGE_WIFI_STATE לא ניתנת.

כדי לאמת את ההתנהגות הזו, צריך להריץ את הבדיקות הידניות ואת הבדיקות של roboelectric.

לבדיקות ידניות:

  1. עוברים אל הגדרות > אפליקציות והתראות > אפליקציות עם הרשאות גישה מיוחדות > שליטה ב-Wi-Fi.
  2. בוחרים את ההרשאה לאפליקציה ומשביתים אותה.
  3. מוודאים שהאפליקציה יכולה לטפל בתרחיש שבו ההרשאה CHANGE_WIFI_STATE לא ניתנת.

הפסקת השימוש ב-WPS

עקב בעיות אבטחה, ההגדרה המוגנת של Wi-Fi‏ (WPS) ב-WiFiManager הוצאה משימוש ומושבתת ב-Android מגרסה 9 ואילך. עם זאת, WiFiDirect עדיין משתמש ב-WPS ב-supplicant של WPA.

גרפיקה

הטמעה

Vulkan 1.1 API

ב-Android 9 ואילך יש תמיכה בהטמעה של Vulkan 1.1 graphics API.

הכלי WinScope למעקב אחר מעברים בין חלונות

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

קוד המקור של הכלי WinScope נמצא בכתובת platform/development/tools/winscope.

אינטראקציה

אודיו לרכב

Automotive Audio מתאר את ארכיטקטורת האודיו להטמעות של Android שקשורות לכלי רכב.

ה-HAL של Neural Networks (NN) מגדיר הפשטה של המאיצים השונים. מנהלי ההתקנים של המאיצים האלה חייבים לעמוד בתקן ה-HAL הזה.

Vehicle HAL

בקטע מאפייני הרכב מתוארים שינויים בממשק HAL של הרכב.

בחירת לוויין GNSS

כשעובדים עם ממשקי HAL חדשים של מערכת ניווט לוויינית גלובלית (GNSS) (גרסה 1.1 ואילך), Android Framework עוקב אחרי הגדרות Android. השותפים יכולים לשנות את ההגדרות דרך Google Play Services או דרך עדכוני מערכת אחרים. ההגדרות האלה מאפשרות ל-HAL של GNSS לדעת אם לא כדאי להשתמש בלווייני GNSS מסוימים. האפשרות הזו יכולה להיות שימושית במקרה של שגיאות מתמשכות בתקן GNSS או בקונסטלציה, או כדי להגיב מהר יותר לבעיות בהטמעת GNSS HAL שעשויות להתרחש כשמשתמשים בקונסטלציות שונות באמצעות מערכות זמן שונות ואירועים חיצוניים, כמו מעבר לשנייה מעוברת, יום או שבוע.

דגם החומרה של GNSS

ב-Android 9, ‏GNSS HAL בגרסה 1.1 ואילך יכול להעביר מידע על ממשק ה-API של החומרה לפלטפורמה. הפלטפורמה צריכה להטמיע את הממשק IGnssCallback ולהעביר אחיזה ל-HAL. ה-HAL של GNSS מעביר את פרטי דגם החומרה באמצעות השיטה LocationManager#getGnssHardwareModelName(). יצרני המכשירים צריכים לעבוד עם ספקי ה-HAL של GNSS כדי לספק את המידע הזה, אם הדבר אפשרי.

הרשאות

הגדרת עדכונים של בקרת גישה שרירותית

הגדרת בקרת גישה שרירותית (DAC) מכילה עדכונים למנגנון של מזהי Android‏ (AIDs) להרחבת היכולות של מערכת הקבצים.

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

ב-Android 9 ואילך, אם יש הרשאות שצריך לדחות, צריך לערוך את קובץ ה-XML כך שייעשה בו שימוש בתג deny-permission במקום בתג permission ששימש בגרסאות קודמות.

נתונים

שיפורים בהערכת רוחב הפס

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

במכשירים עם Android 6.0 ואילך, מבצעים קריאה ל-ConnectivityManager.requestBandwidthUpdate() כדי לקבל הערכה של רוחב הפס של רשת סלולרית, והמסגרת עשויה לספק הערכה של רוחב הפס של קישור מוריד.

אבל במכשירים עם Android מגרסה 9 ואילך, פונקציית ה-callback‏ onCapabilitiesChanged() מופעלת באופן אוטומטי כשיש שינוי משמעותי ברוחב הפס המשוער, והקריאה ל-requestBandwidthUpdate() היא פעולה ללא תוצאה (no-op). המאפיינים המשויכים getLinkDownstreamBandwidthKbps() ו-getLinkUpstreamBandwidthKbps() מאוכלסים במידע מעודכן שמסופק על ידי השכבה הפיזית.

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

ניטור תנועה ב-eBPF

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

שחזור לממשקי API ברמה נמוכה יותר

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

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

מומלץ להשתמש באימות כדי לבדוק אם יש ערכים לא חוקיים בחלק מסוים של נתוני הגיבוי, ולשחזר רק נתונים חוקיים, כמו ב-core/java/android/provider/SettingsValidators.java.

התכונה מופעלת כברירת מחדל. אפשר להשבית את התמיכה של SettingsBackupAgent בשחזור מגרסאות עתידיות באמצעות Settings.Global.OVERRIDE_SETTINGS_PROVIDER_RESTORE_ANY_VERSION. לא נדרשת הטמעה נוספת, אלא אם יצרן המכשיר מרחיב את אחד מסוכני הגיבוי שכלולים ב-ROM (או מוסיף סוכן בהתאמה אישית).

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

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

  • SystemBackupAgent מציין את הערך restoreAnyVersion = false ב-Android 9 ואילך. הוא לא תומך בשחזור מגרסאות מתקדמות יותר של ה-API.

  • SettingsBackupAgent מציין את restoreAnyVersion = true ב-Android 9 ואילך. יש תמיכה חלקית באמצעות מאמתים. אפשר לשחזר הגדרה מגרסת API ישנה יותר אם קיים מאמת שלה במערכת ההפעלה של היעד. כשמוסיפים הגדרה, צריך להוסיף גם את כלי התיקוף שלה. פרטים נוספים זמינים בכיתה.

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

Enterprise

שיפורים בפרופיל המנוהל

שינויים בממשק המשתמש של פרופילים מנוהלים מאפשרים למשתמשים לזהות את הפרופיל המנוהל, לגשת אליו ולשלוט בו בקלות רבה יותר.

השהיה של ערוצי OTA

ה-@SystemApi החדש מאפשר לבעלי מכשירים להשהות ללא הגבלת זמן עדכוני OTA, כולל עדכוני אבטחה.

ביצועים

Health 2.0

Android מגרסה 9 ואילך כולל את android.hardware.health HAL 2.0, שדרוג גרסה משמעותי מ-health@1.0 HAL. מידע נוסף זמין בדפים הבאים:

פתרון אחסון במטמון של קובצי APK

ב-Android 9 ואילך יש פתרון של אחסון במטמון של חבילות APK להתקנה מהירה של אפליקציות שהועלו מראש במכשיר שתומך במחיצות A/B. יצרני ציוד מקורי יכולים להציב אפליקציות פופולריות ואפליקציות שהועלו מראש במטמון ה-APK, שמאוחסן בעיקר במחיצה B הריקה במכשירים חדשים עם מחיצות A/B, בלי להשפיע על שטח הנתונים שגלוי למשתמשים.

אופטימיזציה מבוססת-פרופיל

ב-Android 9 ואילך יש תמיכה בשימוש באופטימיזציה מבוססת-פרופיל (PGO) של Clang במודולים מקומיים של Android שיש להם כללי build של תוכנית אב.

רישום ביומן מראש

מצב מיוחד של SQLiteDatabase שנקרא compatibility write-ahead logging (WAL) מאפשר למסד נתונים להשתמש ב-journal_mode=WAL תוך שמירה על חיבור אחד לכל היותר לכל מסד נתונים.

זמני האתחול

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

כוח

הגבלות על פעילות ברקע

ב-Android 9 ואילך יש הגבלות ברקע שמאפשרות למשתמשים להגביל אפליקציות שעלולות לרוקן את הסוללה. המערכת עשויה גם להציע להשבית אפליקציות שמשפיעות לרעה על בריאות המכשיר.

מכשירים ללא סוללה

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