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

Android के नियम

नियम

android_binary
aar_import
android_library
android_instrumentation_test
android_local_test
android_device
android_ndk_repository
android_sdk_repository

android_binary

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` कंस्ट्रेंट के साथ, और Android टारगेट प्लैटफ़ॉर्म के लिए, `.so` नेटिव लाइब्रेरी `cc_library` रैप कर रहे हैं या बना रहे हैं.
`srcs`	`List of labels; optional` सोर्स फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. `.java` टाइप की `srcs` फ़ाइलें कंपाइल की गईं. पढ़ने में आसान बनाने के लिए, जनरेट की गई `.java` सोर्स फ़ाइल का नाम `srcs` में डालना सही नहीं है. इसके बजाय, जिस नियम पर निर्भर है उसे `srcs` में डालें, जैसा कि यहां बताया गया है. `.srcjar` टाइप की `srcs` फ़ाइलों को अनपैक और कंपाइल किया गया है. (अगर आपको जेनरूल या बिल्ड एक्सटेंशन के साथ .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 Bug के लिए एक ऐसी सुविधा है, जो अब काम नहीं करती है, जिसे 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 वैल्यू अच्छी है. ध्यान दें कि फ़ाइनल ऐप्लिकेशन में हर शार्ड के नतीजे में कम से कम एक dex मिलेगा. इस वजह से, रिलीज़ बाइनरी के लिए इसे 1 से ज़्यादा पर सेट करने का सुझाव नहीं दिया जाता.
`dexopts`	`List of strings; optional` क्लास.dex जनरेट करते समय, dx टूल के लिए अतिरिक्त कमांड लाइन फ़्लैग. यह नीति, "बनाएं वैरिएबल" के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करती है.
`enable_data_binding`	`Boolean; optional; default is False` अगर सही है, तो यह नियम resource_files एट्रिब्यूट के ज़रिए शामिल किए गए लेआउट रिसॉर्स में, डेटा बाइंडिंग एक्सप्रेशन को प्रोसेस करता है. इस सेटिंग के बिना, डेटा बाइंडिंग एक्सप्रेशन से बिल्ड पूरे नहीं होते. डेटा बाइंडिंग वाला Android ऐप्लिकेशन बनाने के लिए, आपको ये काम भी करने होंगे: इस एट्रिब्यूट को Android के उन सभी नियमों के लिए सेट करें जो इस पर निर्भर करते हैं. ऐसा इसलिए है, क्योंकि डिपेंडेंसी, संसाधन को मर्ज करके, नियम के डेटा बाइंडिंग एक्सप्रेशन को इनहेरिट करते हैं. इसलिए उन्हें उन एक्सप्रेशन को पार्स करने के लिए, डेटा बाइंडिंग के साथ भी बनाना होगा. इस एट्रिब्यूट को सेट करने वाले सभी टारगेट के लिए, डेटा बाइंडिंग रनटाइम लाइब्रेरी के लिए `deps =` एंट्री जोड़ें. यह लाइब्रेरी आपके डिपो के सेटअप के आधार पर तय होती है.
`incremental_dexing`	`Integer; optional; nonconfigurable; default is -1` टारगेट को हर हाल में, इंक्रीमेंटल डेक्स, ओवरराइडिंग डिफ़ॉल्ट, और --incremental_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`. अगर research_files या एसेट के बारे में जानकारी दी गई है, तो यह बताना ज़रूरी है.
`manifest_values`	`Dictionary: String -> String; optional` मेनिफ़ेस्ट में बदली जाने वाली वैल्यू की डिक्शनरी. मेनिफ़ेस्ट में मौजूद ${name} के किसी भी इंस्टेंस को, इस शब्दकोश में दिए गए नाम से जुड़ी वैल्यू से बदल दिया जाएगा. appId, versionCode, versionName, minSdkVersion, targetSdkVersion और maxSdkVersion जब Manifest_Merger लेगसी पर सेट है, तो सिर्फ़ appId, 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 के लिए मैपिंग के तौर पर इस्तेमाल की जाने वाली फ़ाइल. फ़ाइल में "शब्दों" को लाइन से अलग किया जाता है, ताकि अस्पष्ट बनाने के दौरान क्लास और सदस्यों का नाम बदला जा सके.
`proguard_apply_mapping`	`Label; optional` ProGuard के लिए मैपिंग के तौर पर इस्तेमाल की जाने वाली फ़ाइल. मैपिंग फ़ाइल, `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_resource_shrinking फ़्लैग से कंट्रोल किया जाता है.

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` इस टारगेट पर निर्भर Android टारगेट को उपलब्ध कराने के लिए, `.aar` फ़ाइल.
`exports`	`List of labels; optional` इस नियम पर निर्भर नियमों को एक्सपोर्ट करने के लिए टारगेट. java_library.exports देखें.
`srcjar`	`Label; optional` ऐसी JAR फ़ाइल जिसमें AAR में कंपाइल की गई JAR फ़ाइलों का सोर्स कोड होता है.

