סקירה כללית של ערכת פיתוח מקורית של ספקים (VNDK).

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

למה VNDK?

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

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

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

כדי להתמודד עם אתגרים אלה, אנדרואיד מכילה מספר תכונות כגון VNDK (מתואר בסעיף זה), HIDL , hwbinder, שכבת עץ של מכשירים ושכבת על של מדיניות.

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

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

מושגי VNDK

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

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

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

ספריות משותפות במסגרת עבור הספק

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

  1. ייצוב ה-ABIs/APIs של הספריות המשותפות של המסגרת . מודולי מסגרת חדשים ומודולים ישנים של ספקים יכולים להשתמש באותה ספרייה משותפת כדי להקטין את טביעת הרגל של הזיכרון ואת גודל האחסון. ספרייה משותפת ייחודית גם מונעת מספר בעיות של טעינה כפולה. עם זאת, עלות הפיתוח לשמירה על ABIs/APIs יציבים היא גבוהה וזה לא ריאלי לייצב את כל ABIs/APIs המיוצאים על ידי כל ספרייה משותפת של מסגרת.
  2. העתק ספריות משותפות של מסגרת ישנה . מגיע עם ההגבלה החזקה נגד ערוצים צדדיים, המוגדרים ככל המנגנונים לתקשורת בין מודולי מסגרת ומודולי ספקים, כולל (אך לא מוגבל ל) קלסר, שקע, צינור, זיכרון משותף, קבצים משותפים ומאפייני מערכת. לא חייבת להיות תקשורת אלא אם כן פרוטוקול התקשורת קפוא ויציב (למשל HIDL דרך hwbinder). טעינה כפולה של ספריות משותפות עלולה לגרום גם לבעיות; לדוגמה, אם אובייקט שנוצר על ידי הספרייה החדשה מועבר לפונקציות מהספרייה הישנה, ​​עלולה להתרחש שגיאה מכיוון שספריות אלו עשויות לפרש את האובייקט בצורה שונה.

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

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

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

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

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

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

  • 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 ).

Vendor Test Suite (VTS)

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

,

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

למה VNDK?

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

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

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

כדי להתמודד עם אתגרים אלה, אנדרואיד מכילה מספר תכונות כגון VNDK (מתואר בסעיף זה), HIDL , hwbinder, שכבת עץ של מכשירים ושכבת על של מדיניות.

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

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

מושגי VNDK

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

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

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

ספריות משותפות במסגרת עבור הספק

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

  1. ייצוב ה-ABIs/APIs של הספריות המשותפות של המסגרת . מודולי מסגרת חדשים ומודולים ישנים של ספקים יכולים להשתמש באותה ספרייה משותפת כדי להקטין את טביעת הרגל של הזיכרון ואת גודל האחסון. ספרייה משותפת ייחודית גם מונעת מספר בעיות של טעינה כפולה. עם זאת, עלות הפיתוח לשמירה על ABIs/APIs יציבים היא גבוהה וזה לא ריאלי לייצב את כל ABIs/APIs המיוצאים על ידי כל ספרייה משותפת של מסגרת.
  2. העתק ספריות משותפות מסגרת ישנות . מגיע עם ההגבלה החזקה נגד ערוצים צדדיים, המוגדרים ככל המנגנונים לתקשורת בין מודולי מסגרת ומודולי ספקים, כולל (אך לא מוגבל ל) קלסר, שקע, צינור, זיכרון משותף, קבצים משותפים ומאפייני מערכת. לא חייבת להיות תקשורת אלא אם כן פרוטוקול התקשורת קפוא ויציב (למשל HIDL דרך hwbinder). טעינה כפולה של ספריות משותפות עלולה לגרום גם לבעיות; לדוגמה, אם אובייקט שנוצר על ידי הספרייה החדשה מועבר לפונקציות מהספרייה הישנה, ​​עלולה להתרחש שגיאה מכיוון שספריות אלו עשויות לפרש את האובייקט בצורה שונה.

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

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

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

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

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

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

  • 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 ).

Vendor Test Suite (VTS)

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

,

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

למה VNDK?

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

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

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

כדי להתמודד עם אתגרים אלה, אנדרואיד מכילה מספר תכונות כגון VNDK (מתואר בסעיף זה), HIDL , hwbinder, שכבת עץ של מכשירים ושכבת על של מדיניות.

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

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

מושגי VNDK

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

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

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

ספריות משותפות במסגרת עבור הספק

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

  1. ייצוב ה-ABIs/APIs של הספריות המשותפות של המסגרת . מודולי מסגרת חדשים ומודולים ישנים של ספקים יכולים להשתמש באותה ספרייה משותפת כדי להקטין את טביעת הרגל של הזיכרון ואת גודל האחסון. ספרייה משותפת ייחודית גם מונעת מספר בעיות של טעינה כפולה. עם זאת, עלות הפיתוח לשמירה על ABIs/APIs יציבים היא גבוהה וזה לא ריאלי לייצב את כל ABIs/APIs המיוצאים על ידי כל ספרייה משותפת של מסגרת.
  2. העתק ספריות משותפות מסגרת ישנות . מגיע עם ההגבלה החזקה נגד ערוצים צדדיים, המוגדרים ככל המנגנונים לתקשורת בין מודולי מסגרת ומודולי ספקים, כולל (אך לא מוגבל ל) קלסר, שקע, צינור, זיכרון משותף, קבצים משותפים ומאפייני מערכת. לא חייבת להיות תקשורת אלא אם כן פרוטוקול התקשורת קפוא ויציב (למשל HIDL דרך hwbinder). טעינה כפולה של ספריות משותפות עלולה לגרום גם לבעיות; לדוגמה, אם אובייקט שנוצר על ידי הספרייה החדשה מועבר לפונקציות מהספרייה הישנה, ​​עלולה להתרחש שגיאה מכיוון שספריות אלו עשויות לפרש את האובייקט בצורה שונה.

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

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

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

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

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

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

  • 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 ).

