VNDK चालू करना

वेंडर नेटिव डेवलपमेंट किट (वीएनडीके) के लिए, कोडबेस में कई बदलाव करने पड़ते हैं, ताकि वेंडर और सिस्टम के बीच अंतर किया जा सके. वेंडर/ओईएम कोडबेस में 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 लाइब्रेरी का इस्तेमाल, वेंडर की इमेज में किया जाता है. वेंडर की इमेज में 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 या वीएनडीके एपेक्स में इंस्टॉल किया जाता है)

वेंडर के वर्शन वाली लाइब्रेरी, -D__ANDROID_VNDK__ का इस्तेमाल करके बनाई जाती हैं. इस फ़्लैग की मदद से, निजी सिस्टम कॉम्पोनेंट बंद किए जाते हैं. ये कॉम्पोनेंट, Android के आने वाले वर्शन में काफ़ी बदल सकते हैं. इसके अलावा, अलग-अलग लाइब्रेरी, हेडर का अलग-अलग सेट एक्सपोर्ट करती हैं. जैसे, liblog. टारगेट के वेंडर वैरिएंट के लिए खास तौर पर उपलब्ध विकल्पों को Android.bp फ़ाइल में इस तरह से तय किया जा सकता है:

target: { vendor: { … } }

किसी कोडबेस के लिए वीएनडीके चालू करना

किसी कोडबेस के लिए वीएनडीके चालू करने के लिए:

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 में ले जाया गया है. इन हेडर को मैनेज करने के लिए, इनमें से कोई एक काम करें:

• अगर हो सके, तो सभी 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 शामिल करें.