android_library

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: एक Android 'aar' बंडल जिसमें इस टारगेट के JavaScript संग्रह और संसाधन शामिल हैं. इसमें ट्रांज़िटिव क्लोज़िंग डेटा शामिल नहीं है.

उदाहरण

इस उदाहरण में, 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` कंस्ट्रेंट के साथ और Android टारगेट प्लैटफ़ॉर्म के लिए, `cc_library` नेटिव लाइब्रेरी `.so` रैप करना या बनाना.
`srcs`	`List of labels; optional` `.java` या `.srcjar` फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. `.java` टाइप की `srcs` फ़ाइलें कंपाइल की गईं. पढ़ने में आसान बनाने के लिए, जनरेट की गई `.java` सोर्स फ़ाइल का नाम `srcs` में डालना सही नहीं है. इसके बजाय, जिस नियम पर निर्भर है उसे `srcs` में डालें, जैसा कि यहां बताया गया है. `.srcjar` टाइप की `srcs` फ़ाइलों को अनपैक और कंपाइल किया गया है. (अगर आपको जेनरूल या बिल्ड एक्सटेंशन के साथ .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` अगर सही है, तो यह नियम resource_files एट्रिब्यूट के ज़रिए शामिल किए गए लेआउट रिसॉर्स में, डेटा बाइंडिंग एक्सप्रेशन को प्रोसेस करता है. इस सेटिंग के बिना, डेटा बाइंडिंग एक्सप्रेशन से बिल्ड पूरे नहीं होते. डेटा बाइंडिंग वाला 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` इस लाइब्रेरी में शामिल आईडील सोर्स वाले JavaScript पैकेज ट्री के रूट का पैकेज-रिलेटिव पाथ. इस लाइब्रेरी पर निर्भर आईडीएल सोर्स को प्रोसेस करते समय, इस पाथ का इस्तेमाल इंपोर्ट रूट के तौर पर किया जाएगा. अगर `idl_import_root` बताया गया है, तो `idl_parcelables` और `idl_srcs`, दोनों उस पाथ पर होने चाहिए जो `idl_import_root` में दिखाए जाने वाले ऑब्जेक्ट के Java पैकेज के बताए गए पाथ पर होना चाहिए. अगर `idl_import_root` के बारे में जानकारी नहीं दी गई है, तो `idl_parcelables` और `idl_srcs`, दोनों उन पाथ पर होने चाहिए जो Java रूट के तहत उनके पैकेज में बताए गए पाथ पर होते हैं. उदाहरण देखें.
`idl_parcelables`	`List of labels; optional` इंपोर्ट के तौर पर सप्लाई करने के लिए, Android IDL की परिभाषाओं की सूची. ये फ़ाइलें, इस लाइब्रेरी पर निर्भर किसी भी `android_library` टारगेट के लिए, इंपोर्ट के तौर पर उपलब्ध कराई जाएंगी. ये फ़ाइलें, सीधे तौर पर या इसके ट्रांज़िटिव क्लोज़र के ज़रिए उपलब्ध होंगी. हालांकि, इनका अनुवाद Java में या कंपाइल नहीं किया जाएगा. इस लाइब्रेरी में मौजूद `.java` सोर्स से सीधे तौर पर जुड़ी `.aidl` फ़ाइलें ही शामिल की जानी चाहिए.उदाहरण के लिए, पार्सल किए जा सकने वाले कॉन्टेंट को अपने हिसाब से लागू किया जा सकता है. ऐसा न होने पर, `idl_srcs` का इस्तेमाल किया जाना चाहिए. इन फ़ाइलों को सही तरीके से रखा जाना चाहिए, ताकि एडल कंपाइलर उन्हें ढूंढ सके. इसका मतलब जानने के लिए, idl_Import_root की जानकारी देखें.
`idl_preprocessed`	`List of labels; optional` इंपोर्ट के तौर पर उपलब्ध कराने के लिए, पहले से प्रोसेस किए गए Android आईडीएल की परिभाषाओं की सूची. ये फ़ाइलें, इस लाइब्रेरी पर निर्भर किसी भी `android_library` टारगेट के लिए, इंपोर्ट के तौर पर उपलब्ध कराई जाएंगी. ये फ़ाइलें, सीधे तौर पर या इसके ट्रांज़िटिव क्लोज़र के ज़रिए उपलब्ध होंगी. हालांकि, इनका अनुवाद Java में या कंपाइल नहीं किया जाएगा. पहले से प्रोसेस की गई सिर्फ़ ऐसी `.aidl` फ़ाइलें ही शामिल की जानी चाहिए जो इस लाइब्रेरी में मौजूद `.java` सोर्स से सीधे तौर पर मेल खाती हों (जैसे, पार्सलेबल को अपने हिसाब से लागू करना). इसके अलावा, Android आईडीएल की उन परिभाषाओं के लिए `idl_srcs` का इस्तेमाल करें जिन्हें Java इंटरफ़ेस में अनुवाद करना है और पहले से प्रोसेस नहीं की गई एआईडीएल फ़ाइलों के लिए `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`. अगर research_files या एसेट के बारे में जानकारी दी गई है, तो यह बताना ज़रूरी है.
`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, -dontwarn, गुमाद रखने वाले और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ `android_binary` के proGuard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि नॉन-टॉलॉजिकल मर्जिंग हो.
`resource_files`	`List of labels; optional` पैकेज किए जाने वाले संसाधनों की सूची. आम तौर पर, यह `res` डायरेक्ट्री में मौजूद सभी फ़ाइलों का `glob` होता है. जनरेट की गई फ़ाइलों (जेनरूल से) का रेफ़रंस यहां लेबल में भी दिया जा सकता है. इस शर्त पर सिर्फ़ यह पाबंदी है कि जनरेट किए गए आउटपुट उसी "`res`" डायरेक्ट्री में हों, जिसमें शामिल की गई अन्य रिसॉर्स फ़ाइलें मौजूद हैं.