Vendor Test Suite (VTS)

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

,

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

למה VNDK?

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

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

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

כדי להתמודד עם אתגרים אלה, אנדרואיד מכילה מספר תכונות כגון VNDK (מתואר בסעיף זה), HIDL , hwbinder, שכבת עץ של מכשירים ושכבת על של מדיניות.

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

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

מושגי VNDK

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

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

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

ספריות משותפות במסגרת עבור הספק

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

  1. ייצוב ה-ABIs/APIs של הספריות המשותפות של המסגרת . מודולי מסגרת חדשים ומודולים ישנים של ספקים יכולים להשתמש באותה ספרייה משותפת כדי להקטין את טביעת הרגל של הזיכרון ואת גודל האחסון. ספרייה משותפת ייחודית גם מונעת מספר בעיות של טעינה כפולה. עם זאת, עלות הפיתוח לשמירה על ABIs/APIs יציבים היא גבוהה וזה לא ריאלי לייצב את כל ABIs/APIs המיוצאים על ידי כל ספרייה משותפת של מסגרת.
  2. העתק ספריות משותפות מסגרת ישנות . מגיע עם ההגבלה החזקה נגד ערוצים צדדיים, המוגדרים ככל המנגנונים לתקשורת בין מודולי מסגרת ומודולי ספקים, כולל (אך לא מוגבל ל) קלסר, שקע, צינור, זיכרון משותף, קבצים משותפים ומאפייני מערכת. לא חייבת להיות תקשורת אלא אם כן פרוטוקול התקשורת קפוא ויציב (למשל HIDL דרך hwbinder). טעינה כפולה של ספריות משותפות עלולה לגרום גם לבעיות; לדוגמה, אם אובייקט שנוצר על ידי הספרייה החדשה מועבר לפונקציות מהספרייה הישנה, ​​עלולה להתרחש שגיאה מכיוון שספריות אלו עשויות לפרש את האובייקט בצורה שונה.

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

  • ספריות LL-NDK הן ספריות מסגרת משותפות שידוע כי הן יציבות. המפתחים שלהם מחויבים לשמור על יציבות ה-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) הן ספריות משותפות במסגרת שבטוח להעתקה פעמיים. מודולי מסגרת ומודול ספק יכולים לקשר עם עותקים משלהם. A framework shared library can become an eligible VNDK library only if it satisfies the following criteria:
    • It does not send/receive IPCs to/from the framework.
    • It is not related to ART virtual machine.
    • It does not read/write files/partitions with unstable file formats.
    • It does not have special software license which requires legal reviews.
    • Its code owner does not have objections to vendor usages.
  • Framework-Only Libraries (FWK-ONLY) are Framework Shared Libraries that do not belong to the categories mentioned above. These libraries:
    • Are considered framework internal implementation details.
    • Must not be accessed by vendor modules.
    • Have unstable ABIs/APIs and no API/ABI compatibility guarantees.
    • Are not copied.

Same-Process HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) is a set of predetermined HALs implemented as Vendor Shared Libraries and loaded into Framework Processes . SP-HALs are isolated by a linker namespace (controls the libraries and symbols that are visible to the shared libraries). SP-HALs must depend only on LL-NDK and VNDK-SP .

VNDK-SP is a predefined subset of eligible VNDK libraries. VNDK-SP libraries are carefully reviewed to ensure double-loading VNDK-SP libraries into framework processes does not cause problems. Both SP-HALs and VNDK-SPs are defined by Google.

The following libraries are approved SP-HALs:

  • 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 libraries specify vndk: { support_system_process: true } in their Android.bp files. If vndk: {private:true} is also specified, then these libraries are called VNDK-SP-Private and they are invisible to SP-HALS.

The following are framework-only libraries with RS exceptions (FWK-ONLY-RS) :

  • libft2.so (Renderscript)
  • libmediandk.so (Renderscript)

VNDK versioning

VNDK shared libraries are versioned:

  • The ro.vndk.version system property is automatically added to /vendor/default.prop .
  • VNDK and VNDK-SP shared libraries are installed as a VNDK apex com.android.vndk.v${ro.vndk.version} and mounted to /apex/com.android.vndk.v${ro.vndk.version} .

The value of ro.vndk.version is chosen by the algorithm below:

  • If BOARD_VNDK_VERSION is not equal to current , use BOARD_VNDK_VERSION .
  • If BOARD_VNDK_VERSION is equal to current :
    • If PLATFORM_VERSION_CODENAME is REL , use PLATFORM_SDK_VERSION (eg 28 ).
    • Otherwise, use PLATFORM_VERSION_CODENAME (eg P ).

Vendor Test Suite (VTS)

The Android Vendor Test Suite (VTS) mandates a non-empty ro.vndk.version property. Both newly-launched devices and upgrading devices must define ro.vndk.version . Some VNDK test cases (eg VtsVndkFilesTest and VtsVndkDependencyTest ) rely on the ro.vndk.version property to load the matching eligible VNDK libraries data sets.