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

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

הוצאה משימוש

‫Vendor NDK הושק ב-Android 8.0 כדי לספק ממשקי API בין המסגרת לבין קוד הספק. ה-VNDK נמצא בשימוש כבר הרבה שנים, אבל יש לו כמה חסרונות:

• אחסון
• חבילת APEX יחידה של VNDK כוללת את כל ספריות ה-VNDK, גם אם נעשה בהן שימוש מהמכשיר וגם אם לא.
• ‫GSI מכיל כמה גרסאות של VNDK APEX כדי לתמוך בכמה גרסאות של תמונות ספקים.
• אפשרות לקבל עדכונים
• קשה לעדכן קובצי VNDK APEX בנפרד מעדכון הפלטפורמה.
• קובצי אימג' של הספקים מתעדכנים לעיתים קרובות דרך האוויר (OTA), ולכן היתרונות של אריזת VNDK בתוך קובץ אימג' של המערכת מצטמצמים.

בעקבות הבעיות האלה, החלטנו להוציא משימוש את VNDK החל מ-Android 15.

פרטים על הוצאה משימוש של VNDK

כל ספריות ה-VNDK נארזות ב-VNDK APEX ומוגדרות להתקנה בתמונת המערכת (‎-ext). עם הוצאת VNDK משימוש, ספריות VNDK קודמות מותקנות בתמונת הספק (או המוצר), כמו ספריות אחרות שזמינות לספק. התכונות האלה יוסרו יחד עם הוצאת VNDK משימוש:

• ‫VNDK APEX ל-Android 15
• מאפייני המערכת שמציינים את הגרסה של ה-VNDK של היעד מוסרים אם מחיצות הספק או המוצר נוצרות עבור Android 15:
  • ro.vndk.version
  • ro.product.vndk.version
• האופטימיזציות של VNDK לא יהיו זמינות כי אין VNDK:
  • ‫TARGET_VNDK_USING_CORE_VARIANT למכשירי Android Go
  • ‫use_vndk_as_stable Vendor APEXes
• תמונת מצב של הספק, שתלויה מאוד ב-VNDK

חריגים להוצאה משימוש

התכונות האלה לא ישתנו עם הוצאת ה-VNDK משימוש:

• קובצי VNDK APEX עם VNDK גרסה 14 או גרסה נמוכה יותר, שנדרשים לתמיכה בתמונות ספקים קיימות.
• ‫LL-NDK לא נכלל ב-VNDK.

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

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

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

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

כדי להתמודד עם האתגרים האלה, מערכת Android כוללת כמה תכונות כמו ערכת פיתוח מקומית לספק (VNDK) (שמתוארת בקטע הזה),‏ HIDL,‏ hwbinder,‏ שכבת-על של פירוט מבנה המכשיר ו-sepolicy overlay.

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

במסמכים שקשורים ל-VNDK נעשה שימוש במינוח הבא:

• מודולים הם ספריות משותפות או קבצים הפעלה. מודולים יוצרים יחסי תלות בזמן ה-build.
• תהליכים הם משימות של מערכת ההפעלה שנוצרות מקבצים הפעלה. תהליכים יוצרים תלות בזמן ריצה.
• מונחים שעומדים בדרישות המסגרת קשורים למחיצה system:
• קובצי הפעלה של המסגרת הם קובצי הפעלה ב-/system/bin או ב-/system/xbin.
• ספריות משותפות של מסגרות הן ספריות משותפות שנמצאות בתיקייה /system/lib[64].
• מודולים של מסגרות מתייחסים גם לספריות משותפות של מסגרות וגם לקובצי הפעלה של מסגרות.
• תהליכי 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 ו-hardware binder.

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

בקטעים הבאים מוסבר איך VNDK מטפל בספריות משותפות של מסגרות לספקים וב-HALs (שכבות הפשטה של חומרה) באותו תהליך (SP-HALs).

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

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

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

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

• ספריות 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 שאפשר להעתיק פעמיים בלי בעיה. מודולים של מסגרת ומודולים של ספקים יכולים להיות מקושרים לעותקים שלהם. ספרייה משותפת של framework יכולה להיות ספריית VNDK מתאימה רק אם היא עומדת בקריטריונים הבאים:
  • הוא לא שולח או מקבל הודעות IPC אל או מהמסגרת.
  • הוא לא קשור למכונה הווירטואלית ART.
  • היא לא קוראת/כותבת קבצים/מחיצות עם פורמטים לא יציבים של קבצים.
  • אין לו רישיון תוכנה מיוחד שדורש בדיקות משפטיות.
  • לבעלים של הקוד אין התנגדות לשימוש בו על ידי ספקים.
• ספריות Framework-Only (FWK-ONLY) הן ספריות Framework Shared שלא שייכות לקטגוריות שצוינו למעלה. הספריות האלה:
  • נחשבים לפרטי הטמעה פנימיים של המסגרת.
  • אסור למודולים של ספקים לגשת אליהם.
  • יש להם ממשקי ABI/API לא יציבים ואין להם ערבויות תאימות ל-API/ABI.
  • לא מועתקים.

HAL באותו תהליך (SP-HAL)

‫Same-Process HAL ‏ (SP-HAL) הוא קבוצה של HAL שנקבעו מראש ומיושמים כ-Vendor Shared Libraries ונטענים לתוך Framework Processes. ספריות SP-HAL מבודדות על ידי מרחב שמות של מקשר (שולט בספריות ובסמלים שגלויים לספריות המשותפות). מודולי SP-HAL צריכים להיות תלויים רק ב-LL-NDK וב-VNDK-SP.

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

אלה ספריות 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 (Renderscript)
• libmediandk.so (Renderscript)

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

הספריות המשותפות של VNDK הן בעלות גרסאות:

• נכס המערכת ro.vndk.version נוסף אוטומטית אל /vendor/default.prop.
• ספריות משותפות של VNDK ו-VNDK-SP מותקנות כ-VNDK apex 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.
• ‫If BOARD_VNDK_VERSION is equal to 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 שעומדות בדרישות.