रिलीज़ होने वाले किसी भी वर्शन की जानकारी देने वाले दस्तावेज़ के लिए, कृपया "वर्शन दस्तावेज़" ड्रॉप-डाउन का इस्तेमाल करें. डिफ़ॉल्ट व्यू, head पर सबसे नए वर्शन को दिखाता है.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

Android नियम

किसी समस्या की शिकायत करें सोर्स देखें

नियम

android_binary
aar_import
android_library
android_platformation_test
android_local_test
android_device
android_ndk_repository
android_sdk_repository

Android_बाइनरी

नियम का सोर्स देखें

android_binary(name, deps, srcs, assets, assets_dir, compatible_with, crunch_png, custom_package, debug_key, debug_signing_keys, debug_signing_lineage_file, densities, deprecation, dex_shards, dexopts, distribs, enable_data_binding, exec_compatible_with, exec_properties, features, incremental_dexing, instruments, javacopts, key_rotation_min_sdk, licenses, main_dex_list, main_dex_list_opts, main_dex_proguard_specs, manifest, manifest_values, multidex, nocompress_extensions, package_id, plugins, proguard_apply_dictionary, proguard_apply_mapping, proguard_generate_mapping, proguard_specs, resource_configuration_filters, resource_files, restricted_to, shrink_resources, tags, target_compatible_with, testonly, visibility)

इससे Android ऐप्लिकेशन पैकेज फ़ाइलें (.apk) बनती हैं.

इंप्लिसिट आउटपुट टारगेट

name.apk: Android ऐप्लिकेशन पैकेज फ़ाइल, जिसे डीबग कुंजियों और zipaligned से साइन किया गया है, उसका इस्तेमाल आपके ऐप्लिकेशन को डेवलप और डीबग करने के लिए किया जा सकता है. डीबग कुंजियों के साथ साइन इन करने पर, आप अपना ऐप्लिकेशन रिलीज़ नहीं कर सकते.
name_unsigned.apk: फ़ाइल का बिना हस्ताक्षर वाला ऐसा वर्शन जिसे सार्वजनिक तौर पर रिलीज़ करने से पहले, रिलीज़ कुंजियों से साइन किया जा सकता है.
name_deploy.jar: एक Java संग्रह जिसमें इस टारगेट को स्थायी तौर पर बंद किया जाता है.
डिप्लॉयमेंट जार में वे सभी क्लास होती हैं जो किसी क्लासलोडर से मिलती हैं. इस क्लासलोडर ने शुरू से आखिर तक, इस टारगेट के रनटाइम क्लासपाथ को खोजा है.
name_proguard.jar, एक Java संग्रह है जिसमें name_deploy.jar पर ProGuard चलाने का नतीजा है. यह आउटपुट सिर्फ़ तब बनाया जाता है, जब proGuard_specs एट्रिब्यूट को बताया गया हो.
name_proguard.map: name_deploy.jar पर ProGuard चलाने का नतीजा. यह आउटपुट सिर्फ़ तब बनाया जाता है, जब proGuard_specs एट्रिब्यूट के बारे में बताया गया हो और proGuard_generate_mapping या shrink_resources को सेट किया गया हो.

उदाहरण

