تفعيل VNDK

تتطلّب حزمة Vendor Native Development Kit ‏ (VNDK) إجراء عدة تغييرات على قاعدة بيانات لفصل المخاوف بين المورّد والنظام. استخدِم الدليل التالي لتفعيل حزمة VNDK في قاعدة بيانات رمز مطوّر/مصنّع أصلي.

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

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

الشكل 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"
      }
      ...
  }

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

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

يتم إنشاء إصدارات المورّدين من المكتبات باستخدام -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.