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

Android नियम

नियम

android_binary
aar_Import
android_library
android_console_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 के नियमों के उदाहरण, Bazel का सोर्स ट्री की 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` फ़ाइलों की सूची, डीबग कीऑस्क पर हस्ताक्षर करने के लिए कीस्टोर को डीबग करें. आम तौर पर, आप डिफ़ॉल्ट बटन के अलावा दूसरी कुंजियों का इस्तेमाल नहीं करना चाहते. इसलिए, इस एट्रिब्यूट को हटा दें. चेतावनी: अपनी प्रोडक्शन कुंजियों का इस्तेमाल न करें. उन्हें पूरी तरह से सुरक्षित किया जाना चाहिए और उन्हें आपके सोर्स ट्री में नहीं रखा जाना चाहिए.
`debug_signing_lineage_file`	`Label; optional` डीबग_साइनिंग_की के लिए साइनिंग लाइनेज वाली फ़ाइल. आम तौर पर, आप डिफ़ॉल्ट बटन के अलावा दूसरी कुंजियों का इस्तेमाल नहीं करना चाहते. इसलिए, इस एट्रिब्यूट को हटा दें. चेतावनी: अपनी प्रोडक्शन कुंजियों का इस्तेमाल न करें. उन्हें पूरी तरह से सुरक्षित किया जाना चाहिए और उन्हें आपके सोर्स ट्री में नहीं रखा जाना चाहिए.
`densities`	`List of strings; optional` APK बनाते समय फ़िल्टर करने की डेंसिटी. ऐसा करने पर, रास्टर ड्रॉ करने वाले वे संसाधन हटा दिए जाएंगे जिन्हें किसी डिवाइस पर, लोड किए गए स्क्रीन डेंसिटी के हिसाब से लोड नहीं किया जाएगा. इससे, APK का साइज़ कम हो जाएगा. अगर मेनिफ़ेस्ट में पहले से ही कोई सुपरसेट लिस्टिंग नहीं है, तो उससे जुड़ी एक स्क्रीन के सेक्शन को भी मेनिफ़ेस्ट में जोड़ा जाएगा.
`dex_shards`	`Integer; optional; default is 1` शार्ड को अलग-अलग करने की संख्या कम से कम रखी जानी चाहिए. इससे ऐप्लिकेशन इंस्टॉल करने और शुरू करने में लगने वाले समय की बचत होती है. बाइनरी फ़ाइल का साइज़ बड़ा होने पर, ज़्यादा शार्ड इस्तेमाल किए जाने चाहिए. परफ़ॉर्मेंस की जांच शुरू करने के लिए, 25 का इस्तेमाल करना अच्छा रहता है. ध्यान दें कि फ़ाइनल ऐप्लिकेशन में हर शार्ड का कम से कम एक डेक्स होगा. इस वजह से, इसे बाइनरी से ज़्यादा पर सेट करने का सुझाव नहीं दिया जाता है.
`dexopts`	`List of strings; optional` क्लास.dex जनरेट करते समय, dx टूल के लिए अन्य कमांड लाइन फ़्लैग. "Make वैरिएबल" की जगह लागू होना और बॉर्न शेल टोकन का इस्तेमाल करना.
`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` इस टारगेट के लिए अतिरिक्त कंपाइलर विकल्प. "Make वैरिएबल" की जगह लागू होना और बॉर्न शेल टोकन का इस्तेमाल करना. ग्लोबल कंपाइलर विकल्पों के बाद, इन कंपाइलर विकल्पों को javac को पास किया जाता है.
`key_rotation_min_sdk`	`String; optional` कम से कम Android प्लैटफ़ॉर्म वर्शन (एपीआई लेवल) सेट करता है, जिसके लिए APK और #39;s हस्ताक्षर बनाने के लिए रोटेट की गई साइनिंग कुंजी का इस्तेमाल किया जाना चाहिए. APK के लिए साइन करने वाली मूल कुंजी का इस्तेमाल प्लैटफ़ॉर्म के सभी पुराने वर्शन के लिए किया जाएगा.
`main_dex_list`	`Label; optional` टेक्स्ट फ़ाइल में, क्लास फ़ाइल के नामों की सूची होती है. उन क्लास फ़ाइलों से तय होने वाली क्लास को primaryclass.dex में डाला जाता है, जैसे: 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` Prox की खास जानकारी के तौर पर इस्तेमाल की जाने वाली फ़ाइलें, ताकि यह पता लगाया जा सके कि मुख्य डेक में कौनसी क्लास होनी चाहिए. सिर्फ़ तब अनुमति दी जाती है, जब `multidex` एट्रिब्यूट `legacy` पर सेट होता है.
`manifest`	`Label; required` Android मेनिफ़ेस्ट फ़ाइल का नाम, आम तौर पर `AndroidManifest.xml`. अगर रिसॉर्स_फ़ाइल या एसेट तय किए जाते हैं, तो इसकी जानकारी देना ज़रूरी है.
`manifest_values`	`Dictionary: String -> String; optional` मेनिफ़ेस्ट में ओवरराइड की जाने वाली वैल्यू का शब्दकोश. मेनिफ़ेस्ट में ${name} के किसी भी इंस्टेंस को, इस शब्दकोश में मौजूद नाम से जुड़ी वैल्यू से बदल दिया जाएगा. ऐप्लिकेशन आईडी, versionCode, versionName, minSdkVersion, targetSdkVersion, और maxSdkVersion भी मेनिफ़ेस्ट के संबंधित एट्रिब्यूट को बदल देंगे और SDK टूल के इस्तेमाल के बारे में बात करेंगे. packageName को अनदेखा किया जाएगा और अगर बताया गया हो या मेनिफ़ेस्ट में पैकेज, दोनों में से किसी भी ApplicationId से सेट किया जाएगा. जब मेनिफ़ेस्ट_मर्ज, लेगसी पर सेट होता है, तो सिर्फ़ 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's के `--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_resources_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_लाइब्रेरी

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: संग्रह वाला स्रोत ("source Jar").
name.aar: एक Android और #39;aar' बंडल, जिसमें java संग्रह और इस टारगेट के संसाधन शामिल हैं. इसमें ट्रांज़िटिव बंद होने की जानकारी शामिल नहीं है.