Android के नियमों के उदाहरण, बेज़ल सोर्स ट्री की examples/android डायरेक्ट्री में देखे जा सकते हैं.

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए यूनीक नाम.
`deps`	`List of labels; optional` बाइनरी लक्ष्य से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. इन लाइब्रेरी टाइप का इस्तेमाल किया जा सकता है: `android_library`, `java_library` की `android` कंस्ट्रेंट के साथ और `cc_library` टारगेट शीट के लिए, `cc_library` नेटिव लाइब्रेरी को रैप या प्रोड्यूस किया जा रहा है.
`srcs`	`List of labels; optional` सोर्स फ़ाइलों की सूची जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. `.java` प्रकार की `srcs` फ़ाइलें कंपाइल की गई हैं. पढ़ने में आसान के लिए, जनरेट की गई `.java` सोर्स फ़ाइल का नाम `srcs` में डालना सही नहीं है. इसके बजाय, `srcs` पर निर्भर नियम का नाम डालें, जैसा कि यहां बताया गया है. `.srcjar` की `srcs` फ़ाइलें अनपैक की जाती हैं और उन्हें कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule या बिल्ड एक्सटेंशन के साथ, .java फ़ाइलों का सेट जनरेट करना होता है.)
`assets`	`List of labels; optional` पैकेज की जाने वाली एसेट की सूची. आम तौर पर, यह `assets` डायरेक्ट्री में मौजूद सभी फ़ाइलों का `glob` होता है. आपके पास दूसरे नियमों का भी इस्तेमाल करने का विकल्प है. जैसे, कोई फ़ाइल बनाने के लिए इस्तेमाल किए जाने वाले नियम या अन्य पैकेज में मौजूद फ़ाइलें. हालांकि, ऐसा तब ही हो सकता है, जब उन सभी फ़ाइलों को उससे जुड़े पैकेज की `assets_dir` डायरेक्ट्री में देखा जा सकता हो.
`assets_dir`	`String; optional` वह स्ट्रिंग जो `assets` में मौजूद फ़ाइलों का पाथ बताती है. जोड़ी गई `assets` और `assets_dir` जोड़ी गई एसेट, पैकेज की गई एसेट के बारे में बताती हैं. दोनों एसेट के बारे में बताया जाना चाहिए या इनमें से कोई नहीं.
`crunch_png`	`Boolean; optional; default is True` PNG को समेटें. यह नौ पैच प्रोसेसिंग से अलग है, जो हमेशा किया जाता है. यह aapt बग के लिए रुका हुआ समाधान है, जिसे aapt2 में ठीक किया गया है.
`custom_package`	`String; optional` Java पैकेज जिसके लिए java स्रोत जनरेट किए जाएंगे. आम तौर पर, पैकेज का पता उस डायरेक्ट्री से लिया जाता है जहां BUILD फ़ाइल में नियम शामिल होता है. आप कोई दूसरा पैकेज दे सकते हैं. हालांकि, हम ऐसा करने की सलाह नहीं देते, क्योंकि इससे रनटाइम के दौरान जनरेट की गई अन्य लाइब्रेरी के साथ, क्लासपाथ के कॉन्फ़्लिक्ट से जुड़ी गड़बड़ी आ सकती है.
`debug_key`	`Label; optional; default is @bazel_tools//tools/android:debug_keystore` वह फ़ाइल जिसमें डीबग कीस्टोर मौजूद है, जिसका इस्तेमाल डीबग apk को साइन करने के लिए किया जाता है. आम तौर पर, आपको डिफ़ॉल्ट बटन के अलावा किसी दूसरी कुंजी का इस्तेमाल नहीं करना चाहिए. इसलिए, इस एट्रिब्यूट का इस्तेमाल न करें. चेतावनी: अपनी प्रोडक्शन कुंजियों का इस्तेमाल न करें, उन्हें पूरी तरह से सुरक्षित रखना चाहिए और उन्हें आपके सोर्स ट्री में नहीं रखना चाहिए.
`debug_signing_keys`	`List of labels; optional` फ़ाइलों की सूची, डीबग के APK पर हस्ताक्षर करने के लिए कीस्टोर को डीबग करें. आम तौर पर, आपको डिफ़ॉल्ट बटन के अलावा किसी दूसरी कुंजी का इस्तेमाल नहीं करना चाहिए. इसलिए, इस एट्रिब्यूट का इस्तेमाल न करें. चेतावनी: अपनी प्रोडक्शन कुंजियों का इस्तेमाल न करें, उन्हें पूरी तरह से सुरक्षित रखना चाहिए और उन्हें आपके सोर्स ट्री में नहीं रखना चाहिए.
`debug_signing_lineage_file`	`Label; optional` डीबग_sign_keys के लिए साइनिंग वंशावली वाली फ़ाइल. आम तौर पर, आपको डिफ़ॉल्ट बटन के अलावा किसी दूसरी कुंजी का इस्तेमाल नहीं करना चाहिए. इसलिए, इस एट्रिब्यूट का इस्तेमाल न करें. चेतावनी: अपनी प्रोडक्शन कुंजियों का इस्तेमाल न करें, उन्हें पूरी तरह से सुरक्षित रखना चाहिए और उन्हें आपके सोर्स ट्री में नहीं रखना चाहिए.
`densities`	`List of strings; optional` APK बनाते समय फ़िल्टर करने की सुविधा. इससे रास्टर ड्रॉ किए जा सकने वाले ऐसे संसाधन हटा दिए जाएंगे जिन्हें किसी डिवाइस से, खास स्क्रीन डेंसिटी के साथ लोड नहीं किया जाएगा. इससे, APK का साइज़ कम हो जाएगा. अगर मेनिफ़ेस्ट में पहले से कोई सुपरसेट लिस्टिंग नहीं है, तो मेनिफ़ेस्ट में भी ऐसी स्क्रीन के सेक्शन को जोड़ा जाएगा जो इसके साथ काम करते हों.
`dex_shards`	`Integer; optional; default is 1` शार्ड डीक्सिंग की संख्या कम की जा सकती है. इससे, ऐप्लिकेशन इंस्टॉल करने और स्टार्टअप के समय खर्च करने से, आपको काफ़ी जल्दी मदद मिलती है. बाइनरी फ़ाइल को जितना बड़ा किया जाएगा, उतने ज़्यादा शार्ड का इस्तेमाल किया जाएगा. प्रयोग करना शुरू करने के लिए, 25 का इस्तेमाल करना बेहतर रहता है. ध्यान दें कि फ़ाइनल ऐप्लिकेशन में हर शार्ड को कम से कम एक डेक्स मिलेगा. इस वजह से, रिलीज़ बाइनरी के लिए इसे 1 से ज़्यादा पर सेट करने का सुझाव नहीं दिया जाता.
`dexopts`	`List of strings; optional` class.dex जनरेट करते समय, dx टूल के लिए कमांड लाइन के अन्य फ़्लैग पाएं. "वैरिएबल बनाएं" विकल्प और बोन शेल टोकनाइज़ेशन के तहत.
`enable_data_binding`	`Boolean; optional; default is False` अगर यह नियम सही है, तो यह रिसॉर्स_फ़ाइल एट्रिब्यूट के ज़रिए शामिल लेआउट रिसॉर्स में डेटा बाइंडिंग एक्सप्रेशन प्रोसेस करता है. इस सेटिंग के बिना, डेटा बाइंडिंग एक्सप्रेशन पूरी तरह काम नहीं करते. डेटा बाइंडिंग वाला Android ऐप्लिकेशन बनाने के लिए, आपको ये काम भी करने होंगे: इस एट्रिब्यूट को उन सभी Android नियमों के लिए सेट करें जो कुछ समय के लिए, इस पर निर्भर रहते हैं. ऐसा इसलिए होता है, क्योंकि डिपेंडेंट, रिसोर्स को मर्ज करने की सुविधा का इस्तेमाल करके, नियम की डेटा बाइंडिंग एक्सप्रेशन इनहेरिट कर लेते हैं. इसलिए, उन्हें इन एक्सप्रेशन को पार्स करने के लिए, डेटा बाइंडिंग का इस्तेमाल करके, फ़ील्ड बनाना ज़रूरी होता है. इस प्रॉपर्टी को सेट करने वाले सभी टारगेट में, डेटा बाइंडिंग रनटाइम लाइब्रेरी के लिए एक `deps =` एंट्री जोड़ें. यह लाइब्रेरी, आपके डिपो के सेट अप के हिसाब से तय होती है.
`incremental_dexing`	`Integer; optional; nonconfigurable; default is -1` टारगेट को इंक्रीमेंटल डेक्सिंग के साथ या उसके बिना बनाए जाने के लिए बनाएं. इसके लिए, डिफ़ॉल्ट और ininmental_dexing फ़्लैग को बदलें.
`instruments`	`Label; optional` `android_binary`, इंस्ट्रूमेंट पर सेट होता है. अगर यह एट्रिब्यूट सेट किया जाता है, तो इस `android_binary` को इंस्ट्रूमेंटेशन टेस्ट के लिए टेस्ट ऐप्लिकेशन के तौर पर माना जाएगा. इसके बाद, `android_instrumentation_test` टारगेट इस टारगेट को इसके test_app एट्रिब्यूट में तय कर सकता है.
`javacopts`	`List of strings; optional` इस टारगेट के लिए ज़्यादा कंपाइलर विकल्प. "वैरिएबल बनाएं" विकल्प और बोन शेल टोकनाइज़ेशन के तहत. यह कंपाइलर विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac में पास कर दिए जाते हैं.
`key_rotation_min_sdk`	`String; optional` वह कम से कम Android प्लैटफ़ॉर्म वर्शन (एपीआई लेवल) सेट करता है जिसके लिए APK का हस्ताक्षर बनाने के लिए APK की बदली गई साइनिंग कुंजी का इस्तेमाल किया जाना चाहिए. APK के लिए मूल साइनिंग कुंजी का इस्तेमाल पिछले सभी प्लैटफ़ॉर्म वर्शन के लिए किया जाएगा.
`main_dex_list`	`Label; optional` टेक्स्ट फ़ाइल में कक्षा के फ़ाइल नामों की सूची होती है. उन क्लास फ़ाइलों में तय की गई क्लास, प्राइमरी क्लास में रखी जाती हैं. जैसे: android/support/multidex/MultiDex$V19.class android/support/multidex/MultiDex.class android/support/multidex/MultiDexApplication.class com/google/common/base/Objects.class `multidex="manual_main_dex"` के साथ इस्तेमाल किया जाना चाहिए.
`main_dex_list_opts`	`List of strings; optional` मुख्य dex सूची बिल्डर को पास करने के लिए कमांड लाइन विकल्प. मुख्य dex सूची में शामिल क्लास को प्रभावित करने के लिए इस विकल्प का उपयोग करें.
`main_dex_proguard_specs`	`List of labels; optional` उन फ़ाइलों के बारे में पता लगाने के लिए जिन्हें ProGuard स्पेसिफ़िकेशन के तौर पर इस्तेमाल किया जाना चाहिए जिन्हें मुख्य डेक में रखा जाना चाहिए. सिर्फ़ तब अनुमति है, जब `multidex` एट्रिब्यूट `legacy` पर सेट हो.
`manifest`	`Label; required` Android मेनिफ़ेस्ट फ़ाइल का नाम, आम तौर पर `AndroidManifest.xml`. अगर रिसॉर्स_फ़ाइल या एसेट की जानकारी दी गई है, तो वे तय होनी चाहिए.
`manifest_values`	`Dictionary: String -> String; optional` मेनिफ़ेस्ट में बदली जाने वाली वैल्यू की डिक्शनरी. मेनिफ़ेस्ट में मौजूद ${name} के किसी भी उदाहरण को इस शब्दकोश में मौजूद नाम से जुड़ी वैल्यू से बदल दिया जाएगा. applicationId, versionCode, versionName, minSdkVersion, targetSdkVersion और maxSdkVersion भी मेनिफ़ेस्ट के संबंधित एट्रिब्यूट को बदल देंगे और sdk टैग का इस्तेमाल करते हैं. packageName को अनदेखा कर दिया जाएगा और अगर बताया गया हो या पैकेज में मौजूद पैकेज, तो appId से सेट किया जाएगा. जब मेनिफ़ेस्ट_मर्जर को लेगसी पर सेट किया जाता है, तो सिर्फ़ applicationId, versionCode, और versionName का कोई असर होगा.
`multidex`	`String; optional; default is "native"` कोड को कई dex फ़ाइलों में बांटना है या नहीं. जितने तरह के प्लेसमेंट हो सकते हैं उनकी जानकारी यहां दी गई है: `native`, dex 64K इंडेक्स की सीमा पार होने पर, कोड को एक से ज़्यादा Dex फ़ाइलों में बांटें. यह मान लेता है कि रनटाइम पर मल्टीडेक्स क्लास लोड करने के लिए, नेटिव प्लैटफ़ॉर्म सपोर्ट है. यह सिर्फ़ Android L और उसके बाद वाले वर्शन के साथ काम करता है. `legacy`, dex 64K इंडेक्स की सीमा पार होने पर, कोड को एक से ज़्यादा Dex फ़ाइलों में बांटें. मान लें कि मल्टीडेक्स क्लास, ऐप्लिकेशन कोड के ज़रिए लोड की जाती हैं (जैसे कि कोई स्थानीय प्लैटफ़ॉर्म सपोर्ट नहीं). `manual_main_dex`: dex 64K इंडेक्स की सीमा पार होने पर कोड को कई dex फ़ाइलों में बांटें. मुख्य dex फ़ाइल का कॉन्टेंट, main_dex_list एट्रिब्यूट का इस्तेमाल करके, टेक्स्ट फ़ाइल में क्लास की सूची देकर बताया जाना चाहिए. `off` सभी कोड को एक ही dex फ़ाइल में कंपाइल करें, भले ही वह इंडेक्स की सीमा से ज़्यादा हो.
`nocompress_extensions`	`List of strings; optional` apk में कंप्रेस किए बिना छोड़ने के लिए फ़ाइल एक्सटेंशन की सूची.
`package_id`	`Integer; optional; default is 0` इस बाइनरी में मौजूद संसाधनों को असाइन किया जाने वाला पैकेज आईडी. ज़्यादा जानकारी के लिए, AAPT2 का `--package-id` आर्ग्युमेंट देखें. आम तौर पर, इसे सेट (या) किया जाना चाहिए, जिसकी वजह से वैल्यू का डिफ़ॉल्ट मान 127 (`0x7F`) हो जाता है.
`plugins`	`List of labels; optional` कंपाइल के समय पर चलने वाले Java कंपाइलर प्लग इन. जब भी यह टारगेट बनाया जाएगा, तब प्लग इन एट्रिब्यूट में दिए गए हर `java_plugin` को चलाया जाएगा. प्लग इन से जनरेट हुए रिसॉर्स को टारगेट के नतीजे के जार में शामिल किया जाएगा.
`proguard_apply_dictionary`	`Label; optional` प्रोगार्ड के लिए मैपिंग के रूप में इस्तेमाल की जाने वाली फ़ाइल. अस्पष्ट बनाने के दौरान, कक्षाओं और सदस्यों के नाम बदलते समय, "शब्द" की एक लाइन को, अलग-अलग किया जाता है.
`proguard_apply_mapping`	`Label; optional` प्रोगार्ड के लिए मैपिंग के रूप में इस्तेमाल की जाने वाली फ़ाइल. नए बिल्ड पर वही मैपिंग लागू करने के लिए, `proguard_generate_mapping` से जनरेट की गई मैपिंग फ़ाइल.
`proguard_generate_mapping`	`Boolean; optional; nonconfigurable; default is False` ProGuard मैपिंग फ़ाइल जनरेट करनी है या नहीं. मैपिंग फ़ाइल सिर्फ़ `proguard_specs` जनरेट होने पर ही जनरेट होगी. इस फ़ाइल में मूल और अस्पष्ट क्लास, तरीके, और फ़ील्ड के नामों के बीच मैपिंग की सूची होगी. चेतावनी: अगर इस एट्रिब्यूट का इस्तेमाल किया जाता है, तो ProGuard की खास बातों में `-dontobfuscate` या `-printmapping` शामिल नहीं होने चाहिए.
`proguard_specs`	`List of labels; optional` ProGuard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. यह फ़ाइल, खास जानकारी के उस सेट के बारे में बताएगी जिसे ProGuard में इस्तेमाल किया जाएगा.
`resource_configuration_filters`	`List of strings; optional` संसाधन कॉन्फ़िगरेशन फ़िल्टर की सूची, जैसे कि 'en' जो apk के संसाधनों को सिर्फ़ 'en' कॉन्फ़िगरेशन वाले संसाधनों तक सीमित कर देगी. सूडोलोकलाइज़ेशन की सुविधा चालू करने के लिए, `en_XA` और/या `ar_XB` सूडो-लोकेशन शामिल करें.
`resource_files`	`List of labels; optional` पैकेज किए जाने वाले संसाधनों की सूची. आम तौर पर, यह `res` डायरेक्ट्री में मौजूद सभी फ़ाइलों का `glob` होता है. जनरेट की गई फ़ाइलों (जेनर से) को यहां लेबल से भी रेफ़र किया जा सकता है. सिर्फ़ एक पाबंदी यह है कि जनरेट किए गए आउटपुट उसी "`res`" डायरेक्ट्री में शामिल होने चाहिए जो किसी दूसरी रिसॉर्स फ़ाइल में शामिल हैं.
`shrink_resources`	`Integer; optional; default is -1` संसाधन छोटा किया जाए या नहीं. बाइनरी का इस्तेमाल नहीं करने वाले रिसॉर्स को APK से हटा दिया जाएगा. यह सुविधा सिर्फ़ स्थानीय संसाधनों (जैसे, `manifest` और `resource_files` एट्रिब्यूट) का इस्तेमाल करने वाले नियमों के लिए है. साथ ही, इनके लिए ProGuard की ज़रूरत होती है. यह ज़्यादातर Gradle संसाधन श्रेंडरर (https://developer.android.com/studio/build/shrink-code.html#shrink-resources) की तरह ही काम करता है. ध्यान देने लायक अंतर: `values/` में मौजूद रिसॉर्स के साथ-साथ, फ़ाइल पर आधारित रिसॉर्स भी हटा दिए जाएंगे डिफ़ॉल्ट रूप से `strict mode` का इस्तेमाल करती है इस्तेमाल नहीं किए गए आईडी संसाधनों को हटाने की सुविधा सिर्फ़ aapt2 के साथ काम करती है अगर रिसॉर्स को छोटा करने की सुविधा चालू है, तो विश्लेषण और मिटाए गए कॉन्टेंट के बारे में बताते हुए `name_files/resource_shrinker.log` भी जनरेट किया जाएगा. जितनी तरह के साइटमैप हो सकते हैं उनकी जानकारी यहां दी गई है: `shrink_resources = 1`: Android संसाधन के सिकुड़ने की सुविधा चालू करें `shrink_resources = 0`: Android रिसॉर्स के सिकुड़ने की सुविधा बंद कर देता है `shrink_resources = -1` श्रिंकिंग की प्रक्रिया को --android_resources_shinking फ़्लैग से कंट्रोल किया जाता है.

aar_import

नियम का सोर्स देखें

aar_import(name, deps, data, aar, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, licenses, restricted_to, srcjar, tags, target_compatible_with, testonly, visibility)

इस नियम में, android_library और android_binary नियमों के लिए, .aar फ़ाइलों को लाइब्रेरी के तौर पर इस्तेमाल करने की अनुमति है.

उदाहरण

    aar_import(
        name = "google-vr-sdk",
        aar = "gvr-android-sdk/libraries/sdk-common-1.10.0.aar",
    )

    android_binary(
        name = "app",
        manifest = "AndroidManifest.xml",
        srcs = glob(["**.java"]),
        deps = [":google-vr-sdk"],
    )

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए यूनीक नाम.
`aar`	`Label; required` `.aar` फ़ाइल, जिसे इस टारगेट पर निर्भर Android टारगेट को उपलब्ध कराना है.
`exports`	`List of labels; optional` इस नियम पर निर्भर नियमों को एक्सपोर्ट करने के लिए टारगेट. java_library.exports देखें.
`srcjar`	`Label; optional` एक ऐसी JAR फ़ाइल जिसमें AAR की JAR फ़ाइलों का सोर्स कोड होता है.

Android लाइब्रेरी

नियम का सोर्स देखें

android_library(name, deps, srcs, data, assets, assets_dir, compatible_with, custom_package, deprecation, distribs, enable_data_binding, exec_compatible_with, exec_properties, exported_plugins, exports, exports_manifest, features, idl_import_root, idl_parcelables, idl_preprocessed, idl_srcs, javacopts, licenses, manifest, neverlink, plugins, proguard_specs, resource_files, restricted_to, tags, target_compatible_with, testonly, visibility)

यह नियम अपने स्रोतों को .jar फ़ाइल में कंपाइल और संग्रहित करता है. Android रनटाइम लाइब्रेरी android.jar को सीधे तौर पर कंपाइलेशन क्लास पाथ पर डाला गया है.

इंप्लिसिट आउटपुट टारगेट

libname.jar: Java संग्रह.
libname-src.jar (स्रोत जार) वाला संग्रह.
name.aar: एक 'aar' बंडल जिसमें java संग्रह और इस टारगेट के संसाधन हैं. इसमें परिवहन के बंद होने की जानकारी शामिल नहीं होती है.

उदाहरण

इस उदाहरण में idl_import_root को सेट करने का तरीका बताया गया है. //java/bazel/helloandroid/BUILD में शामिल होने दें:

android_library(
    name = "parcelable",
    srcs = ["MyParcelable.java"], # bazel.helloandroid.MyParcelable

    # MyParcelable.aidl will be used as import for other .aidl
    # files that depend on it, but will not be compiled.
    idl_parcelables = ["MyParcelable.aidl"] # bazel.helloandroid.MyParcelable

    # We don't need to specify idl_import_root since the aidl file
    # which declares bazel.helloandroid.MyParcelable
    # is present at java/bazel/helloandroid/MyParcelable.aidl
    # underneath a java root (java/).
)

android_library(
    name = "foreign_parcelable",
    srcs = ["src/android/helloandroid/OtherParcelable.java"], # android.helloandroid.OtherParcelable
    idl_parcelables = [
        "src/android/helloandroid/OtherParcelable.aidl" # android.helloandroid.OtherParcelable
    ],

    # We need to specify idl_import_root because the aidl file which
    # declares android.helloandroid.OtherParcelable is not positioned
    # at android/helloandroid/OtherParcelable.aidl under a normal java root.
    # Setting idl_import_root to "src" in //java/bazel/helloandroid
    # adds java/bazel/helloandroid/src to the list of roots
    # the aidl compiler will search for imported types.
    idl_import_root = "src",
)

# Here, OtherInterface.aidl has an "import android.helloandroid.CallbackInterface;" statement.
android_library(
    name = "foreign_interface",
    idl_srcs = [
        "src/android/helloandroid/OtherInterface.aidl" # android.helloandroid.OtherInterface
        "src/android/helloandroid/CallbackInterface.aidl" # android.helloandroid.CallbackInterface
    ],

    # As above, idl_srcs which are not correctly positioned under a java root
    # must have idl_import_root set. Otherwise, OtherInterface (or any other
    # interface in a library which depends on this one) will not be able
    # to find CallbackInterface when it is imported.
    idl_import_root = "src",
)

# MyParcelable.aidl is imported by MyInterface.aidl, so the generated
# MyInterface.java requires MyParcelable.class at compile time.
# Depending on :parcelable ensures that aidl compilation of MyInterface.aidl
# specifies the correct import roots and can access MyParcelable.aidl, and
# makes MyParcelable.class available to Java compilation of MyInterface.java
# as usual.
android_library(
    name = "idl",
    idl_srcs = ["MyInterface.aidl"],
    deps = [":parcelable"],
)

# Here, ServiceParcelable uses and thus depends on ParcelableService,
# when it's compiled, but ParcelableService also uses ServiceParcelable,
# which creates a circular dependency.
# As a result, these files must be compiled together, in the same android_library.
android_library(
    name = "circular_dependencies",
    srcs = ["ServiceParcelable.java"],
    idl_srcs = ["ParcelableService.aidl"],
    idl_parcelables = ["ServiceParcelable.aidl"],
)

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए यूनीक नाम.
`deps`	`List of labels; optional` उन दूसरी लाइब्रेरी की सूची जिनसे लिंक करना है. इन लाइब्रेरी टाइप का इस्तेमाल किया जा सकता है: `android_library`, `java_library` की `android` कंस्ट्रेंट के साथ और `cc_library` टारगेट शीट के लिए, `.so` नेटिव लाइब्रेरी को रैप या प्रोड्यूस किया जा रहा है.
`srcs`	`List of labels; optional` `.java` या `.srcjar` फ़ाइलों की सूची जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. `.java` प्रकार की `srcs` फ़ाइलें कंपाइल की गई हैं. पढ़ने में आसान के लिए, जनरेट की गई `.java` सोर्स फ़ाइल का नाम `srcs` में डालना सही नहीं है. इसके बजाय, `srcs` पर निर्भर नियम का नाम डालें, जैसा कि यहां बताया गया है. `.srcjar` की `srcs` फ़ाइलें अनपैक की जाती हैं और उन्हें कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule या बिल्ड एक्सटेंशन के साथ, .java फ़ाइलों का सेट जनरेट करना होता है.) अगर `srcs` को हटाया जाता है, तो `deps` में तय सभी डिपेंडेंसी को इस नियम से एक्सपोर्ट किया जाता है. डिपेंडेंसी एक्सपोर्ट करने के बारे में ज़्यादा जानने के लिए, java_library के एक्सपोर्ट देखें. हालांकि, यह व्यवहार जल्द ही रोक दिया जाएगा. इस पर भरोसा न करने की कोशिश करें.
`assets`	`List of labels; optional` पैकेज की जाने वाली एसेट की सूची. आम तौर पर, यह `assets` डायरेक्ट्री में मौजूद सभी फ़ाइलों का `glob` होता है. आपके पास दूसरे नियमों का भी इस्तेमाल करने का विकल्प है. जैसे, कोई फ़ाइल बनाने के लिए इस्तेमाल किए जाने वाले नियम या अन्य पैकेज में मौजूद फ़ाइलें. हालांकि, ऐसा तब ही हो सकता है, जब उन सभी फ़ाइलों को उससे जुड़े पैकेज की `assets_dir` डायरेक्ट्री में देखा जा सकता हो.
`assets_dir`	`String; optional` वह स्ट्रिंग जो `assets` में मौजूद फ़ाइलों का पाथ बताती है. जोड़ी गई `assets` और `assets_dir` जोड़ी गई एसेट, पैकेज की गई एसेट के बारे में बताती हैं. दोनों एसेट के बारे में बताया जाना चाहिए या इनमें से कोई नहीं.
`custom_package`	`String; optional` Java पैकेज जिसके लिए java स्रोत जनरेट किए जाएंगे. आम तौर पर, पैकेज का पता उस डायरेक्ट्री से लिया जाता है जहां BUILD फ़ाइल में नियम शामिल होता है. आप कोई दूसरा पैकेज दे सकते हैं. हालांकि, हम ऐसा करने की सलाह नहीं देते, क्योंकि इससे रनटाइम के दौरान जनरेट की गई अन्य लाइब्रेरी के साथ, क्लासपाथ के कॉन्फ़्लिक्ट से जुड़ी गड़बड़ी आ सकती है.
`enable_data_binding`	`Boolean; optional; default is False` अगर यह नियम सही है, तो यह रिसॉर्स_फ़ाइल एट्रिब्यूट के ज़रिए शामिल लेआउट रिसॉर्स में डेटा बाइंडिंग एक्सप्रेशन प्रोसेस करता है. इस सेटिंग के बिना, डेटा बाइंडिंग एक्सप्रेशन पूरी तरह काम नहीं करते. डेटा बाइंडिंग वाला Android ऐप्लिकेशन बनाने के लिए, आपको ये काम भी करने होंगे: इस एट्रिब्यूट को उन सभी Android नियमों के लिए सेट करें जो कुछ समय के लिए, इस पर निर्भर रहते हैं. ऐसा इसलिए होता है, क्योंकि डिपेंडेंट, रिसोर्स को मर्ज करने की सुविधा का इस्तेमाल करके, नियम की डेटा बाइंडिंग एक्सप्रेशन इनहेरिट कर लेते हैं. इसलिए, उन्हें इन एक्सप्रेशन को पार्स करने के लिए, डेटा बाइंडिंग का इस्तेमाल करके, फ़ील्ड बनाना ज़रूरी होता है. इस प्रॉपर्टी को सेट करने वाले सभी टारगेट में, डेटा बाइंडिंग रनटाइम लाइब्रेरी के लिए एक `deps =` एंट्री जोड़ें. यह लाइब्रेरी, आपके डिपो के सेट अप के हिसाब से तय होती है.
`exported_plugins`	`List of labels; optional` उन लाइब्रेरी में एक्सपोर्ट करने के लिए `java_plugin` की सूची (उदाहरण के लिए, एनोटेशन प्रोसेसर) जो सीधे इस लाइब्रेरी पर निर्भर करती हैं. `java_plugin` की दी गई सूची उन सभी लाइब्रेरी पर लागू हो जाएगी जो सीधे तौर पर इस लाइब्रेरी पर निर्भर करती हैं. ऐसा तब ही होगा, जब उस लाइब्रेरी ने साफ़ तौर पर इन लेबल को `plugins` में बताया हो.
`exports`	`List of labels; optional` `exports` एट्रिब्यूट से जिन नियमों को बंद किया गया है वे सीधे तौर पर `exports` टारगेट पर निर्भर किसी भी नियम की डिपेंडेंसी माने जाते हैं. `exports` उस नियम का सीधे तौर पर हिस्सा नहीं हैं जिससे वे जुड़े हैं.
`exports_manifest`	`Integer; optional; default is 1` इस टारगेट पर निर्भर `android_binary` टारगेट में मेनिफ़ेस्ट एंट्री एक्सपोर्ट करनी हैं या नहीं. `uses-permissions` एट्रिब्यूट कभी भी एक्सपोर्ट नहीं किए जाते.
`idl_import_root`	`String; optional` इस लाइब्रेरी में शामिल id स्रोत वाले java पैकेज ट्री के रूट का पैकेज-रिलेटिव पाथ. इस पाथ का इस्तेमाल, इंपोर्ट किए गए रूट के तौर पर किया जाएगा. हालांकि, इसका इस्तेमाल इस लाइब्रेरी पर निर्भर idl स्रोतों को प्रोसेस करते समय किया जाएगा. जब `idl_import_root` बताया जाता है, तब `idl_parcelables` और `idl_srcs` को `idl_import_root` के तहत जिस ऑब्जेक्ट के बारे में बताया जाता है उसके जावा पैकेज में बताए गए पाथ पर होना चाहिए. जब `idl_import_root` तय न की गई हो, तो `idl_parcelables` और `idl_srcs`, दोनों को पैकेज के ज़रिए Java रूट के तहत बताए गए पाथ पर होना चाहिए. उदाहरण देखें.
`idl_parcelables`	`List of labels; optional` इंपोर्ट के तौर पर देने के लिए, Android IDL की परिभाषाओं की सूची. ये फ़ाइलें ऐसे किसी भी `android_library` टारगेट के लिए इंपोर्ट के तौर पर उपलब्ध कराई जाएंगी जो इस लाइब्रेरी पर निर्भर करता है. इसके अलावा, इन्हें सीधे तौर पर या सीधे तौर पर बंद करने की सुविधा से भी एक्सपोर्ट किया जा सकता है. हालांकि, न तो इन्हें न ही Java या कंपाइल किया जा सकता है. सिर्फ़ वे `.aidl` फ़ाइलें शामिल की जानी चाहिए जो सीधे तौर पर, इस लाइब्रेरी के `.java` सोर्स से जुड़ी हों (उदाहरण के लिए, पार्स किए जा सकने की सुविधा को पसंद के मुताबिक लागू किया जा सकता है). ऐसा न होने पर, `idl_srcs` का इस्तेमाल किया जाना चाहिए. सहायक कंपाइलर उन्हें ढूंढ सकें, इसके लिए उन्हें सही ढंग से रखना चाहिए. इसका मतलब जानने के लिए, idl_import_root का ब्यौरा देखें.
`idl_preprocessed`	`List of labels; optional` इंपोर्ट के तौर पर उपलब्ध कराने के लिए, पहले से प्रोसेस किए गए Android IDL की सूची. ये फ़ाइलें ऐसे किसी भी `android_library` टारगेट के लिए इंपोर्ट के तौर पर उपलब्ध कराई जाएंगी जो इस लाइब्रेरी पर निर्भर करता है. इसके अलावा, इन्हें सीधे तौर पर या सीधे तौर पर बंद करने की सुविधा से भी एक्सपोर्ट किया जा सकता है. हालांकि, न तो इन्हें न ही Java या कंपाइल किया जा सकता है. पहले से प्रोसेस की गई ऐसी `.aidl` फ़ाइलें शामिल की जानी चाहिए जो इस लाइब्रेरी में सीधे तौर पर `.java` सोर्स से जुड़ी हुई हैं (उदाहरण के लिए, पार्सल करने की सुविधा को पसंद के मुताबिक लागू करना). ऐसा न करने पर, Android आईडीएल की उन परिभाषाओं के लिए `idl_srcs` का इस्तेमाल करें जिन्हें Java इंटरफ़ेस का अनुवाद करना है और बिना प्रोसेस की गई AIDL फ़ाइलों के लिए `idl_parcelable` का इस्तेमाल करना चाहिए.
`idl_srcs`	`List of labels; optional` Java इंटरफ़ेस में अनुवाद करने के लिए Android IDL परिभाषाओं की सूची. Java इंटरफ़ेस जनरेट होने के बाद, उन्हें `srcs` के कॉन्टेंट के साथ कंपाइल किया जाएगा. ये फ़ाइलें, ऐसे `android_library` टारगेट के लिए इंपोर्ट के तौर पर उपलब्ध कराई जाएंगी जो इस लाइब्रेरी पर निर्भर करता हो. सीधे तौर पर या सीधे तौर पर इसका इस्तेमाल करके, ट्रांज़िशन किया जा सकता है. सहायक कंपाइलर उन्हें ढूंढ सकें, इसके लिए उन्हें सही ढंग से रखना चाहिए. इसका मतलब जानने के लिए, idl_import_root का ब्यौरा देखें.
`javacopts`	`List of strings; optional` इस टारगेट के लिए ज़्यादा कंपाइलर विकल्प. "वैरिएबल बनाएं" विकल्प और बोन शेल टोकनाइज़ेशन के तहत. यह कंपाइलर विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac में पास कर दिए जाते हैं.
`manifest`	`Label; optional` Android मेनिफ़ेस्ट फ़ाइल का नाम, आम तौर पर `AndroidManifest.xml`. अगर रिसॉर्स_फ़ाइल या एसेट की जानकारी दी गई है, तो वे तय होनी चाहिए.
`neverlink`	`Boolean; optional; default is False` इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए करें, रनटाइम पर नहीं. `neverlink` के तौर पर मार्क किए गए नियम के आउटपुट का इस्तेमाल `.apk` बनाने के लिए नहीं किया जाएगा. अगर लाइब्रेरी एक्ज़ीक्यूशन के दौरान रनटाइम एनवायरमेंट से उपलब्ध कराई जाए, तो यह काम का है.
`plugins`	`List of labels; optional` कंपाइल के समय पर चलने वाले Java कंपाइलर प्लग इन. जब भी यह टारगेट बनाया जाएगा, तब प्लग इन एट्रिब्यूट में दिए गए हर `java_plugin` को चलाया जाएगा. प्लग इन से जनरेट हुए रिसॉर्स को टारगेट के नतीजे के जार में शामिल किया जाएगा.
`proguard_specs`	`List of labels; optional` ProGuard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इससे, ProGuard में इस्तेमाल होने वाली खास जानकारी के सेट के बारे में पता चलेगा. अगर बताया गया हो, तो उसे इस लाइब्रेरी के हिसाब से `android_binary` टारगेट में जोड़ा जाएगा. यहां शामिल फ़ाइलों में समान नियम, जैसे -dontnote, -dontwardn, माना जाने वाले असर, और -keep से शुरू होने वाले नियम होने चाहिए. अन्य विकल्प, सिर्फ़ `android_binary` की ProGuard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि बिना मर्ज वाले वाहनों को मर्ज किया जा सके.
`resource_files`	`List of labels; optional` पैकेज किए जाने वाले संसाधनों की सूची. आम तौर पर, यह `res` डायरेक्ट्री में मौजूद सभी फ़ाइलों का `glob` होता है. जनरेट की गई फ़ाइलों (जेनर से) को यहां लेबल से भी रेफ़र किया जा सकता है. सिर्फ़ एक पाबंदी यह है कि जनरेट किए गए आउटपुट उसी "`res`" डायरेक्ट्री में शामिल होने चाहिए जो किसी दूसरी रिसॉर्स फ़ाइल में शामिल हैं.

