סקירה כללית על Vendor Native Development Kit (VNDK)

Vendor Native Development Kit (VNDK) היא קבוצת ספריות שמשמשות ספריות אחרות או בינאריים, במחיצת הספק או המוצר, בזמן הריצה של dlopen.

למה כדאי להשתמש ב-VNDK?

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

עדכונים באמצעות Framework בלבד כוללים את האתגרים הבאים:

  • תלות בין המודולים של framework והמודולים של הספקים. לפני Android 8.0, אפשר היה לקשר מודולים במחיצת הספק ובמחיצת המערכת שתי רשתות נוירונים זו מול זו. עם זאת, יחסי התלות ממודולים של ספקים נובעים באופן בלתי רצוי הגבלות על פיתוח מודולים של framework.
  • תוספים לספריות AOSP. במכשירי Android דרישה שכל מכשירי Android יעברו CTS כאשר מחיצת המערכת הוחלפה באמצעות תמונת מערכת כללית סטנדרטית (GSI). עם זאת, ככל שספקים מרחיבים את שירות AOSP ספריות לשיפור הביצועים או להוספת פונקציות נוספות ל-HIDL שלהן על הטמעות, להבהב את מחיצת המערכת באמצעות GSI סטנדרטי. עלול לגרום לשיבושים בהטמעת HIDL של ספק. לקבלת הנחיות לגבי כדי למנוע תקלות כאלה, תוספי VNDK.

כדי להתמודד עם האתגרים האלה, מערכת Android כוללת כמה תכונות, בתור VNDK (מתואר בקטע הזה), HIDL, hwbinder, שכבת-על של עץ המכשיר, וגם שכבת-על של Sepolicy.

תנאים ספציפיים ל-VNDK

מסמכים שקשורים ל-VNDK משתמשים במונחים הבאים:
  • מודולים מתייחסים לספריות משותפות או לקובצי הפעלה. מודולים יוצרים זמן build של יחסי התלות.
  • תהליכים הם משימות של מערכת ההפעלה שמקורם בקובצי הפעלה. תהליכים קובעים את זמן הריצה של יחסי התלות.
  • התנאים המתאימים ל-Framework קשורים למחיצה system:
    • קובצי הפעלה של framework מתייחסים לקובצי הפעלה ב-/system/bin או /system/xbin
    • ספריות משותפות של Framework מתייחסות לספריות משותפות /system/lib[64].
    • מודולים של framework מתייחסים לשתי הספריות המשותפות של framework וקובצי הפעלה של framework.
    • תהליכי מסגרת הם תהליכים שמקורם ב-framework בקובצי הפעלה, כמו /system/bin/app_process.
  • התנאים שאושרו על ידי הספקים קשורים למחיצות של vendor:
    • קובצי הפעלה של ספקים מתייחסים לקובצי הפעלה ב-/vendor/bin
    • ספריות משותפות של ספקים מתייחסות לספריות משותפות בקטע /vendor/lib[64].
    • מודולים של ספקים מתייחסים גם לקובצי הפעלה של ספקים וגם לספריות משותפות של ספקים.
    • תהליכים של ספקים הם תהליכים שנוצרים מהספק קובצי הפעלה, כמו /vendor/bin/android.hardware.camera.provider@2.4-service.

מושגי VNDK

בעולם Android 8.0 ואילך, תהליכי framework לא נטענים ספריות משותפות של ספקים, כל תהליכי העיבוד של הספקים טוענים רק ספריות משותפות של ספקים (וחלק מהספריות המשותפות של ה-framework), והתקשורת בין תהליכי framework ותהליכי ספקים כפופים ל-HIDL ולחומרה ב-Binder.

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

בקטעים הבאים מפורט האופן שבו VNDK מטפל בספריות משותפות של framework עבור ספקים ו-HALs בתהליכים שונים (SP-HAL).