android_instrumentation_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_local_test

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's डेटा संग्रह स्थान जोड़ें:

http_archive(
    name = "robolectric",
    urls = ["https://github.com/robolectric/robolectric/archive/<COMMIT>.tar.gz"],
    strip_prefix = "robolectric-<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:robolectric",
    ],
)

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` फ़ाइलों को अनपैक और कंपाइल किया गया है. (अगर आपको जेनरूल या बिल्ड एक्सटेंशन के साथ .java फ़ाइलों का सेट जनरेट करना हो, तो यह काम का है.) दूसरी सभी फ़ाइलों को तब तक अनदेखा किया जाता है, जब तक ऊपर बताए गए फ़ाइल टाइप की कम से कम एक फ़ाइल मौजूद हो. ऐसा न होने पर, गड़बड़ी का मैसेज दिखता है. `srcs` एट्रिब्यूट ज़रूरी है और जब तक `runtime_deps` बताया नहीं गया हो, तब तक इसे खाली नहीं छोड़ा जा सकता.
`custom_package`	`String; optional` वह Java पैकेज जिसमें R कैटगरी जनरेट की जाएगी. डिफ़ॉल्ट रूप से, पैकेज का अनुमान उस डायरेक्ट्री से लगाया जाता है जहां BUILD फ़ाइल मौजूद होती है. अगर इस एट्रिब्यूट का इस्तेमाल किया जाता है, तो आपको `test_class` का भी इस्तेमाल करना पड़ सकता है.
`densities`	`List of strings; optional` apk बनाते समय फ़िल्टर करने के लिए डेंसिटी. अगर मेनिफ़ेस्ट में सुपरसेट StarlarkListing पहले से मौजूद नहीं है, तो मेनिफ़ेस्ट में, इससे जुड़ा स्क्रीन-स्क्रीन सेक्शन भी जोड़ दिया जाएगा.
`enable_data_binding`	`Boolean; optional; default is False` सही होने पर, यह नियम डेटा बाइंडिंग रेफ़रंस को प्रोसेस करता है. यह उन डिपेंडेंसी को प्रोसेस करता है जिनका इस्तेमाल इस टेस्ट में, डेटा-बाइंडिंग के लिए किया जाता है. इस सेटिंग के बिना, डेटा-बाइंडिंग डिपेंडेंसी के लिए बाइनरी-लेवल पर कोड जनरेट करने की ज़रूरत नहीं होगी. इसकी वजह से, बिल्ड काम करना बंद कर सकता है.
`javacopts`	`List of strings; optional` इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह नीति, "बनाएं वैरिएबल" के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करती है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं.
`jvm_flags`	`List of strings; optional` इस बाइनरी को चलाने के लिए, रैपर स्क्रिप्ट में एम्बेड किए जाने वाले फ़्लैग की सूची. यह विकल्प $(location) और "Make वैरिएबल" के बदले लागू होता है. साथ ही, बर्न शेल टोकनाइज़ेशन पर निर्भर करता है. Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल है (सभी डिपेंडेंट जार को ढूंढने के लिए) और सही Java इंटरप्रेटर को शुरू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम होता है. इसके बाद, `"$@"` होता है, ताकि क्लास के नाम के बाद, अन्य आर्ग्युमेंट को पास किया जा सके. हालांकि, जेवीएम से पार्स करने के लिए बने तर्कों को, कमांड लाइन पर क्लासनाम से पहले बताया जाना चाहिए. क्लास का नाम शामिल करने से पहले, `jvm_flags` के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ दिया जाता है. ध्यान दें कि इस एट्रिब्यूट का `_deploy.jar` आउटपुट पर कोई असर नहीं पड़ता*.
`manifest`	`Label; optional` Android मेनिफ़ेस्ट फ़ाइल का नाम, आम तौर पर `AndroidManifest.xml`. अगर research_files या एसेट को परिभाषित किया गया है या टेस्ट की जा रही लाइब्रेरी के किसी मेनिफ़ेस्ट में `minSdkVersion` टैग है, तो इस बारे में बताना ज़रूरी है.
`manifest_values`	`Dictionary: String -> String; optional` मेनिफ़ेस्ट में बदली जाने वाली वैल्यू की डिक्शनरी. मेनिफ़ेस्ट में मौजूद ${name} के किसी भी इंस्टेंस को, इस शब्दकोश में दिए गए नाम से जुड़ी वैल्यू से बदल दिया जाएगा. `applicationId`, `versionCode`, `versionName`, `minSdkVersion`, `targetSdkVersion`, और `maxSdkVersion` भी, मेनिफ़ेस्ट और इस्तेमाल-sdk टैग से जुड़े एट्रिब्यूट को बदल देंगे. `packageName` को अनदेखा कर दिया जाएगा और अगर बताया गया हो, तो इसे `applicationId` से या मेनिफ़ेस्ट में पैकेज के तौर पर सेट कर दिया जाएगा. Manifest_values का इस्तेमाल करने के लिए, नियम में मेनिफ़ेस्ट का होना ज़रूरी नहीं है.
`nocompress_extensions`	`List of strings; optional` संसाधन apk में, कंप्रेस नहीं किए गए फ़ाइल एक्सटेंशन की सूची.
`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 या transaction_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` नियम के `name` से मेल खाने वाली Java क्लास का इस्तेमाल किया जाएगा. टेस्ट क्लास को `org.junit.runner.RunWith` के साथ एनोटेट करना ज़रूरी है.
`use_launcher`	`Boolean; optional; default is True` बाइनरी को कस्टम लॉन्चर का इस्तेमाल करना चाहिए या नहीं. अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो लॉन्चर एट्रिब्यूट और इससे जुड़े `--java_launcher` फ़्लैग को इस टारगेट के लिए अनदेखा किया जाएगा.

android_device

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 Emulator बनाता है जिसे दी गई खास जानकारी के हिसाब से कॉन्फ़िगर किया गया हो. इस एम्युलेटर को bazel रन कमांड के ज़रिए या सीधे जनरेट की गई स्क्रिप्ट को चलाकर शुरू किया जा सकता है. हमारा सुझाव है कि आप अपना तय करने के बजाय, मौजूदा android_device के नियमों पर निर्भर रहें.

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

android_device के लिए KVM इमेज बनाने की सुविधा काम करती है. ऐसा तब होता है, जब system_image की मूल इमेज X86 पर आधारित हो और इसे ज़्यादा से ज़्यादा I686 सीपीयू आर्किटेक्चर के हिसाब से ऑप्टिमाइज़ किया गया हो. केवीएम का इस्तेमाल करने के लिए, 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 play :nexus_s -- --action=start. का इस्तेमाल करें. स्क्रिप्ट ये फ़्लैग दिखाती है:

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

तर्क

एट्रिब्यूट
`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: उपयोगकर्ता के डेटा का शुरुआती हिस्सा source.properties: यह एक प्रॉपर्टी फ़ाइल होती है, जिसमें इमेज के बारे में जानकारी होती है. ये फ़ाइलें, Android SDK टूल का हिस्सा हैं या इन्हें तीसरे पक्ष उपलब्ध कराते हैं. उदाहरण के लिए, Intel, x86 इमेज उपलब्ध कराता है.
`vertical_resolution`	`Integer; required` एम्युलेट करने के लिए पिक्सल में वर्टिकल स्क्रीन रिज़ॉल्यूशन. वैल्यू कम से कम 240 होनी चाहिए.
`vm_heap`	`Integer; required` Android वर्चुअल मशीन हीप के मेगाबाइट में मौजूद साइज़ का इस्तेमाल, हर प्रोसेस के लिए किया जाएगा. वैल्यू कम से कम 16 मेगाबाइट होनी चाहिए.