Android_platform_test

नियम का सोर्स देखें

android_instrumentation_test(name, data, args, compatible_with, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, licenses, local, restricted_to, shard_count, size, support_apks, tags, target_compatible_with, target_device, test_app, testonly, timeout, toolchains, visibility)

android_instrumentation_test नियम Android के इंस्ट्रूमेंटेशन टेस्ट चलाता है. यह एक एम्युलेटर को शुरू करेगा, जिस ऐप्लिकेशन की जांच की जा रही है, टेस्ट ऐप्लिकेशन, और कोई भी दूसरा ज़रूरी ऐप्लिकेशन इंस्टॉल करेगा और टेस्ट पैकेज में बताए गए टेस्ट चलाएगा.

test_app एट्रिब्यूट, android_binary की जानकारी देता है, जिसमें टेस्ट शामिल होता है. ऐसा करने पर, android_binary इंस्टेंस एट्रिब्यूट की मदद से, android_binary ऐप्लिकेशन की जांच में शामिल हो रहा है.

उदाहरण

# java/com/samples/hello_world/BUILD

android_library(
    name = "hello_world_lib",
    srcs = ["Lib.java"],
    manifest = "LibraryManifest.xml",
    resource_files = glob(["res/**"]),
)

# The app under test
android_binary(
    name = "hello_world_app",
    manifest = "AndroidManifest.xml",
    deps = [":hello_world_lib"],
)