ספריות משותפות של Framework לספק

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

  1. ייצב את ממשקי ה-ABI/API של הספריות המשותפות של ה-framework. מודולים חדשים של framework ומודולים ישנים של ספקים יכולים להשתמש באותה ספרייה משותפת כדי להקטין את טביעת הרגל הפחמנית ואת גודל האחסון. גם ספרייה משותפת ייחודית מונעת כמה בעיות של טעינה כפולה. יחד עם זאת, עלות הפיתוח כדי לשמור על יציבות ממשקי ה-ABI/API גבוהים ולא מציאותי לייצב את כל ממשקי ה-ABI/API שיוצאו על ידי כל ספרייה משותפת.
  2. העתקת ספריות משותפות ישנות. מגיע עם הגבלה שחלה על ערוצים צדדיים, מוגדרים ככל שהם מנגנונים לתקשורת בין המודולים של framework והמודולים של הספקים, כולל (בין היתר) binder , socket , pipe , זיכרון משותף, קובץ משותף ומאפייני מערכת. יש להיות ללא תקשורת, אלא אם פרוטוקול התקשורת קפוא ויציב (למשל, HIDL דרך hwbinder). טעינה כפולה של ספריות משותפות עלולה לגרום גם בעיות; לדוגמה, אם אובייקט שנוצר על ידי הספרייה החדשה מועבר בפונקציות מהספרייה הישנה, עלולה להיווצר שגיאה מאחר שהספריות עשויים לפרש את האובייקט באופן שונה.

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

  • ספריות LL-NDK הן ספריות משותפות ב-Framework שידועות כיציבות. המפתחים שלהם מחויבים לשמור על יציבות API/ABI.
    • LL-NDK כולל את הספריות הבאות: libEGL.so, libGLESv1_CM.so libGLESv2.so, libGLESv3.so libandroid_net.so, libc.so, libdl.so, liblog.so, libm.so, libnativewindow.so, libneuralnetworks.so, libsync.so, libvndksupport.so וגם libvulkan.so,
  • ספריות VNDK שעומדות בדרישות (VNDK) הן מסגרות משותפות ספריות שאפשר להעתיק פעמיים. Framework Modules וגם מודולים של ספקים יכולים לקשר לעותקים משלהם. מסגרת שותפה יכולה להפוך לספריית VNDK כשירה רק אם היא עומדת קריטריונים:
    • היא לא שולחת או מקבלת כתובות IPC אל ה-framework או ממנו.
    • היא לא קשורה למכונה וירטואלית של ART.
    • הוא לא קורא/כותב קבצים/מחיצות עם פורמטים לא יציבים של קבצים.
    • המכשיר לא כולל רישיון תוכנה מיוחד שדורש בדיקות משפטיות.
    • לבעלי הקוד אין התנגדות לשימושים של הספק.
  • ספריות מסגרת בלבד (FWK-בלבד) הן מסגרות משותפות ספריות שלא שייכות לקטגוריות שצוינו למעלה. האלה ספריות:
    • נחשבים מפרטי ההטמעה הפנימית של המסגרת.
    • אסור לגישה באמצעות מודולים של ספקים.
    • הם בעלי ממשקי ABI/API לא יציבים וללא הבטחות לתאימות של API/ABI.
    • הם לא מועתקים.

Same-Process HAL (SP-HAL)

HAL בתהליך זהה (SP-HAL) הוא קבוצה של רכיבי HAL שנקבעו מראש שמוטמעות כספריות משותפות של ספקים ונטענו אל Framework תהליכים. SP-HAL מבודדים באמצעות מרחב שמות של מקשר (שולט ספריות וסמלים שגלויים לספריות המשותפות). חובה לספקי SP-HAL תלויות רק ב-LL-NDK וב-VNDK-SP.

VNDK-SP הוא קבוצת משנה מוגדרת מראש של ספריות VNDK שעומדות בדרישות. ספריות VNDK-SP עוברים בדיקה קפדנית כדי לוודא שספריות VNDK-SP טוענות פעמיים ב-framework לא גורם לבעיות. מזהי SP-HAL ו-VNDK-SP מוגדרים לפי Google.

הספריות הבאות הן ספריות SP-HAL מאושרות:

  • libGLESv1_CM_${driver}.so
  • libGLESv2_${driver}.so
  • libGLESv3_${driver}.so
  • libEGL_${driver}.so
  • vulkan.${driver}.so
  • android.hardware.renderscript@1.0-impl.so
  • android.hardware.graphics.mapper@2.0-impl.so

ספריות VNDK-SP מציינות את הערך vndk: { support_system_process: true } בקובצי Android.bp. אם vndk: {private:true} הוא גם מציינים את הספריות האלה, הן נקראות VNDK-SP-Private בלתי נראה ל-SP-HALS.

הרשימה הבאה היא ספריות של framework בלבד עם החרגות RS (FWK-ONLY-RS):

  • libft2.so (רינדור)
  • libmediandk.so (רינדור)

ניהול גרסאות של VNDK

גרסאות של ספריות משותפות של VNDK:

  • מאפיין המערכת ro.vndk.version נוסף באופן אוטומטי אל /vendor/default.prop.
  • ספריות משותפות של VNDK ו-VNDK-SP מותקנות בתור קודקס של VNDK com.android.vndk.v${ro.vndk.version} נטענים אל /apex/com.android.vndk.v${ro.vndk.version}.

הערך של ro.vndk.version נבחר על ידי האלגוריתם למטה:

  • אם BOARD_VNDK_VERSION הוא לא שווה ל- current, שימוש ב-BOARD_VNDK_VERSION.
  • אם BOARD_VNDK_VERSION הוא שווה ל- current:
    • אם הערך של PLATFORM_VERSION_CODENAME הוא REL, צריך להשתמש PLATFORM_SDK_VERSION (למשל 28).
    • אחרת, צריך להשתמש ב-PLATFORM_VERSION_CODENAME (למשל, P).

חבילת בדיקה של ספקים (VTS)

חבילת הבדיקה של ספק Android (VTS) מחייבת מאפיין ro.vndk.version שאינו ריק. שני המכשירים שהושקו לאחרונה והמכשירים המשודרגים חייבים להגדיר את ro.vndk.version. בדיקת VNDK במקרים (למשל VtsVndkFilesTest VtsVndkDependencyTest) מסתמכים על ro.vndk.version כדי לטעון את קבוצות הנתונים התואמות של ספריות VNDK.