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

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

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

הפסקת תמיכה

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

• אחסון
• חבילת VNDK APEX אחת מכילה את כל ספריות VNDK, גם אם נעשה בהן שימוש מהמכשיר וגם אם לא.
• GSI מכיל כמה גרסאות של VNDK APEXes כדי לתמוך בכמה גרסאות של קובצי אימג' של ספקים.
• יכולת לקבל עדכונים
• קשה לעדכן את VNDK APEXes בנפרד מהעדכון של הפלטפורמה.
• תמונות של ספקים מתעדכנות לעיתים קרובות באוויר (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 עבור חשבונות APEX של ספקים
• snapshot של הספק, שתלוי מאוד ב-VNDK

החרגות מההוצאה משימוש

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

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

למה VNDK?

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

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

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

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

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

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

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

מושגים ב-VNDK

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

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

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

ספריות משותפות של מסגרת לספקי תוכנה

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

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

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

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

VNDK-SP היא קבוצת משנה מוגדרת מראש של ספריות VNDK שעומדות בדרישות. ספריות VNDK-SP נבדקות בקפידה כדי לוודא שהטעינה הכפולה של ספריות VNDK-SP בתהליכי המסגרת לא גורמת לבעיות. גם ממשקי 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.

אלה ספריות של מסגרת בלבד עם חריגות 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.
• אם BOARD_VNDK_VERSION שווה current:
• אם הערך של PLATFORM_VERSION_CODENAME הוא REL, צריך להשתמש ב-PLATFORM_SDK_VERSION (למשל 28).
• אחרת, צריך להשתמש ב-PLATFORM_VERSION_CODENAME (למשל: P).

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

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