उदाहरण

Android के नियमों के उदाहरण, Bazel का सोर्स ट्री की examples/android डायरेक्ट्री में मौजूद हैं.

इस उदाहरण में, 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` टारगेट किया जाता है. साथ ही, Android टारगेट प्लैटफ़ॉर्म के लिए `.so` नेटिव लाइब्रेरी बनाई जाती हैं.
`srcs`	`List of labels; optional` `.java` या `.srcjar` फ़ाइलों की सूची जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. `.java` प्रकार की `srcs` फ़ाइलें कंपाइल की गई हैं. पढ़ने और समझने में आसान के लिए, जनरेट की गई `.java` सोर्स फ़ाइल का नाम `srcs` में डालना ठीक नहीं है. इसके बजाय, `srcs` में निर्भर नियम का नाम डालें, जैसा कि नीचे बताया गया है. `.srcjar` प्रकार की `srcs` फ़ाइलें अनपैक की गई हैं और उन्हें कंपाइल किया गया है. (अगर आपको genrule या बिल्ड एक्सटेंशन के साथ .java फ़ाइलों का सेट जनरेट करना है, तो यह तरीका कारगर होगा.) अगर `srcs` को खाली छोड़ा जाता है, तो `deps` में बताई गई कोई भी डिपेंडेंसी इस नियम से एक्सपोर्ट की जाती है. डिपेंडेंसी के बारे में ज़्यादा जानकारी के लिए, java_library'sexport देखें. हालांकि, इस व्यवहार को जल्द ही रोक दिया जाएगा. इस पर भरोसा न करने की कोशिश करें.
`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` जावा पैकेज ट्री के रूट के साथ पैकेज-रिलेटिव पाथ, जिसमें इस लाइब्रेरी में शामिल आइडल सोर्स शामिल हैं. इस पाथ का इस्तेमाल इंपोर्ट किए जाने वाले रूट के तौर पर किया जाएगा. ऐसा तब किया जाएगा, जब इस लाइब्रेरी पर निर्भर आईडी सोर्स को प्रोसेस किया जा रहा हो. जब `idl_import_root` दिया गया हो, तो `idl_parcelables` और `idl_srcs`, दोनों को उस ऑब्जेक्ट के Java पैकेज के बताए गए पाथ पर होना चाहिए जिसके बारे में `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 की उन परिभाषाओं के लिए `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` इस टारगेट के लिए अतिरिक्त कंपाइलर विकल्प. "Make वैरिएबल" की जगह लागू होना और बॉर्न शेल टोकन का इस्तेमाल करना. ग्लोबल कंपाइलर विकल्पों के बाद, इन कंपाइलर विकल्पों को 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, -dontvarn, benonosides, और -keep से शुरू होने वाले नियम होने चाहिए. दूसरे विकल्प, सिर्फ़ `android_binary`'sGuard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि वे गैर-ऑटोलॉजिकल मर्ज में शामिल न हों.
`resource_files`	`List of labels; optional` पैकेज किए जाने वाले संसाधनों की सूची. आम तौर पर, यह `res` डायरेक्ट्री में मौजूद सभी फ़ाइलों का `glob` होता है. जनरेट की गई फ़ाइलों (जेनरल से) का रेफ़रंस यहां लेबल से भी लिया जा सकता है. एकमात्र पाबंदी यह है कि जनरेट किए गए आउटपुट उसी कोट &`res`;कोटेशन के तहत होने चाहिए जो अन्य रिसॉर्स फ़ाइलों में शामिल हैं.

