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

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

הפסקת תמיכה

NDK של הספק הושק ב-Android 8.0 כדי לספק ממשקי API בין המסגרת לקוד הספק. אמנם משתמשים ב-VNDK במשך שנים רבות, אבל יש לו כמה חסרונות:
  • אחסון
    • VNDK APEX אחד כולל את כל ספריות ה-VNDK, גם אם משתמשים בהן מהמכשיר וגם אם לא.
    • GSI מכיל כמה גרסאות של VNDK APEX כדי לתמוך בכמה גרסאות של תמונות של ספקים.
  • יכולת לקבל עדכונים
    • קשה לעדכן את 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:
    • קובצי הפעלה של framework מתייחסים לקובצי הפעלה ב-/system/bin או ב-/system/xbin.
    • ספריות משותפות של Framework מתייחסות לספריות המשותפות בקטע /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 ואילך, תהליכי המסגרת לא טוענים ספריות משותפות של ספקים, כל תהליכי הספקים טוענים רק ספריות משותפות של ספקים (וחלק מספריות המסגרת המשותפות), והתקשורת בין תהליכי המסגרת לבין תהליכי הספקים מבוססת על HIDL ועל hardware binder.

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

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

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

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

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

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

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

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

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

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