# javatests/com/samples/hello_world/BUILD

android_library(
    name = "hello_world_test_lib",
    srcs = ["Tests.java"],
    deps = [
      "//java/com/samples/hello_world:hello_world_lib",
      ...  # test dependencies such as Espresso and Mockito
    ],
)

# The test app
android_binary(
    name = "hello_world_test_app",
    instruments = "//java/com/samples/hello_world:hello_world_app",
    manifest = "AndroidManifest.xml",
    deps = [":hello_world_test_lib"],
)

android_instrumentation_test(
    name = "hello_world_uiinstrumentation_tests",
    target_device = ":some_target_device",
    test_app = ":hello_world_test_app",
)

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए यूनीक नाम.
`support_apks`	`List of labels; optional` इंस्ट्रूमेंटेशन टेस्ट शुरू होने से पहले, डिवाइस पर इंस्टॉल किए जाने वाले अन्य APKs.
`target_device`	`Label; required` वह android_device जिस पर टेस्ट चलाया जाना चाहिए. पहले से चल रहे या किसी फ़िज़िकल डिवाइस पर एम्युलेटर पर टेस्ट चलाने के लिए, इन तर्कों का इस्तेमाल करें: `--test_output=streamed --test_arg=--device_broker_type=LOCAL_ADB_SERVER --test_arg=--device_serial_number=$device_identifier`
`test_app`	`Label; required` android_binary टारगेट जिसमें टेस्ट क्लास शामिल हों. `android_binary` टारगेट को यह बताना होगा कि वह अपनी `instruments` विशेषता के ज़रिए किस टारगेट की जांच कर रहा है.