Android_testation_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 Robolectic टेस्टिंग फ़्रेमवर्क के साथ काम करता है. रोबोलेट्रिक टेस्ट लिखने के बारे में ज़्यादा जानने के लिए, Android Robolectic साइट देखें.

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

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

उदाहरण

android_local_test के लिए Robolectract का इस्तेमाल करने के लिए, अपनी WORKSPACE फ़ाइल में Robolecric's.repository जोड़ें:

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()

इससे, Robolectic के लिए ज़रूरी 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` फ़ाइलें अनपैक की गई हैं और उन्हें कंपाइल किया गया है. (अगर आपको genrule या बिल्ड एक्सटेंशन के साथ .java फ़ाइलों का सेट जनरेट करना है, तो यह तरीका कारगर होगा.) बाकी सभी फ़ाइलों को अनदेखा किया जाता है. हालांकि, ऊपर बताई गई फ़ाइल टाइप में से कम से कम एक फ़ाइल का होना ज़रूरी है. ऐसा न करने पर, गड़बड़ी की सूचना मिलती है. अगर `runtime_deps` से जुड़ी जानकारी नहीं दी जाती है, तो `srcs` एट्रिब्यूट ज़रूरी है और इसे खाली नहीं छोड़ा जा सकता.
`custom_package`	`String; optional` Java पैकेज, जिसमें R क्लास जनरेट की जाएगी. डिफ़ॉल्ट रूप से, पैकेज की जानकारी उस डायरेक्ट्री से मिलती है जहां नियम वाली BUILD फ़ाइल होती है. अगर आप इस एट्रिब्यूट का इस्तेमाल करते हैं, तो आपको `test_class` का भी इस्तेमाल करना पड़ सकता है.
`densities`	`List of strings; optional` APK बनाते समय फ़िल्टर करने की डेंसिटी. अगर मेनिफ़ेस्ट में पहले से ही कोई Superset StarlarkListing नहीं है, तो उससे जुड़ी स्क्रीन के साथ काम करने वाला स्क्रीन सेक्शन भी जोड़ा जाएगा.
`enable_data_binding`	`Boolean; optional; default is False` अगर यह सही है, तो यह नियम इस टेस्ट में इस्तेमाल की गई डिपेंडेंसी का इस्तेमाल करने वाले डेटा बाइंडिंग रेफ़रंस को प्रोसेस करता है. इस सेटिंग के बिना, डेटा-बाइंडिंग डिपेंडेंसी में बाइनरी लेवल का कोड जनरेट करने की ज़रूरत नहीं होती. साथ ही, इससे बिल्ड फ़ेल हो सकता है.
`javacopts`	`List of strings; optional` इस लाइब्रेरी के लिए अतिरिक्त कंपाइलर विकल्प. "Make वैरिएबल" की जगह लागू होना और बॉर्न शेल टोकन का इस्तेमाल करना. ग्लोबल कंपाइलर विकल्पों के बाद, इन कंपाइलर विकल्पों को javac को पास किया जाता है.
`jvm_flags`	`List of strings; optional` इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में एम्बेड किए गए फ़्लैग की सूची. $(location) और "Make वैरिएबल" की जगह बदलाव करें और बॉर्न शेल टोकन का इस्तेमाल करें. Java बाइनरी की रैपर स्क्रिप्ट में क्लासपाथ की परिभाषा (सभी निर्भर जार ढूंढने के लिए) शामिल होती है और सही Java इंटरप्रेटर को शुरू किया जाता है. रैपर स्क्रिप्ट से जनरेट की जाने वाली कमांड लाइन में मुख्य क्लास का नाम और फिर `"$@"` होता है, ताकि आप क्लासनेम के बाद दूसरे आर्ग्युमेंट को पास कर सकें. हालांकि, JVM से पार्स करने के लिए किए जाने वाले आर्ग्युमेंट को कमांड लाइन पर क्लासनाम से पहले बताया जाना चाहिए. क्लास का नाम सूची में शामिल करने से पहले, `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` रिसॉर्स 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 या रनटाइम_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 क्लास का नाम बताता है. इसे सेट करना कम ही होता है. अगर यह आर्ग्युमेंट हटाया जाता है, तो उस Java क्लास का इस्तेमाल किया जाएगा जिसका नाम इस `android_local_test` नियम के `name` से मेल खाता है. टेस्ट क्लास के साथ `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 डिवाइस तय करने के बजाय, मौजूदा 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

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

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

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए कोई खास नाम.
`cache`	`Integer; required` एम्युलेटर की कैश मेमोरी के मेगाबाइट में साइज़. इसका कम से कम मान 16 मेगाबाइट है.
`default_properties`	`Label; optional` एम्युलेटर पर /default.prop में रखने के लिए एक प्रॉपर्टी फ़ाइल. इसकी मदद से नियम बनाने वाला, एम्युलेटर को और भी असली डिवाइस की तरह दिखा सकता है. खास तौर पर, उपयोगकर्ता एजेंट स्ट्रिंग और अन्य व्यवहार को कंट्रोल करने से, ऐप्लिकेशन या सर्वर किसी खास डिवाइस पर अलग तरह से काम कर सकते हैं. इस फ़ाइल की प्रॉपर्टी, ro.product.model जैसे एम्युलेटर की सेट की गई रीड ओनली प्रॉपर्टी को बदल देंगी.
`horizontal_resolution`	`Integer; required` एम्युलेट करने के लिए पिक्सल में हॉरिज़ॉन्टल स्क्रीन रिज़ॉल्यूशन. कम से कम वैल्यू 240 है.
`platform_apks`	`List of labels; optional` बूट के समय डिवाइस पर इंस्टॉल किए जाने वाले apks की सूची.
`ram`	`Integer; required` डिवाइस में एम्युलेट करने के लिए मेगाबाइट में रैम की मात्रा. यह पूरे डिवाइस के लिए है, न कि सिर्फ़ डिवाइस पर इंस्टॉल किए गए किसी खास ऐप्लिकेशन के लिए. कम से कम वैल्यू 64 मेगाबाइट है.
`screen_density`	`Integer; required` एम्युलेट की गई स्क्रीन की सघनता पिक्सल में प्रति इंच है. इसका कम से कम मान 30 ppi है.
`system_image`	`Label; required` ऐसा फ़ाइल ग्रुप जिसमें ये फ़ाइलें शामिल हैं: System.img: सिस्टम पार्टीशन kernel-qemu: Linux कर्नेल एम्युलेटर लोड होगा ramdisk.img: बूट समय पर इस्तेमाल करने के लिए अंदर की इमेज userdata.img: उपयोगकर्ता के डेटा का शुरुआती हिस्सा source.property: ऐसी प्रॉपर्टी फ़ाइल जिसमें इमेज की जानकारी होती है ये फ़ाइलें 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)

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

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

