वीएनडीके चालू करें

वेंडर नेटिव डेवलपमेंट किट (VNDK) के लिए, कोडबेस में कई बदलाव करने पड़ते हैं, ताकि वेंडर और सिस्टम के बीच समस्याओं को अलग किया जा सके. वेंडर/OEM के कोडबेस में VNDK को चालू करने के लिए, यहां दी गई गाइड का इस्तेमाल करें.

सिस्टम लाइब्रेरी बनाना

बिल्ड सिस्टम में कई तरह के ऑब्जेक्ट होते हैं. इनमें लाइब्रेरी (शेयर की गई, स्टैटिक या हेडर) और बाइनरी शामिल हैं.

पहली इमेज. सिस्टम लाइब्रेरी बनाएं.

• 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__ के साथ या उसके बिना बनाया जाए. उदाहरण के लिए, utils/StrongPointer.h जैसे libutils हेडर को अब भी हेडर लाइब्रेरी libutils_headers का इस्तेमाल करके ऐक्सेस किया जा सकता है.

कुछ हेडर (जैसे, unistd.h) को अब ट्रांज़िटिव तरीके से शामिल नहीं किया जा सकता, लेकिन उन्हें स्थानीय तौर पर शामिल किया जा सकता है.

आखिर में, private/android_filesystem_config.h का सार्वजनिक हिस्सा cutils/android_filesystem_config.h पर ले जाया गया है. इन हेडर को मैनेज करने के लिए, इनमें से कोई एक काम करें:

• अगर हो सके, तो सभी AID_* मैक्रो को getgrnam/getpwnam कॉल से बदलकर, private/android_filesystem_config.h पर निर्भरता हटाएं. उदाहरण के लिए:
  • (uid_t)AID_WIFI, getpwnam("wifi")->pw_uid हो जाता है.
  • (gid_t)AID_SDCARD_R, getgrnam("sdcard_r")->gr_gid हो जाता है.
  ज़्यादा जानकारी के लिए, private/android_filesystem_config.h पर जाएं.
• हार्ड कोड किए गए एआईएस के लिए, cutils/android_filesystem_config.h शामिल करें.