Android_टेस्ट करें

नियम का सोर्स देखें

android_local_test(name, deps, srcs, data, args, compatible_with, custom_package, densities, deprecation, enable_data_binding, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, licenses, local, manifest, manifest_values, nocompress_extensions, plugins, resource_configuration_filters, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, visibility)

यह नियम, डिवाइस पर लागू होने वाले नियमों के बजाय, android_library नियमों को लागू करने के लिए है. यह Android Robolectric के टेस्ट फ़्रेमवर्क के साथ काम करता है. Robolectric के टेस्ट लिखने के बारे में विवरण के लिए Android Robolectric साइट देखें.

इंप्लिसिट आउटपुट टारगेट

name.jar: टेस्ट का Java संग्रह.
name-src.jar (स्रोत जार) वाला संग्रह.
name_deploy.jar डिप्लॉयमेंट के लिए सही Java डिप्लॉयमेंट को संग्रहित किया गया है (सिर्फ़ तब बनाया गया, जब साफ़ तौर पर अनुरोध किया गया हो).

उदाहरण

android_local_test के साथ Robolectric का इस्तेमाल करने के लिए, अपनी WORKSPACE फ़ाइल में Robolectric का डेटा स्टोर करने की जगह जोड़ें:

http_archive(
    name = "robolectric",
    urls = ["https://github.com/robolectric/robolectric-bazel/archive/<COMMIT>.tar.gz"],
    strip_prefix = "robolectric-bazel-<COMMIT>",
    sha256 = "<HASH>",
)
load("@robolectric//bazel:robolectric.bzl", "robolectric_repositories")
robolectric_repositories()

इससे Robolectric के लिए ज़रूरी maven_jar नियम लागू हो जाते हैं. इसलिए, हर android_local_test नियम @robolectric//bazel:robolectric पर निर्भर होना चाहिए. नीचे उदाहरण देखें।

android_local_test(
    name = "SampleTest",
    srcs = [
        "SampleTest.java",
    ],
    manifest = "LibManifest.xml",
    deps = [
        ":sample_test_lib",
        "@robolectric//bazel:android-all",
    ],
)