cpufeatures

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 एपीआई लेवल बनाना. अगर जानकारी न दी गई हो, तो सबसे ज़्यादा एपीआई लेवल इंस्टॉल किया जाएगा.
`path`	`String; optional; nonconfigurable` Android NDK का एक ऐब्सलूट या रिलेटिव पाथ. यह एट्रिब्यूट या `$ANDROID_NDK_HOME` एनवायरमेंट वैरिएबल सेट करना ज़रूरी है. Android NDK, 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 टूल का इस्तेमाल करने के लिए कॉन्फ़िगर करता है.

उदाहरण

बेज़ेल के लिए Android का SDK टूल सेट अप करने का सबसे कम तरीका है कि अपनी WORKSPACE फ़ाइल में android_sdk_repository नियम का नाम रखें "androidsdk" और $ANDROID_HOMEAndroid एनवायरमेंट पाथ की वैल्यू को अपने Android SDK टूल के पाथ पर सेट करें. Bazel, Android के सबसे अच्छे एपीआई लेवल का इस्तेमाल करेगा और डिफ़ॉल्ट रूप से, 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 फ़ाइल फ़ोल्डर का हिस्सा है, तो इसका इस्तेमाल किया जा सकता है. उदाहरण के लिए, अगर SDK टूल के वर्शन कंट्रोल में इसका इस्तेमाल किया जाता है.

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

सहायता लाइब्रेरी, Android SDK Manager में "Android सहायता डेटा स्टोर करने की जगह" के तौर पर उपलब्ध हैं. यह सामान्य Android लाइब्रेरी का वर्शन वाला सेट है, जैसे कि Support और AppCompat लाइब्रेरी. इसे लोकल मेवन रिपॉज़िटरी के तौर पर पैकेज किया जाता है. android_sdk_repository इन सभी लाइब्रेरी के लिए बेज़ल टारगेट जनरेट करता है. इनका इस्तेमाल 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"`) के अंदर ही उस डिपेंडेंसी को ठीक करना चाहिए.