تمكين VNDK

يتطلب VNDK عدة تغييرات على قاعدة التعليمات البرمجية لفصل المخاوف بين البائع والنظام. استخدم الدليل التالي لتمكين VNDK في قاعدة تعليمات البائع/OEM.

بناء مكتبات النظام

يحتوي نظام البناء على عدة أنواع من الكائنات بما في ذلك المكتبات (المشتركة أو الثابتة أو الرأسية) والثنائيات.

الشكل 1. بناء مكتبات النظام

• يتم استخدام المكتبات core بواسطة صورة النظام، على صورة النظام. لا يمكن استخدام هذه المكتبات من قبل vendor ، أو vendor_available ، vndk ، أو vndk-sp .

  cc_library {
      name: "libThatIsCore",
      ...
  }
  

• يتم استخدام مكتبات vendor-only (أو proprietary ) بواسطة صورة البائع، على صورة البائع.

  cc_library {
      name: "libThatIsVendorOnly",
      proprietary: true,
      # or: vendor: true, # (for things in AOSP)
      ...
  }
  

• يتم استخدام مكتبات vendor_available بواسطة صورة البائع، على صورة البائع (قد تحتوي على نسخ مكررة من core ).

  cc_library {
      name: "libThatIsVendorAvailable",
      vendor_available: true,
      ...
  }
  

• يتم استخدام مكتبات vndk بواسطة صورة البائع، على صورة النظام.

  cc_library {
      name: "libThatIsVndk",
      vendor_available: true,
      vndk: {
          enabled: true,
      }
      ...
  }
  

• يتم استخدام مكتبات vndk-sp بواسطة صورة البائع وأيضًا بواسطة صورة النظام بشكل غير مباشر.

  cc_library {
      name: "libThatIsVndkSp",
      vendor_available: true,
      vndk: {
          enabled: true,
          support_system_process: true,
      }
      ...
  }
  

• يتم استخدام مكتبات llndk بواسطة صور النظام والبائعين.

  cc_library {
      name: "libThatIsLlndk",
      llndk: {
          symbol_file: "libthatisllndk.map.txt"
      }
      ...
  }
  

عندما يتم وضع علامة على lib على أنه vendor_available:true ، يتم إنشاؤه مرتين:

• مرة واحدة للنظام الأساسي (وبالتالي تم تثبيته على /system/lib )
• مرة واحدة للبائع (وبالتالي تم تثبيته على /vendor/lib أو VNDK APEX)

تم إنشاء إصدارات البائعين من libs باستخدام -D__ANDROID_VNDK__ . يتم تعطيل مكونات النظام الخاصة التي قد تتغير بشكل كبير في الإصدارات المستقبلية من Android باستخدام هذه العلامة. بالإضافة إلى ذلك، تقوم المكتبات المختلفة بتصدير مجموعة مختلفة من الرؤوس (مثل liblog ). يمكن تحديد الخيارات الخاصة بمتغير البائع للهدف في ملف Android.bp في:

target: { vendor: { … } }

تمكين VNDK لقاعدة التعليمات البرمجية

لتمكين VNDK لقاعدة التعليمات البرمجية:

1. تحديد الأهلية عن طريق حساب الأحجام المطلوبة لأقسام vendor.img و system.img .
2. تمكين BOARD_VNDK_VERSION=current . يمكنك الإضافة إلى BoardConfig.mk أو إنشاء مكونات باستخدامه مباشرةً (على سبيل المثال، m -j BOARD_VNDK_VERSION=current MY-LIB ).

بعد تمكين BOARD_VNDK_VERSION=current ، يفرض نظام الإنشاء متطلبات التبعية والرأس التالية.

إدارة التبعيات

يجب حل كائن vendor الذي يعتمد على مكون core غير موجود في vndk أو ككائن vendor باستخدام أحد الخيارات التالية:

• يمكن إزالة التبعية.
• إذا كان المكون core مملوكًا vendor ، فيمكن وضع علامة عليه على أنه vendor_available أو vendor .
• قد يتم نقل التغيير الذي يجعل الكائن الأساسي جزءًا من vndk إلى Google.

بالإضافة إلى ذلك، إذا كان للمكون core تبعيات على vendor ، فيجب تحويل مكون vendor إلى مكون core أو يجب إزالة التبعية بطريقة أخرى (على سبيل المثال، عن طريق إزالة التبعية أو عن طريق نقل التبعية إلى مكون vendor ).

إدارة الرؤوس

يجب إزالة تبعيات الرؤوس العامة لتمكين نظام الإنشاء من معرفة ما إذا كان سيتم إنشاء الرؤوس باستخدام -D__ANDROID_VNDK__ أم لا. على سبيل المثال، لا يزال من الممكن الوصول إلى رؤوس libutils مثل utils/StrongPointer.h باستخدام مكتبة الرؤوس libutils_headers .

لم يعد من الممكن تضمين بعض الرؤوس (مثل unistd.h ) بشكل متعدٍ ولكن يمكن تضمينها محليًا.

أخيرًا، تم نقل الجزء العام من private/android_filesystem_config.h إلى cutils/android_filesystem_config.h . لإدارة هذه الرؤوس، قم بأحد الإجراءات التالية:

• قم بإزالة التبعية إلى private/android_filesystem_config.h عن طريق استبدال كافة وحدات الماكرو AID_* باستدعاءات getgrnam / getpwnam إن أمكن. على سبيل المثال:
  • (uid_t)AID_WIFI يصبح getpwnam("wifi")->pw_uid .
  • (gid_t)AID_SDCARD_R يصبح getgrnam("sdcard_r")->gr_gid .
  للحصول على التفاصيل، راجع private/android_filesystem_config.h .
• بالنسبة لنظام AIS المشفر، قم بتضمين cutils/android_filesystem_config.h .