android_library(
    name = "sample_test_lib",
    srcs = [
         "Lib.java",
    ],
    resource_files = glob(["res/**"]),
    manifest = "AndroidManifest.xml",
)

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए यूनीक नाम.
`deps`	`List of labels; optional` जिन लाइब्रेरी की जांच करनी है उनकी सूची. साथ ही, टारगेट में जोड़ी जाने वाली अन्य लाइब्रेरी भी. इस एट्रिब्यूट की ट्रांज़िट समय के दौरान, Android के नियमों में बताए गए सभी रिसॉर्स, एसेट, और मेनिफ़ेस्ट फ़ाइलें टेस्ट में उपलब्ध कराई गई हैं. `deps` में, `android_library`, `aar_import`, `java_import`, `java_library`, और `java_lite_proto_library` के लिए नियमों की सूची दी गई है.
`srcs`	`List of labels; optional` सोर्स फ़ाइलों की सूची जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. नीचे बताए गए खास मामलों को छोड़कर, यह ज़रूरी है. `.java` प्रकार की `srcs` फ़ाइलें कंपाइल की गई हैं. पढ़ने में आसान के लिए, जनरेट की गई `.java` सोर्स फ़ाइल का नाम `srcs` में डालना सही नहीं है. इसके बजाय, `srcs` पर निर्भर नियम का नाम डालें, जैसा कि यहां बताया गया है. `.srcjar` की `srcs` फ़ाइलें अनपैक की जाती हैं और उन्हें कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule या बिल्ड एक्सटेंशन के साथ, .java फ़ाइलों का सेट जनरेट करना होता है.) बाकी सभी फ़ाइलों को तब तक अनदेखा किया जाता है, जब तक ऊपर बताई गई फ़ाइल टाइप की कम से कम एक फ़ाइल मौजूद हो. ऐसा न करने पर, गड़बड़ी के बारे में बताया जाता है. अगर `runtime_deps` के बारे में जानकारी नहीं दी गई है, तो `srcs` एट्रिब्यूट ज़रूरी है और इसे खाली नहीं छोड़ा जा सकता.
`custom_package`	`String; optional` Java पैकेज जिसमें R क्लास जनरेट की जाएगी. डिफ़ॉल्ट रूप से, पैकेज का पता उस डायरेक्ट्री से लगाया जाता है जहां BUILD फ़ाइल में नियम शामिल होता है. अगर आप इस एट्रिब्यूट का इस्तेमाल करते हैं, तो आपको `test_class` का भी इस्तेमाल करना पड़ सकता है.
`densities`	`List of strings; optional` APK बनाते समय फ़िल्टर करने की सुविधा. अगर मेनिफ़ेस्ट में पहले से ही कोई Superstar StarlarkListing नहीं है, तो मेनिफ़ेस्ट में मिलती-जुलती स्क्रीन भी जोड़ी जाएगी.
`enable_data_binding`	`Boolean; optional; default is False` अगर यह नियम सही है, तो इस जांच में इस्तेमाल की गई डेटा-बाइंडिंग डिपेंडेंसी में इस्तेमाल किए गए डेटा बाइंडिंग रेफ़रंस को प्रोसेस किया जाता है. इस सेटिंग के बिना, डेटा-बाइंडिंग डिपेंडेंसी के लिए ज़रूरी बाइनरी-लेवल कोड जनरेट करना ज़रूरी नहीं होगा. साथ ही, इस वजह से बिल्ड फ़ेलियर हो सकते हैं.
`javacopts`	`List of strings; optional` इस लाइब्रेरी के लिए अतिरिक्त कंपाइलर विकल्प. "वैरिएबल बनाएं" विकल्प और बोन शेल टोकनाइज़ेशन के तहत. यह कंपाइलर विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac में पास कर दिए जाते हैं.
`jvm_flags`	`List of strings; optional` इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में एम्बेड करने के लिए फ़्लैग की सूची. $(जगह) और "वैरिएबल बनाएं" विकल्प और बोन शेल टोकनाइज़ेशन के तहत. Java बाइनरी के लिए रैपर स्क्रिप्ट में एक classPATH परिभाषा (सभी निर्भर जार ढूंढने के लिए) शामिल होती है और सही Java इंटरप्रेटर को शुरू करती है. रैपर स्क्रिप्ट से जनरेट होने वाली कमांड लाइन में मुख्य क्लास का नाम शामिल होता है और उसके बाद `"$@"` होता है. इससे आप क्लासनेम के बाद अन्य आर्ग्युमेंट को पास कर सकते हैं. हालांकि, जेवीएम से पार्स किए जाने वाले आर्ग्युमेंट को, कमांड लाइन पर क्लास के नाम से पहले बताया जाना चाहिए. क्लास का नाम सूची में शामिल होने से पहले, `jvm_flags` के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ दिया जाता है. ध्यान दें कि इस एट्रिब्यूट का `_deploy.jar` आउटपुट पर कोई असर नहीं पड़ता*.
`manifest`	`Label; optional` Android मेनिफ़ेस्ट फ़ाइल का नाम, आम तौर पर `AndroidManifest.xml`. अगर संसाधन_फ़ाइलें या एसेट तय किए गए हैं या उनकी जांच में शामिल लाइब्रेरी के किसी भी मेनिफ़ेस्ट में `minSdkVersion` टैग मौजूद है, तो उनकी जानकारी दी जाएगी.
`manifest_values`	`Dictionary: String -> String; optional` मेनिफ़ेस्ट में बदली जाने वाली वैल्यू की डिक्शनरी. मेनिफ़ेस्ट में मौजूद ${name} के किसी भी उदाहरण को इस शब्दकोश में मौजूद नाम से जुड़ी वैल्यू से बदल दिया जाएगा. `applicationId`, `versionCode`, `versionName`, `minSdkVersion`, `targetSdkVersion`, और `maxSdkVersion`, मेनिफ़ेस्ट के भी एट्रिब्यूट को बदल देंगे. साथ ही, sdk टैग का इस्तेमाल करेंगे. `packageName` को नज़रअंदाज़ कर दिया जाएगा. साथ ही, मेनिफ़ेस्ट में पैकेज के बारे में बताए जाने पर, उसे `applicationId` से सेट कर दिया जाएगा. मेनिफ़ेस्ट_वैल्यू का इस्तेमाल करने के लिए, नियम पर मेनिफ़ेस्ट ज़रूरी नहीं है.
`nocompress_extensions`	`List of strings; optional` रिसॉर्स एक्सटेंशन में फ़ाइल एक्सटेंशन की सूची, बिना कंप्रेस किए होनी चाहिए.
`plugins`	`List of labels; optional` कंपाइल के समय पर चलने वाले Java कंपाइलर प्लग इन. जब भी यह नियम बनाया जाएगा, तब इस एट्रिब्यूट में दिया गया हर `java_plugin` चलेगा. लाइब्रेरी, `exported_plugins` का इस्तेमाल करने वाली डिपेंडेंसी से भी प्लग इन इनहेरिट कर सकती है. प्लग इन से जनरेट हुए रिसॉर्स, इस नियम के नतीजे वाले जार में शामिल हो जाएंगे.
`resource_configuration_filters`	`List of strings; optional` रिसॉर्स कॉन्फ़िगरेशन फ़िल्टर की सूची, जैसे कि 'en'. इसकी मदद से, apk में मौजूद रिसॉर्स को सिर्फ़ 'en' कॉन्फ़िगरेशन में मौजूद संसाधनों तक सीमित किया जाता है.
`resource_jars`	`List of labels; optional` अमान्य: इसके बजाय java_import और deps या रनटाइम_deps का उपयोग करें.
`resource_strip_prefix`	`String; optional` Java संसाधनों से स्ट्रिप के लिए पाथ प्रीफ़िक्स. अगर बताया गया हो, तो इस पाथ प्रीफ़िक्स को `resources` एट्रिब्यूट में मौजूद हर फ़ाइल से हटा दिया जाता है. यह एक गड़बड़ी है कि किसी संसाधन फ़ाइल का इस डायरेक्ट्री में न होना. अगर कुछ भी तय नहीं किया जाता है, तो रिसॉर्स फ़ाइल का पाथ, उसी एलिमेंट के हिसाब से तय किया जाता है जो सोर्स फ़ाइलों के Java पैकेज की तरह होता है. उदाहरण के लिए, `stuff/java/foo/bar/a.txt` पर एक सोर्स फ़ाइल `foo/bar/a.txt` पर मौजूद होगी.
`runtime_deps`	`List of labels; optional` लाइब्रेरी को सिर्फ़ फ़ाइनल बाइनरी के लिए उपलब्ध कराना या सिर्फ़ रनटाइम के दौरान टेस्ट करना. सामान्य `deps` की तरह, ये रनटाइम क्लास पाथ पर दिखेंगे. हालांकि, इनकी तरह कंपाइल होने के समय वाले क्लास पाथ पर ये नहीं दिखेंगे. यहां रनटाइम के हिसाब से सभी डिपेंडेंसी यहां दी जानी चाहिए. डिपेंडेंसी-विश्लेषण टूल को `runtime_deps` और `deps`, दोनों में दिखने वाले टारगेट को अनदेखा करना चाहिए.
`stamp`	`Integer; optional; default is 0` क्या बिल्ड जानकारी को बाइनरी में एन्कोड करना है. वैल्यू इस तरह की हो सकती हैं: `stamp = 1`: बिल्ड की जानकारी को हमेशा बाइनरी में स्टैंप करें. भले ही, `--nostamp` बिल्ड में जानकारी दी गई हो. इस सेटिंग से बचना चाहिए, क्योंकि इससे बाइनरी और उस पर निर्भर सभी डाउनस्ट्रीम कार्रवाइयों के लिए, कैश मेमोरी में सेव करने की सुविधा बंद हो जाती है. `stamp = 0`: बिल्ड की जानकारी को हमेशा स्थायी वैल्यू से बदलें. इससे, बिल्ड को कैश मेमोरी में सेव करने में आसानी होती है. `stamp = -1`: बिल्ड की जानकारी को एम्बेड करने का तरीका, `--[no]stamp` फ़्लैग से कंट्रोल होता है. स्टैंप वाली बाइनरी को तब तक नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी बदल जाती हैं.
`test_class`	`String; optional` टेस्टिंग रनर से लोड की जाने वाली Java क्लास. यह एट्रिब्यूट, उस Java क्लास का नाम बताता है जिसे जांच के लिए चलाया जाना है. इसे सेट करना बहुत कम होता है. अगर यह आर्ग्युमेंट मिटाया जाता है, तो उस `android_local_test` क्लास का इस्तेमाल किया जाएगा जिसका नाम इस `android_local_test` नियम से मेल खाता है. टेस्ट क्लास को `org.junit.runner.RunWith` के साथ एनोटेट करना ज़रूरी है.
`use_launcher`	`Boolean; optional; default is True` बाइनरी को कस्टम लॉन्चर का इस्तेमाल करना चाहिए या नहीं. अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो लॉन्चर एट्रिब्यूट और इससे जुड़े `--java_launcher` फ़्लैग को अनदेखा कर दिया जाएगा.

