सूंग बिल्ड सिस्टम

Android 7.0 रिलीज़ से पहले, Android GNU ब्रैंड करने और उन्हें लागू करने के लिए डिज़ाइन किया गया है. Make बिल्ड सिस्टम बड़े पैमाने पर काम करता है और इसका इस्तेमाल भी किया जाता है. हालांकि, Android का इस्तेमाल धीरे-धीरे किया जा सकता है, गड़बड़ी होने की आशंका है, बड़े स्तर पर नहीं चलाया जा सकता और इसकी जांच करना भी मुश्किल है. कॉन्टेंट बनाने सूंग बिल्ड सिस्टम Android बिल्ड के लिए ज़रूरी सुविधा देता है.

इस वजह से, प्लैटफ़ॉर्म डेवलपर को 'बनाएं' टैब से दूसरे प्लैटफ़ॉर्म पर स्विच करना चाहिए और जल्द से जल्द. को सवाल भेजें Android-बिल्डिंग सहायता पाने के लिए Google Group.

सूंग क्या है?

Make की जगह सूंग का बिल्ड सिस्टम इस्तेमाल करने के लिए, Android 7.0 (Nougat) में नया सिस्टम पेश किया गया था. यह रणनीति, काटी जीएनयू क्लोन टूल और Ninja बिल्ड सिस्टम बनाएं Android के बिल्ड की रफ़्तार बढ़ाने के लिए कॉम्पोनेंट का इस्तेमाल किया जा सकता है.

ज़्यादा जानकारी के लिए, Android मेक बिल्ड सिस्टम Android ओपन सोर्स प्रोजेक्ट (AOSP) में दी गई जानकारी निर्देश और Android.mk लेखकों के लिए सिस्टम में बदलाव बनाएं देखें.

बिल्ड से जुड़ी एंट्री यहां देखें: मुख्य शब्दों और पूरी जानकारी के लिए, सूंग रेफ़रंस फ़ाइलें देखें.

बनाएं और सूंग की तुलना करें

यहां बताया गया है कि 'मेक कॉन्फ़िगरेशन' और सूंग के इस काम को कैसे पूरा कर रहे हैं सूंग कॉन्फ़िगरेशन (ब्लूप्रिंट या .bp) फ़ाइल.

उदाहरण के लिए

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := libxmlrpc++
LOCAL_MODULE_HOST_OS := linux

LOCAL_RTTI_FLAG := -frtti
LOCAL_CPPFLAGS := -Wall -Werror -fexceptions
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/src

LOCAL_SRC_FILES := $(call \
     all-cpp-files-under,src)
include $(BUILD_SHARED_LIBRARY)

सूंग का उदाहरण

cc_library_shared {
     name: "libxmlrpc++",

     rtti: true,
     cppflags: [
           "-Wall",
           "-Werror",
           "-fexceptions",
     ],
     export_include_dirs: ["src"],
     srcs: ["src/**/*.cpp"],

     target: {
           darwin: {
                enabled: false,
           },
     },
}

खास टेस्ट के हिसाब से सोंग कॉन्फ़िगरेशन के उदाहरणों के लिए, यहां देखें आसान बिल्ड कॉन्फ़िगरेशन.

Android.bp फ़ाइल में मौजूद फ़ील्ड के बारे में जानने के लिए, इसे देखें Android.bp फ़ाइल फ़ॉर्मैट.

खास मॉड्यूल

कुछ खास मॉड्यूल ग्रुप में खास विशेषताएं होती हैं.

डिफ़ॉल्ट मॉड्यूल

एक ही प्रॉपर्टी को कई मॉड्यूल में दोहराने के लिए, डिफ़ॉल्ट मॉड्यूल का इस्तेमाल किया जा सकता है. उदाहरण के लिए:

cc_defaults {
    name: "gzip_defaults",
    shared_libs: ["libz"],
    stl: "none",
}

