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

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

פיתוח פתרונות

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

קובץ אימג' גנרי של המערכת (GSI) הוא קובץ אימג' של המערכת עם הגדרות מותאמות למכשירי Android. תמונת מערכת כללית (GSI) כוללת פרטים על ההבדלים בין תמונות GSI למכשירים שמופעלת בהם מערכת Android 9 ולמכשירים שמשדרגים ל-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 ואילך, כדי לשנות את המאפיינים שמוגדרים בשכבות-על של עץ המכשיר (DTO), צריך לוודא שמטען האתחול מעביר את ה-blob של עץ המכשיר המאוחד לליבת המערכת.

ניהול גרסאות של כותרות תמונות DTBO

‫Android מגרסה 9 ואילך כולל שדה גרסה בכותרת של תמונת DTBO.

אימות DTBO

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

תאימות של ליבת המערכת

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

‫Vendor NDK

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

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

בודק ABI

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

קובצי snapshot של VNDK

קובץ אימג' של המערכת יכול להשתמש בתמונות מצב של 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 ואילך.

המערכת כבסיס

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

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

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

DTBO בשחזור

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

תצוגה

מגרעות במסך

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

הצעות לסיבוב

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

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

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

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

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

צבעים עם טווח רחב

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

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

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

תאימות

מסמך הגדרת התאימות (CDD) של Android

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

הגדרות

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

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

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

הערה: התכונה פועלת מקצה לקצה רק אם מפעילים אותה כמו שצריך ב-Launchers. ‫AOSP כולל הטמעה לדוגמה. אפשר לעיין ב-Change-Id Iccd6f965fa3d61992244a365efc242122292c0ca ב-AOSP כדי לראות את קוד לדוגמה שסופק.

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

שידור מוגן של המערכת יכול להישלח לאפליקציות שמחזיקות בהרשאה 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 test harness.

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

הורדות של CTS

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

אפשרויות CTS

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

  • ‫run retry retries all tests that failed or weren't executed from the previous sessions.
  • ‫‘--shard-count מחלק את ההרצה של CTS למספר נתון של מקטעים עצמאיים, כדי להריץ אותה במקביל בכמה מכשירים.

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

שירות Secure Element (SE)

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

תיבת שילוב חיישנים

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

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

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

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

ארכיטקטורת בקר המארח

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

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

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

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

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

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

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

ניפוי באגים

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

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

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

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

תכונות אבטחה

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

סכמת החתימה v3 APK תומכת ברוטציית מפתחות APK.

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

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

ניתוח דינמי

‫Android 9 כולל תמיכה בכלים נוספים לניתוח ולהפחתת סיכונים של ניצול לרעה.

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

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

Kernel CFI

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

הצפנה

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

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

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

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

מאגר מפתחות

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

StrongBox

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

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

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

כדי לייבא מפתח באופן מאובטח אל 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 כולל בדיקות חדשות בזמן בנייה שמוודאות שלכל הקבצים במיקומים ספציפיים יש מאפיינים מתאימים. לדוגמה, כל הקבצים ב-sysfs כוללים את מאפיין sysfs_type הנדרש.

אודיו

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

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

מצלמה

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

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

מעקב תנועה

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

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

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

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

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

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

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

קישוריות

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

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

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

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

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

ספק

זיהוי הספק

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

eSIM

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

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

ב-Android מגרסה 9 ואילך יש שיפורים בהגדרות המשתמש של מערכת משנה מבוססת-IP למולטימדיה (IMS). אתם יכולים להגדיר 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 יכולים לקבל את השידורים.

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

Wi-Fi

‫Wi-Fi של ספק

התכונה carrier 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

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

בו-זמניות של Wi-Fi STA/AP היא היכולת של מכשירים לפעול במצב תחנה (STA) ובמצב נקודת גישה (AP) בו-זמנית. במכשירים שתומכים ב-Wi-Fi עם Dual Band Simultaneous (DBS), התכונה הזו מאפשרת יכולות חדשות, כמו להפעיל נקודה לשיתוף אינטרנט (Hotspot) בלי להפריע ל-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

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

גרפיקה

הטמעה

Vulkan 1.1 API

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

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

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

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

אינטראקציה

אודיו לרכב

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

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

שכבת הפשטת חומרה לרכב

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

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

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

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

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

הרשאות

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

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

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

ב-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

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

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

השהיית עדכונים דרך האוויר

ממשק ה-API החדש @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 שיש להם כללי בנייה של blueprint.

רישום ביומן כתיבה מראש

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

זמני הפעלה

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

הספק

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

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

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

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