Android डिवाइस

नियम का सोर्स देखें

android_device(name, cache, compatible_with, default_properties, deprecation, distribs, exec_compatible_with, exec_properties, features, horizontal_resolution, licenses, platform_apks, ram, restricted_to, screen_density, system_image, tags, target_compatible_with, testonly, vertical_resolution, visibility, vm_heap)

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

यह नियम बेज़ल टेस्ट और ब्लेज़ रन के लिए --run_under फ़्लैग के लिए सही टारगेट है. यह एक एम्युलेटर शुरू करता है, टेस्ट किए जा रहे/एम्युलेटर को चलाए जा रहे टारगेट को कॉपी करता है और इसकी जांच करता है या इसे सही तरीके से चलाता है.

अगर दिया गया system_image X86 आधारित है और इसे ज़्यादातर I686 सीपीयू आर्किटेक्चर के लिए ऑप्टिमाइज़ किया गया है, तो android_device केवीएम इमेज बनाने में मदद करता है. केवीएम का इस्तेमाल करने के लिए, android_device नियम में tags = ['requires-kvm'] जोड़ें.

इंप्लिसिट आउटपुट टारगेट

name_images/userdata.dat: एम्युलेटर को शुरू करने के लिए, इमेज फ़ाइलें और स्नैपशॉट शामिल हैं
name_images/emulator-meta-data.pb: इसमें सीरियल नंबर को एम्युलेटर को पास करने के लिए ज़रूरी जानकारी शामिल होती है.

उदाहरण

नीचे दिए गए उदाहरण में, android_device को इस्तेमाल करने का तरीका बताया गया है. //java/android/helloandroid/BUILD में शामिल है

android_device(
    name = "nexus_s",
    cache = 32,
    default_properties = "nexus_s.properties",
    horizontal_resolution = 480,
    ram = 512,
    screen_density = 233,
    system_image = ":emulator_images_android_16_x86",
    vertical_resolution = 800,
    vm_heap = 32,
)

filegroup(
    name = "emulator_images_android_16_x86",
    srcs = glob(["androidsdk/system-images/android-16/**"]),
)

//java/android/helloandroid/nexus_s.properties में शामिल है:

ro.product.brand=google
ro.product.device=crespo
ro.product.manufacturer=samsung
ro.product.model=Nexus S
ro.product.name=soju

इस नियम से इमेज और एक स्टार्ट स्क्रिप्ट जनरेट होगी. bazel यहां लागू करके एम्युलेटर शुरू कर सकते हैं :nexus_s -- --action=start. स्क्रिप्ट में ये फ़्लैग दिखते हैं:

--adb_port: adb जिस पर दिखाना है. अगर आप एम्युलेटर को adb निर्देश देना चाहते हैं, तो आप इस पोर्ट से adb कनेक्ट करेंगे.
--emulator_port: एम्युलेटर का टेलनेट मैनेजमेंट कंसोल चालू करने वाला पोर्ट.
--enable_display: सही होने पर एम्युलेटर को डिसप्ले से शुरू करता है (डिफ़ॉल्ट तौर पर गलत).
--action: शुरू करें या बंद करें.
--apks_to_install: एम्युलेटर पर इंस्टॉल किए जाने वाले apk की सूची.

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए यूनीक नाम.
`cache`	`Integer; required` एम्युलेटर के कैश पार्टिशन का मेगाबाइट में साइज़. इसका कम से कम मान 16 मेगाबाइट है.
`default_properties`	`Label; optional` एम्युलेटर पर /default.prop में रखी जाने वाली सिंगल प्रॉपर्टी फ़ाइल. इसकी मदद से, नियम बनाने वाला टूल एम्युलेटर को इस तरह से कॉन्फ़िगर कर सकता है कि वह असल डिवाइस की तरह दिखे. खास तौर पर, उसकी UserAgent स्ट्रिंग और अन्य व्यवहार को कंट्रोल करने पर, जो ऐप्लिकेशन या सर्वर को किसी खास डिवाइस पर अलग तरीके से काम करता है. इस फ़ाइल की प्रॉपर्टी, रीड ओनली प्रॉपर्टी को बदल देंगी. ये प्रॉपर्टी एम्युलेटर जैसे कि ro.product.model से सेट की जाती हैं.
`horizontal_resolution`	`Integer; required` एम्युलेट करने के लिए, पिक्सल में हॉरिज़ॉन्टल स्क्रीन रिज़ॉल्यूशन. कम से कम वैल्यू 240 है.
`platform_apks`	`List of labels; optional` बूट के समय डिवाइस पर इंस्टॉल किए जाने वाले apk की सूची.
`ram`	`Integer; required` डिवाइस में एम्युलेट करने के लिए मेगाबाइट में रैम की मात्रा. यह पूरे डिवाइस के लिए है, न कि सिर्फ़ डिवाइस पर इंस्टॉल किए गए किसी खास ऐप्लिकेशन के लिए. कम से कम वैल्यू 64 मेगाबाइट है.
`screen_density`	`Integer; required` पिक्सल प्रति इंच में एम्युलेट की गई स्क्रीन का घनत्व. इसकी कम से कम वैल्यू 30 ppi है.
`system_image`	`Label; required` ऐसा फ़ाइल ग्रुप जिसमें ये फ़ाइलें मौजूद हैं: System.img: सिस्टम पार्टीशन kernel-qemu: Linux कर्नेल एम्युलेटर लोड होगा: ramdisk.img: बूट समय पर उपयोग करने के लिए आंतरिक चित्र userdata.img: शुरुआती उपयोगकर्ता के डेटा का बंटवारा सोर्स.प्रॉपर्टी: ऐसी प्रॉपर्टी फ़ाइल जिसमें इमेज के बारे में जानकारी होती है ये फ़ाइलें, Android sdk वाले ऐप्लिकेशन का हिस्सा हैं या तीसरे पक्षों की ओर से उपलब्ध कराई गई हैं. उदाहरण के लिए, Intel, x86 इमेज उपलब्ध कराता है.
`vertical_resolution`	`Integer; required` वर्टिकल स्क्रीन रिज़ॉल्यूशन को एम्युलेट करने के लिए, पिक्सल में रखें. कम से कम वैल्यू 240 है.
`vm_heap`	`Integer; required` Android के लिए, हर प्रोसेस के लिए Android के लिए हीप के साइज़ का इस्तेमाल, मेगाबाइट में किया जाएगा. कम से कम वैल्यू 16 मेगाबाइट है.

android_ndk_repository

नियम का सोर्स देखें

android_ndk_repository(name, api_level, path, repo_mapping)

Bazel को नेटिव कोड के साथ Android टारगेट बनाने के लिए, Android NDK का इस्तेमाल करने के लिए कॉन्फ़िगर करता है.

ध्यान दें कि android_ndk_repository को लागू करने की जगह Starlark पर लागू की जा रही है. NDK के भविष्य के वर्शन 25 और उसके बाद वाले वर्शन के लिए सहायता को android_ndk_repository के Starlark वर्शन में लागू किया जाएगा. Starlark वर्शन के लिए rule_android_ndk देखें.

ध्यान रखें कि Android के लिए बिल्डिंग बनाने के लिए, आपकी WORKSPACE फ़ाइल में android_sdk_repository का नियम होना भी ज़रूरी है.