cc_binary {
    name: "gzip",
    defaults: ["gzip_defaults"],
    srcs: ["src/test/minigzip.c"],
}

पहले से बने मॉड्यूल

पहले से बने कुछ मॉड्यूल के नाम, मॉड्यूल के नाम जैसा ही होने की अनुमति देते हैं सोर्स के हिसाब से मिलते-जुलते वर्शन उपलब्ध हैं. उदाहरण के लिए, वहां एक cc_prebuilt_binary हो सकता है इसका नाम foo है, जब इसी नाम का कोई cc_binary पहले से मौजूद हो. इससे ये फ़ायदे मिलते हैं डेवलपर के पास यह चुनने की सुविधा होती है कि वे अपने फ़ाइनल वर्शन में कौनसा वर्शन शामिल करें प्रॉडक्ट. अगर किसी बिल्ड कॉन्फ़िगरेशन में दोनों वर्शन शामिल हैं, तो prefer फ़्लैग पहले से बने मॉड्यूल की परिभाषा में मौजूद वैल्यू से पता चलता है कि किस वर्शन को प्राथमिकता दी गई है. ध्यान दें कि पहले से बने कुछ मॉड्यूल के नाम ऐसे होते हैं जो prebuilt से शुरू नहीं होते, जैसे कि android_app_import.

Namespace मॉड्यूल

जब तक Android पूरी तरह से, 'बनाएं' से सूंग में नहीं बदल जाता, तब तक प्रॉडक्ट का कॉन्फ़िगरेशन PRODUCT_SOONG_NAMESPACES मान बताना ज़रूरी है. यह मान, नेमस्पेस की स्पेस से अलग की गई सूची में होना चाहिए, जिसे सूंग 'मेक' में एक्सपोर्ट करता है को m कमांड से बनाया जाना चाहिए. Android के सूंग में बदलने की प्रक्रिया पूरी होने के बाद, नेमस्पेस चालू करने की जानकारी बदल सकती है.

सूंग अलग-अलग डायरेक्ट्री में मॉड्यूल की सुविधा देता है, ताकि एक ही नाम, जब तक हर मॉड्यूल एक अलग नेमस्पेस में बताया गया हो. ऐप्लिकेशन नेमस्पेस का एलान इस तरह किया जा सकता है:

soong_namespace {
    imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}

ध्यान दें कि नेमस्पेस में नाम प्रॉपर्टी नहीं होती; इसका पाथ अपने-आप असाइन किया गया है.

हर सूंग मॉड्यूल को पेड़ में उसकी जगह के आधार पर एक नेमस्पेस असाइन किया जाता है. हर एक सूंग मॉड्यूल को उस नेमस्पेस में माना जाता है जो मौजूदा डायरेक्ट्री की Android.bp फ़ाइल में soong_namespace मिली या सबसे नज़दीकी एंसेस्टर डायरेक्ट्री. अगर ऐसा कोई soong_namespace मॉड्यूल नहीं मिलता है, तो मॉड्यूल को इंप्लिसिट रूट नेमस्पेस में माना जाता है.

यहां एक उदाहरण दिया गया है: सूंग, मॉड्यूल M के ज़रिए बताए गए डिपेंडेंसी D को ठीक करने की कोशिश करता है नेमस्पेस N में, जो नेमस्पेस I1, I2, I3 इंपोर्ट करता है...

1. इसके बाद, अगर D फ़ॉर्म //namespace:module का पूरी तरह क्वालिफ़ाइड नाम है, तो सिर्फ़ इस नेमस्पेस को, बताए गए मॉड्यूल नाम के लिए खोजा जाता है.
2. नहीं तो, सूंग पहले नेमस्पेस में D नाम का मॉड्यूल ढूंढता है एन॰
3. अगर वह मॉड्यूल मौजूद नहीं है, तो सूंग नेमस्पेस I1, I2, I3...
4. आखिर में, सूंग रूट नेमस्पेस में दिखता है.