android_ndk_repository

android_ndk_repository(name, api_level, path, repo_mapping)

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

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

ज़्यादा जानकारी के लिए, Gazel के साथ 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 एनडीके का इस्तेमाल किया जाएगा. यह आपके जेएनआई कोड को कंपाइल करते समय, एपीआई लेवल 24 की लाइब्रेरी का इस्तेमाल करेगा.

सीपीयू

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

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

उदाहरण

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

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 फ़ाइल फ़ोल्डर का हिस्सा हो (उदाहरण के लिए, अगर इसे वर्शन कंट्रोल में चेक किया गया हो).

सपोर्ट लाइब्रेरी

Android SDK Manager में सपोर्ट लाइब्रेरी, "Android सपोर्ट रिपॉज़िटरी" के तौर पर उपलब्ध हैं. यह सामान्य 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 टूल में इंस्टॉल किए गए हर एपीआई लेवल के लिए, `@androidsdk//:sdk-${level}` नाम का एक `android_sdk` टारगेट बनाता है. भले ही, इस एट्रिब्यूट के बारे में बताया गया हो या नहीं. उदाहरण के लिए, नॉन-डिफ़ॉल्ट एपीआई लेवल के हिसाब से कॉन्टेंट बनाने के लिए: `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 बिल्ड टूल का वर्शन. अगर जानकारी नहीं दी जाती है, तो इंस्टॉल किए गए सबसे नए बिल्ड टूल वर्शन का इस्तेमाल किया जाएगा. 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"`) में उस डिपेंडेंसी को ठीक करना चाहिए.