ज़्यादा जानकारी के लिए, Bzel के साथ Android NDK का इस्तेमाल करने के बारे में पूरा दस्तावेज़ पढ़ें.

उदाहरण

android_ndk_repository(
    name = "androidndk",
)

ऊपर दिया गया उदाहरण, $ANDROID_NDK_HOME से आपके Android NDK का पता लगाएगा. साथ ही, यह इसमें काम करने वाले सबसे एपीआई लेवल का भी पता लगाएगा.

android_ndk_repository(
    name = "androidndk",
    path = "./android-ndk-r20",
    api_level = 24,
)

ऊपर दिया गया उदाहरण, ./android-ndk-r20 में आपके फ़ाइल फ़ोल्डर में मौजूद Android एनडीके का इस्तेमाल करेगा. आपका JNI कोड कंपाइल करते समय, यह एपीआई लेवल 24 लाइब्रेरी का इस्तेमाल करेगा.

सीपीयू की सुविधाएं

Android NDK में, cpufeatures लाइब्रेरी की सुविधा होती है. इसका इस्तेमाल रनटाइम के दौरान, डिवाइस के सीपीयू का पता लगाने के लिए किया जा सकता है. नीचे दिए गए उदाहरण में Bazel के साथ सीपीयू की सुविधाओं को इस्तेमाल करने का तरीका बताया गया है.

# jni.cc
#include "ndk/sources/android/cpufeatures/cpu-features.h"
...

# BUILD
cc_library(
    name = "jni",
    srcs = ["jni.cc"],
    deps = ["@androidndk//:cpufeatures"],
)

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए यूनीक नाम.
`api_level`	`Integer; optional; nonconfigurable; default is 0` उसके साथ काम करने के लिए Android API लेवल. अगर बताया नहीं गया है, तो इंस्टॉल किए गए सबसे बड़े एपीआई लेवल का इस्तेमाल किया जाएगा.
`path`	`String; optional; nonconfigurable` Android एनडीके का पूरा या मिलता-जुलता पाथ. यह एट्रिब्यूट या `$ANDROID_NDK_HOME` एनवायरमेंट वैरिएबल सेट करना ज़रूरी है. Android एनडीके को Android डेवलपर साइट से डाउनलोड किया जा सकता है.
`repo_mapping`	`Dictionary: String -> String; optional` स्थानीय डेटा संग्रह स्थान से लेकर ग्लोबल डेटा स्टोर करने की जगह तक नाम का शब्दकोश. इससे, डेटा स्टोर करने की जगह के लिए, डिपेंडेंसी डिपेंडेंसी पर कंट्रोल किया जा सकता है. उदाहरण के लिए, एंट्री `"@foo": "@bar"` में बताया गया है कि किसी भी समय के लिए इस डेटा स्टोर करने की जगह `"@foo"` (जैसे कि `"@foo//some:target"` पर निर्भरता) पर निर्भर होती है. असल में, इसे दुनिया भर में बताई गई `"@bar"` (`"@bar//some:target"`) के अंदर ही, डिपेंडेंसी को हल करना चाहिए.

Android_sdk_Repository

नियम का सोर्स देखें

android_sdk_repository(name, api_level, build_tools_version, path, repo_mapping)

Android टारगेट को बनाने में मदद करने के लिए, स्थानीय Android SDK का इस्तेमाल करने के लिए, Bazel को कॉन्फ़िगर करता है.

उदाहरण

Bazel के लिए Android SDK टूल सेट अप करने के लिए, सबसे ज़रूरी यह है कि आप WORKSPACE फ़ाइल में "androidsdk" नाम का android_sdk_repository नियम रखें और $ANDROID_HOMEपरिवेश वैरिएबल को अपने Android SDK टूल के पाथ पर सेट करें. Bazel सबसे ऊंचे Android API लेवल का उपयोग करेगा और डिफ़ॉल्ट रूप से Android SDK में इंस्टॉल किए गए टूल वर्शन का उपयोग करेगा.

android_sdk_repository(
    name = "androidsdk",
)

फिर से जनरेट किए जा सकने वाले बिल्ड को पक्का करने के लिए, path, api_level, और build_tools_version एट्रिब्यूट को खास वैल्यू पर सेट किया जा सकता है. अगर Android SDK टूल में, एपीआई लेवल या बिल्ड टूल का वर्शन इंस्टॉल नहीं किया गया है, तो यह वर्शन काम नहीं करेगा.

android_sdk_repository(
    name = "androidsdk",
    path = "./sdk",
    api_level = 19,
    build_tools_version = "25.0.0",
)

ऊपर दिया गया उदाहरण, Android SDK के फ़ाइल फ़ोल्डर से जुड़े पाथ का इस्तेमाल करने के बारे में भी बताता है. अगर Android SDK टूल, आपके Bazel Workspace का हिस्सा है, तो यह तरीका आपके काम का होता है. उदाहरण के लिए, अगर SDK टूल को वर्शन कंट्रोल में चुना गया है.

लाइब्रेरी की मदद करें

सहायता लाइब्रेरी, Android SDK Manager में "Android Support Repository" के तौर पर उपलब्ध हैं. यह Android की सामान्य लाइब्रेरी का वर्शन है, जैसे कि Support और AppCompat लाइब्रेरी. इसे स्थानीय Maven के डेटा स्टोर करने की जगह के तौर पर पैक किया जाता है. android_sdk_repository, इनमें से हर लाइब्रेरी के लिए Bazel टारगेट जनरेट करता है. इनका इस्तेमाल android_binary और android_library टारगेट की डिपेंडेंसी में किया जा सकता है.

जनरेट किए गए टारगेट के नाम Android सहायता डेटा संग्रह स्थान में लाइब्रेरी के Maven निर्देशांकों से लिए जाते हैं और इन्हें @androidsdk//${group}:${artifact}-${version} के रूप में फ़ॉर्मैट किया जाता है. नीचे दिए गए उदाहरण में बताया गया है कि android_library, वर्शन सात वर्शन वाली Appcompat लाइब्रेरी के 25.0.0 वर्शन के आधार पर कैसे काम कर सकता है.

android_library(
    name = "lib",
    srcs = glob(["*.java"]),
    manifest = "AndroidManifest.xml",
    resource_files = glob(["res/**"]),
    deps = ["@androidsdk//com.android.support:appcompat-v7-25.0.0"],
)

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए यूनीक नाम.
`api_level`	`Integer; optional; nonconfigurable; default is 0` डिफ़ॉल्ट रूप से बनाया जाने वाला Android एपीआई लेवल. अगर बताया नहीं गया है, तो इंस्टॉल किए गए सबसे बड़े एपीआई लेवल का इस्तेमाल किया जाएगा. दिए गए बिल्ड के लिए इस्तेमाल किए गए एपीआई लेवल को `android_sdk` फ़्लैग से बदला जा सकता है. `android_sdk_repository`, SDK टूल में इंस्टॉल किए गए हर एपीआई लेवल के लिए `android_sdk` टारगेट बनाता है. इसमें `@androidsdk//:sdk-${level}` नाम होता है, भले ही इस एट्रिब्यूट को चुना गया हो या नहीं. उदाहरण के लिए, नॉन-डिफ़ॉल्ट एपीआई लेवल से बनाने के लिए: `bazel build --android_sdk=@androidsdk//:sdk-19 //java/com/example:app`. `android_sdk_repository` की ओर से जनरेट किए गए सभी `android_sdk` टारगेट को देखने के लिए, आप `bazel query "kind(android_sdk, @androidsdk//...)"` चला सकते हैं.
`build_tools_version`	`String; optional; nonconfigurable` 'Android SDK टूल' का वर्शन, जिसका इस्तेमाल Android SDK में किया जा सकता है. अगर कुछ भी तय नहीं किया गया है, तो इंस्टॉल किए गए सबसे नए बिल्ड टूल वर्शन का इस्तेमाल किया जाएगा. Bazel में बिल्ड टूल का 30.0.0 या इसके बाद का वर्शन होना ज़रूरी है.
`path`	`String; optional; nonconfigurable` किसी Android SDK टूल का पूरा या रिलेटिव पाथ. यह एट्रिब्यूट या `$ANDROID_HOME` एनवायरमेंट वैरिएबल सेट करना ज़रूरी है. Android SDK टूल, Android डेवलपर साइट से डाउनलोड किया जा सकता है.
`repo_mapping`	`Dictionary: String -> String; optional` स्थानीय डेटा संग्रह स्थान से लेकर ग्लोबल डेटा स्टोर करने की जगह तक नाम का शब्दकोश. इससे, डेटा स्टोर करने की जगह के लिए, डिपेंडेंसी डिपेंडेंसी पर कंट्रोल किया जा सकता है. उदाहरण के लिए, एंट्री `"@foo": "@bar"` में बताया गया है कि किसी भी समय के लिए इस डेटा स्टोर करने की जगह `"@foo"` (जैसे कि `"@foo//some:target"` पर निर्भरता) पर निर्भर होती है. असल में, इसे दुनिया भर में बताई गई `"@bar"` (`"@bar//some:target"`) के अंदर ही, डिपेंडेंसी को हल करना चाहिए.