Android के नियम

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

नियम

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 संग्रह, जिसमें इस टारगेट का ट्रांज़िटिव क्लोज़र शामिल है.

    डिप्लॉय किए गए jar में वे सभी क्लास होती हैं जो किसी क्लासलोडर को मिलती हैं. यह क्लासलोडर, इस टारगेट के रनटाइम क्लासपाथ को शुरू से लेकर आखिर तक खोजता है.

  • 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

नाम; यह ज़रूरी है

इस टारगेट के लिए यूनीक नाम.
deps

लेबल की सूची; डिफ़ॉल्ट [] है

बाइनरी टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. लाइब्रेरी के इन टाइप को अनुमति दी जाती है: android_library, java_library, जिसमें android शर्त हो और cc_library, Android टारगेट प्लैटफ़ॉर्म के लिए .so नेटिव लाइब्रेरी को रैप करने या जनरेट करने वाली लाइब्रेरी.
srcs

लेबल की सूची; डिफ़ॉल्ट [] है

टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची.

.java टाइप की srcs फ़ाइलें कंपाइल की जाती हैं. कॉन्टेंट को आसानी से पढ़ने के लिए, जनरेट की गई .java सोर्स फ़ाइल का नाम srcs में डालना अच्छा नहीं है. इसके बजाय, srcs में उस नियम का नाम डालें जिस पर यह नियम निर्भर करता है, जैसा कि यहां बताया गया है.

.srcjar टाइप की srcs फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule या बिल्ड एक्सटेंशन की मदद से .java फ़ाइलों का सेट जनरेट करना हो.)

assets

लेबल की सूची; डिफ़ॉल्ट [] है

पैकेज की जाने वाली ऐसेट की सूची. आम तौर पर, यह assets डायरेक्ट्री में मौजूद सभी फ़ाइलों का glob होता है. दूसरे पैकेज में मौजूद अन्य नियमों (ऐसा कोई भी नियम जो फ़ाइलें बनाता है) या एक्सपोर्ट की गई फ़ाइलों का भी रेफ़रंस दिया जा सकता है. हालांकि, ऐसा तब ही किया जा सकता है, जब वे सभी फ़ाइलें उस पैकेज में मौजूद assets_dir डायरेक्ट्री में हों.
assets_dir

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

assets में मौजूद फ़ाइलों का पाथ बताने वाली स्ट्रिंग. assets और assets_dir, पैकेज की गई एसेट के बारे में बताते हैं. साथ ही, दोनों एट्रिब्यूट की वैल्यू दी जानी चाहिए या इनमें से कोई भी एट्रिब्यूट नहीं दिया जाना चाहिए.
crunch_png

बूलियन; डिफ़ॉल्ट तौर पर True

PNG क्रंचिंग करें या नहीं. यह नाइन-पैच प्रोसेसिंग से अलग है, जो हमेशा की जाती है. यह aapt बग से जुड़ी समस्या को हल करने का एक तरीका है. इसे अब इस्तेमाल नहीं किया जा सकता. इस समस्या को aapt2 में ठीक कर दिया गया है.
custom_package

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

वह Java पैकेज जिसके लिए Java सोर्स जनरेट किए जाएंगे. डिफ़ॉल्ट रूप से, पैकेज उस डायरेक्ट्री से अनुमानित होता है जहां नियम वाली BUILD फ़ाइल मौजूद होती है. आपके पास कोई दूसरा पैकेज तय करने का विकल्प होता है, लेकिन ऐसा करने का सुझाव नहीं दिया जाता. ऐसा इसलिए, क्योंकि इससे अन्य लाइब्रेरी के साथ क्लासपथ में समस्याएं आ सकती हैं. इन समस्याओं का पता सिर्फ़ रनटाइम के दौरान चलेगा.
debug_key

लेबल; डिफ़ॉल्ट "@bazel_tools//tools/android:debug_keystore" है

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

चेतावनी: प्रोडक्शन पासकोड का इस्तेमाल न करें. इन्हें पूरी तरह से सुरक्षित रखें और अपने सोर्स ट्री में न रखें.
debug_signing_keys

लेबल की सूची; डिफ़ॉल्ट [] है

डीबग APK पर हस्ताक्षर करने के लिए इस्तेमाल की जाने वाली फ़ाइलों और डीबग कीस्टोर की सूची. आम तौर पर, डिफ़ॉल्ट बटन के अलावा किसी दूसरे बटन का इस्तेमाल नहीं किया जाता. इसलिए, इस एट्रिब्यूट को शामिल नहीं किया जाना चाहिए.

चेतावनी: प्रोडक्शन पासकोड का इस्तेमाल न करें. इन्हें पूरी तरह से सुरक्षित रखें और अपने सोर्स ट्री में न रखें.
debug_signing_lineage_file

लेबल; डिफ़ॉल्ट None है

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

चेतावनी: प्रोडक्शन पासकोड का इस्तेमाल न करें. इन्हें पूरी तरह से सुरक्षित रखें और अपने सोर्स ट्री में न रखें.
densities

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

पूर्णांक; डिफ़ॉल्ट वैल्यू 1 है

डेटा को कितने हिस्सों में बांटकर इंडेक्स किया जाना चाहिए. इससे, ऐप्लिकेशन इंस्टॉल होने और शुरू होने में लगने वाले समय की कीमत पर, डेक्सिंग की प्रोसेस ज़्यादा तेज़ हो जाती है. बाइनरी का साइज़ जितना बड़ा होगा, उतने ही ज़्यादा शार्ड इस्तेमाल किए जाने चाहिए. प्रयोग शुरू करने के लिए 25 एक अच्छी वैल्यू है.

ध्यान दें कि हर शर्ड की वजह से, फ़ाइनल ऐप्लिकेशन में कम से कम एक dex बनेगा. इस वजह से, रिलीज़ बाइनरी के लिए इसे एक से ज़्यादा पर सेट करने का सुझाव नहीं दिया जाता.

dexopts

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

classes.dex जनरेट करते समय, dx टूल के लिए अतिरिक्त कमांड-लाइन फ़्लैग. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.
enable_data_binding

बूलियन; डिफ़ॉल्ट तौर पर False

अगर यह सही है, तो यह नियम resource_files एट्रिब्यूट के ज़रिए शामिल किए गए लेआउट संसाधनों में, डेटा बाइंडिंग एक्सप्रेशन को प्रोसेस करता है. इस सेटिंग के बिना, डेटा बाइंडिंग एक्सप्रेशन के बने बंडल काम नहीं करते.

डेटा बाइंडिंग की सुविधा के साथ Android ऐप्लिकेशन बनाने के लिए, आपको ये काम भी करने होंगे:

  1. इस एट्रिब्यूट को उन सभी Android नियमों के लिए सेट करें जो इस नियम पर निर्भर करते हैं. इसकी वजह यह है कि डिपेंडर, संसाधन को मर्ज करने की प्रोसेस के ज़रिए नियम के डेटा बाइंडिंग एक्सप्रेशन को इनहेरिट करते हैं. इसलिए, उन एक्सप्रेशन को पार्स करने के लिए, उन्हें डेटा बाइंडिंग के साथ भी बनाना होगा.
  2. इस एट्रिब्यूट को सेट करने वाले सभी टारगेट में, डेटा बाइंडिंग रनटाइम लाइब्रेरी के लिए deps = एंट्री जोड़ें. इस लाइब्रेरी की जगह, आपके डिपो सेटअप पर निर्भर करती है.
incremental_dexing

पूर्णांक; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट -1 है

टारगेट को इंक्रीमेंटल डेक्सिंग के साथ या उसके बिना बनाने के लिए, डिफ़ॉल्ट वैल्यू और --incremental_dexing फ़्लैग को बदलें.
instruments

लेबल; डिफ़ॉल्ट None है

android_binary टारगेट को इंस्ट्रूमेंट में बदलना.

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

javacopts

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

इस टारगेट के लिए, कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.

कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac को पास किए जाते हैं.
key_rotation_min_sdk

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

Android प्लैटफ़ॉर्म के उस कम से कम वर्शन (एपीआई लेवल) को सेट करता है जिसके लिए, APK के हस्ताक्षर बनाने के लिए, रोटेट की गई साइनिंग कुंजी का इस्तेमाल किया जाना चाहिए. APK के लिए बनी मूल साइनिंग पासकोड का इस्तेमाल, प्लैटफ़ॉर्म के सभी पुराने वर्शन के लिए किया जाएगा.
main_dex_list

लेबल; डिफ़ॉल्ट None है

टेक्स्ट फ़ाइल में क्लास फ़ाइल के नामों की सूची होती है. उन क्लास फ़ाइलों से तय की गई क्लास, मुख्य classes.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

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

मुख्य डेक्स सूची बिल्डर को पास करने के लिए, कमांड-लाइन विकल्प. मुख्य डेक्स सूची में शामिल क्लास पर असर डालने के लिए, इस विकल्प का इस्तेमाल करें.
main_dex_proguard_specs

लेबल की सूची; डिफ़ॉल्ट [] है

Proguard की खास बातों के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इनसे यह तय किया जाता है कि किन क्लास को मुख्य dex में रखना है. सिर्फ़ तब इस्तेमाल किया जा सकता है, जब multidex एट्रिब्यूट को legacy पर सेट किया गया हो.
manifest

लेबल; ज़रूरी है

Android मेनिफ़ेस्ट फ़ाइल का नाम, आम तौर पर AndroidManifest.xml. अगर resource_files या ऐसेट की जानकारी दी गई है, तो इसकी जानकारी देना ज़रूरी है.
manifest_values

डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; डिफ़ॉल्ट तौर पर {}

मेनिफ़ेस्ट में बदली जाने वाली वैल्यू की डिक्शनरी.

मेनिफ़ेस्ट में ${name} का कोई भी इंस्टेंस, इस डिक्शनरी में नाम से जुड़ी वैल्यू से बदल दिया जाएगा.

applicationId, versionCode, versionName, minSdkVersion, targetSdkVersion, और maxSdkVersion, मेनिफ़ेस्ट और uses-sdk टैग में मौजूद मिलते-जुलते एट्रिब्यूट को भी बदल देंगे.

packageName को अनदेखा कर दिया जाएगा. अगर applicationId दिया गया है, तो इसे applicationId से सेट किया जाएगा. अगर applicationId नहीं दिया गया है, तो इसे मेनिफ़ेस्ट में मौजूद पैकेज से सेट किया जाएगा.

जब manifest_merger को legacy पर सेट किया जाता है, तो सिर्फ़ applicationId, versionCode, और versionName का असर होगा.

multidex

स्ट्रिंग; डिफ़ॉल्ट रूप से "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

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

APK में बिना कंप्रेस किए छोड़ी जाने वाली फ़ाइल एक्सटेंशन की सूची.
package_id

पूर्णांक; डिफ़ॉल्ट वैल्यू 0 है

इस बाइनरी में संसाधनों को असाइन किया जाने वाला पैकेज आईडी.

ज़्यादा जानकारी के लिए, AAPT2 का --package-id आर्ग्युमेंट देखें. आम तौर पर, इसे सेट नहीं किया जा सकता (और ऐसा नहीं करना चाहिए). ऐसा करने पर, डिफ़ॉल्ट वैल्यू 127 (0x7F) हो जाएगी.

plugins

लेबल की सूची; डिफ़ॉल्ट [] है

कंपाइल के समय चलने वाले Java कंपाइलर प्लग इन. प्लग इन एट्रिब्यूट में बताए गए हर java_plugin को, इस टारगेट के बनने पर चलाया जाएगा. प्लग इन से जनरेट किए गए संसाधन, टारगेट के नतीजे के jar में शामिल किए जाएंगे.
proguard_apply_dictionary

लेबल; डिफ़ॉल्ट None है

ProGuard के लिए मैपिंग के तौर पर इस्तेमाल की जाने वाली फ़ाइल. "शब्दों" की लाइन से अलग की गई फ़ाइल, जिससे गुप्त करने के दौरान क्लास और सदस्यों के नाम बदलने के लिए, नाम लिया जा सकता है.
proguard_apply_mapping

लेबल; डिफ़ॉल्ट None है

ProGuard के लिए मैपिंग के तौर पर इस्तेमाल की जाने वाली फ़ाइल. proguard_generate_mapping से जनरेट की गई मैपिंग फ़ाइल, जिसका इस्तेमाल किसी नए बिल्ड पर उसी मैपिंग को लागू करने के लिए फिर से किया जा सकता है.
proguard_generate_mapping

बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट False है

ProGuard की मैपिंग फ़ाइल जनरेट करनी है या नहीं. मैपिंग फ़ाइल सिर्फ़ तब जनरेट होगी, जब proguard_specs की वैल्यू दी गई हो. इस फ़ाइल में, ओरिजनल और सांकेतिक नाम वाली क्लास, तरीके, और फ़ील्ड के नाम के बीच की मैपिंग की सूची होगी.

चेतावनी: अगर इस एट्रिब्यूट का इस्तेमाल किया जाता है, तो Proguard के लिए बनी खास जानकारी में -dontobfuscate और -printmapping, दोनों में से किसी एक का इस्तेमाल करना चाहिए.
proguard_specs

लेबल की सूची; डिफ़ॉल्ट [] है

Proguard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इस फ़ाइल में, Proguard के इस्तेमाल के लिए स्पेसिफ़िकेशन के सेट के बारे में बताया जाएगा.
resource_configuration_filters

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

रिसॉर्स कॉन्फ़िगरेशन फ़िल्टर की सूची, जैसे कि 'en'. इससे APK में मौजूद रिसॉर्स, सिर्फ़ 'en' कॉन्फ़िगरेशन में मौजूद रिसॉर्स तक सीमित हो जाएंगे. सूडोलोकलाइज़ेशन की सुविधा चालू करने के लिए, en_XA और/या ar_XB सूडो-लोकल शामिल करें.
resource_files

लेबल की सूची; डिफ़ॉल्ट [] है

पैकेज किए जाने वाले संसाधनों की सूची. आम तौर पर, यह res डायरेक्ट्री में मौजूद सभी फ़ाइलों का glob होता है.
जनरेट की गई फ़ाइलों (genrules से) का रेफ़रंस, यहां भी लेबल से लिया जा सकता है. हालांकि, इस पर एक पाबंदी है. जनरेट किए गए आउटपुट, शामिल की गई किसी भी अन्य संसाधन फ़ाइल की तरह ही "res" डायरेक्ट्री में होने चाहिए.
shrink_resources

पूर्णांक; डिफ़ॉल्ट वैल्यू -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

नाम; यह ज़रूरी है

इस टारगेट के लिए यूनीक नाम.
aar

लेबल; ज़रूरी है

इस टारगेट पर निर्भर Android टारगेट को देने के लिए .aar फ़ाइल.
exports

लेबल की सूची; डिफ़ॉल्ट [] है

इस नियम पर निर्भर नियमों में एक्सपोर्ट करने के लिए टारगेट. java_library.exports देखें.
srcjar

लेबल; डिफ़ॉल्ट None है

एक 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: एक संग्रह जिसमें सोर्स ("सोर्स jar") शामिल होते हैं.
  • name.aar: Android '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

नाम; यह ज़रूरी है

इस टारगेट के लिए यूनीक नाम.
deps

लेबल की सूची; डिफ़ॉल्ट [] है

लिंक करने के लिए अन्य लाइब्रेरी की सूची. लाइब्रेरी के इन टाइप को अनुमति दी जाती है: android_library, java_library, जिसमें android शर्त हो और cc_library Android टारगेट प्लैटफ़ॉर्म के लिए, .so नेटिव लाइब्रेरी को रैप किया गया हो या बनाई गई हो.
srcs

लेबल की सूची; डिफ़ॉल्ट [] है

टारगेट बनाने के लिए प्रोसेस की गई .java या .srcjar फ़ाइलों की सूची.

.java टाइप की srcs फ़ाइलें कंपाइल की जाती हैं. कॉन्टेंट को आसानी से पढ़ने के लिए, जनरेट की गई .java सोर्स फ़ाइल का नाम srcs में डालना अच्छा नहीं है. इसके बजाय, srcs में उस नियम का नाम डालें जिस पर यह नियम निर्भर करता है, जैसा कि यहां बताया गया है.

.srcjar टाइप की srcs फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule या बिल्ड एक्सटेंशन की मदद से .java फ़ाइलों का सेट जनरेट करना हो.)

अगर srcs को छोड़ दिया जाता है, तो deps में बताई गई किसी भी डिपेंडेंसी को इस नियम से एक्सपोर्ट किया जाता है. डिपेंडेंसी एक्सपोर्ट करने के बारे में ज़्यादा जानकारी के लिए, java_library के एक्सपोर्ट देखें. हालांकि, यह सुविधा जल्द ही बंद कर दी जाएगी. इसलिए, इस पर भरोसा न करें.

assets

लेबल की सूची; डिफ़ॉल्ट [] है

पैकेज की जाने वाली ऐसेट की सूची. आम तौर पर, यह assets डायरेक्ट्री में मौजूद सभी फ़ाइलों का glob होता है. दूसरे पैकेज में मौजूद अन्य नियमों (ऐसा कोई भी नियम जो फ़ाइलें बनाता है) या एक्सपोर्ट की गई फ़ाइलों का भी रेफ़रंस दिया जा सकता है. हालांकि, ऐसा तब ही किया जा सकता है, जब वे सभी फ़ाइलें उस पैकेज में मौजूद assets_dir डायरेक्ट्री में हों.
assets_dir

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

assets में मौजूद फ़ाइलों का पाथ बताने वाली स्ट्रिंग. assets और assets_dir, पैकेज की गई एसेट के बारे में बताते हैं. साथ ही, दोनों एट्रिब्यूट की वैल्यू दी जानी चाहिए या इनमें से कोई भी एट्रिब्यूट नहीं दिया जाना चाहिए.
custom_package

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

वह Java पैकेज जिसके लिए Java सोर्स जनरेट किए जाएंगे. डिफ़ॉल्ट रूप से, पैकेज उस डायरेक्ट्री से अनुमानित होता है जहां नियम वाली BUILD फ़ाइल मौजूद होती है. आपके पास कोई दूसरा पैकेज तय करने का विकल्प होता है, लेकिन ऐसा करने का सुझाव नहीं दिया जाता. ऐसा इसलिए, क्योंकि इससे अन्य लाइब्रेरी के साथ क्लासपथ में समस्याएं आ सकती हैं. इन समस्याओं का पता सिर्फ़ रनटाइम के दौरान चलेगा.
enable_data_binding

बूलियन; डिफ़ॉल्ट तौर पर False

अगर यह सही है, तो यह नियम resource_files एट्रिब्यूट के ज़रिए शामिल किए गए लेआउट संसाधनों में, डेटा बाइंडिंग एक्सप्रेशन को प्रोसेस करता है. इस सेटिंग के बिना, डेटा बाइंडिंग एक्सप्रेशन के बने बंडल काम नहीं करते.

डेटा बाइंडिंग की सुविधा के साथ Android ऐप्लिकेशन बनाने के लिए, आपको ये काम भी करने होंगे:

  1. इस एट्रिब्यूट को उन सभी Android नियमों के लिए सेट करें जो इस नियम पर निर्भर करते हैं. इसकी वजह यह है कि डिपेंडर, संसाधन को मर्ज करने की प्रोसेस के ज़रिए नियम के डेटा बाइंडिंग एक्सप्रेशन को इनहेरिट करते हैं. इसलिए, उन एक्सप्रेशन को पार्स करने के लिए, उन्हें डेटा बाइंडिंग के साथ भी बनाना होगा.
  2. इस एट्रिब्यूट को सेट करने वाले सभी टारगेट में, डेटा बाइंडिंग रनटाइम लाइब्रेरी के लिए deps = एंट्री जोड़ें. इस लाइब्रेरी की जगह, आपके डिपो सेटअप पर निर्भर करती है.
exported_plugins

लेबल की सूची; डिफ़ॉल्ट [] है

उन लाइब्रेरी में एक्सपोर्ट करने के लिए java_plugins (जैसे, एनोटेशन प्रोसेसर) की सूची जो सीधे तौर पर इस लाइब्रेरी पर निर्भर करती हैं.

java_plugin की बताई गई सूची, उन सभी लाइब्रेरी पर लागू की जाएगी जो सीधे तौर पर इस लाइब्रेरी पर निर्भर करती हैं. ऐसा ठीक वैसे ही होगा जैसे उस लाइब्रेरी ने plugins में इन लेबल का साफ़ तौर पर एलान किया हो.

exports

लेबल की सूची; डिफ़ॉल्ट [] है

exports एट्रिब्यूट के ज़रिए मिले सभी नियमों के बंद होने को, ऐसे किसी भी नियम की डायरेक्ट डिपेंडेंसी माना जाता है जो सीधे तौर पर exports वाले टारगेट पर निर्भर करता है.

exports, उस नियम के सीधे डिपेंडेंसी नहीं हैं जिससे वे जुड़े हैं.
exports_manifest

पूर्णांक; डिफ़ॉल्ट वैल्यू 1 है

इस टारगेट पर निर्भर android_binary टारगेट में, मेनिफ़ेस्ट एंट्री को एक्सपोर्ट करना है या नहीं. uses-permissions एट्रिब्यूट कभी एक्सपोर्ट नहीं किए जाते.
idl_import_root

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

इस लाइब्रेरी में शामिल आईडीएल के सोर्स वाले java पैकेज ट्री के रूट का पैकेज-रिलेटिव पाथ.

इस लाइब्रेरी पर निर्भर idl सोर्स को प्रोसेस करते समय, इस पाथ का इस्तेमाल इंपोर्ट रूट के तौर पर किया जाएगा.

idl_import_root की वैल्यू देने पर, idl_parcelables और idl_srcs, दोनों को उस पाथ पर होना चाहिए जिसे idl_import_root में दिखाए गए ऑब्जेक्ट के java पैकेज ने तय किया है. जब idl_import_root की जानकारी नहीं दी जाती है, तो idl_parcelables और idl_srcs, दोनों को Java रूट में अपने पैकेज के बताए गए पाथ पर होना चाहिए.

उदाहरण देखें.
idl_parcelables

लेबल की सूची; डिफ़ॉल्ट [] है

इंपोर्ट के तौर पर देने के लिए, Android IDL की परिभाषाओं की सूची. इन फ़ाइलों को, सीधे तौर पर या ट्रांज़िटिव क्लोज़र के ज़रिए, इस लाइब्रेरी पर निर्भर किसी भी android_library टारगेट के लिए इंपोर्ट के तौर पर उपलब्ध कराया जाएगा. हालांकि, इन्हें Java में अनुवाद नहीं किया जाएगा या कंपाइल नहीं किया जाएगा.

इस लाइब्रेरी में, सिर्फ़ ऐसी .aidl फ़ाइलें शामिल की जानी चाहिए जो सीधे तौर पर .java सोर्स से जुड़ी हों.उदाहरण के लिए, Parcelable के कस्टम लागू होने. ऐसा न करने पर, idl_srcs का इस्तेमाल किया जाना चाहिए.

aidl कंपाइलर को ये फ़ाइलें ढूंढने के लिए, उन्हें सही जगह पर रखना ज़रूरी है. इसका क्या मतलब है, इस बारे में जानने के लिए idl_import_root के बारे में जानकारी देखें.
idl_preprocessed

लेबल की सूची; डिफ़ॉल्ट [] है

पहले से प्रोसेस किए गए Android IDL की परिभाषाओं की सूची, ताकि उन्हें इंपोर्ट के तौर पर दिया जा सके. इन फ़ाइलों को, सीधे तौर पर या ट्रांज़िटिव क्लोज़र के ज़रिए, इस लाइब्रेरी पर निर्भर किसी भी android_library टारगेट के लिए इंपोर्ट के तौर पर उपलब्ध कराया जाएगा. हालांकि, इन्हें Java में अनुवाद नहीं किया जाएगा या कंपाइल नहीं किया जाएगा.

इस लाइब्रेरी में, पहले से प्रोसेस की गई सिर्फ़ ऐसी .aidl फ़ाइलें शामिल की जानी चाहिए जो सीधे तौर पर .java सोर्स से जुड़ी हों. जैसे, Parcelable के कस्टम लागू होने. इसके अलावा, उन Android IDL डेफ़िनिशन के लिए idl_srcs का इस्तेमाल करें जिन्हें Java इंटरफ़ेस में बदलना है. साथ ही, पहले से प्रोसेस नहीं की गई AIDL फ़ाइलों के लिए idl_parcelable का इस्तेमाल करें.

idl_srcs

लेबल की सूची; डिफ़ॉल्ट [] है

Java इंटरफ़ेस में अनुवाद करने के लिए, Android IDL की परिभाषाओं की सूची. Java इंटरफ़ेस जनरेट होने के बाद, उन्हें srcs के कॉन्टेंट के साथ एक साथ संकलित किया जाएगा.

इन फ़ाइलों को, सीधे तौर पर या ट्रांज़िटिव क्लोज़र के ज़रिए, इस लाइब्रेरी पर निर्भर किसी भी android_library टारगेट के लिए इंपोर्ट के तौर पर उपलब्ध कराया जाएगा.

aidl कंपाइलर को ये फ़ाइलें ढूंढने के लिए, उन्हें सही जगह पर रखना ज़रूरी है. इसका क्या मतलब है, इस बारे में जानने के लिए idl_import_root के बारे में जानकारी देखें.
javacopts

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

इस टारगेट के लिए, कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.

कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac को पास किए जाते हैं.
manifest

लेबल; डिफ़ॉल्ट None है

Android मेनिफ़ेस्ट फ़ाइल का नाम, आम तौर पर AndroidManifest.xml. अगर resource_files या ऐसेट की जानकारी दी गई है, तो इसकी जानकारी देना ज़रूरी है.

बूलियन; डिफ़ॉल्ट तौर पर False

इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए करें, न कि रनटाइम के दौरान. neverlink के तौर पर मार्क किए गए नियम के आउटपुट का इस्तेमाल, .apk बनाने में नहीं किया जाएगा. यह तब काम का होता है, जब लाइब्रेरी को रनटाइम एनवायरमेंट से, प्रोग्राम के रन होने के दौरान उपलब्ध कराया जाएगा.
plugins

लेबल की सूची; डिफ़ॉल्ट [] है

कंपाइल के समय चलने वाले Java कंपाइलर प्लग इन. प्लग इन एट्रिब्यूट में बताए गए हर java_plugin को, इस टारगेट के बनने पर चलाया जाएगा. प्लग इन से जनरेट किए गए संसाधन, टारगेट के नतीजे के jar में शामिल किए जाएंगे.
proguard_specs

लेबल की सूची; डिफ़ॉल्ट [] है

Proguard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इनमें, Proguard के इस्तेमाल के लिए स्पेसिफ़िकेशन के सेट के बारे में बताया जाएगा. अगर इनका इस्तेमाल किया जाता है, तो उन्हें इस लाइब्रेरी के आधार पर, किसी भी android_binary टारगेट में जोड़ दिया जाएगा. यहां शामिल फ़ाइलों में सिर्फ़ एक जैसे नियम होने चाहिए. जैसे, -dontnote, -dontwarn, assumenosideeffects, और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ android_binary के proguard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि टॉटोलॉजिकल मर्ज न हों.
resource_files

लेबल की सूची; डिफ़ॉल्ट [] है

पैकेज किए जाने वाले संसाधनों की सूची. आम तौर पर, यह res डायरेक्ट्री में मौजूद सभी फ़ाइलों का glob होता है.
जनरेट की गई फ़ाइलों (genrules से) का रेफ़रंस, यहां भी लेबल से लिया जा सकता है. हालांकि, इस पर एक पाबंदी है. जनरेट किए गए आउटपुट, शामिल की गई किसी भी अन्य संसाधन फ़ाइल की तरह ही "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, instruments एट्रिब्यूट की मदद से, जांच में शामिल 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

नाम; यह ज़रूरी है

इस टारगेट के लिए यूनीक नाम.
support_apks

लेबल की सूची; डिफ़ॉल्ट [] है

इंस्ट्रूमेंटेशन टेस्ट शुरू होने से पहले, डिवाइस पर इंस्टॉल करने के लिए अन्य APK.
target_device

लेबल; ज़रूरी है

वह android_device जिस पर टेस्ट चलाना है.

पहले से चल रहे किसी एमुलेटर या किसी फ़िज़िकल डिवाइस पर टेस्ट चलाने के लिए, इन आर्ग्युमेंट का इस्तेमाल करें: --test_output=streamed --test_arg=--device_broker_type=LOCAL_ADB_SERVER --test_arg=--device_serial_number=$device_identifier
test_app

लेबल; ज़रूरी है

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: सोर्स ("सोर्स jar") वाला संग्रह.
  • name_deploy.jar: डिप्लॉयमेंट के लिए सही Java डिप्लॉयमेंट संग्रह (सिर्फ़ साफ़ तौर पर अनुरोध किए जाने पर बनाया जाता है).

उदाहरण

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

http_archive(
    name = "robolectric",
    urls = ["https://github.com/robolectric/robolectric-bazel/archive/<COMMIT>.tar.gz"],
    strip_prefix = "robolectric-bazel-<COMMIT>",
    sha256 = "<HASH>",
)
load("@robolectric//bazel:robolectric.bzl", "robolectric_repositories")
robolectric_repositories()
यह Robolectric के लिए ज़रूरी maven_jar नियमों को खींचता है. इसके बाद, हर android_local_test नियम, @robolectric//bazel:robolectric पर निर्भर होना चाहिए. नीचे उदाहरण देखें। 

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

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

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

इस टारगेट के लिए यूनीक नाम.
deps

लेबल की सूची; डिफ़ॉल्ट [] है

जिन लाइब्रेरी की जांच करनी है उनकी सूची के साथ-साथ, टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. इस एट्रिब्यूट के ट्रांज़िशन क्लोज़र में, Android के नियमों में बताए गए सभी रिसॉर्स, ऐसेट, और मेनिफ़ेस्ट फ़ाइलें, जांच में उपलब्ध कराई जाती हैं.

deps में इस्तेमाल किए जा सकने वाले नियमों की सूची में android_library, aar_import, java_import, java_library, और java_lite_proto_library शामिल हैं.

srcs

लेबल की सूची; डिफ़ॉल्ट [] है

टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. नीचे बताए गए खास मामले को छोड़कर, यह ज़रूरी है.

.java टाइप की srcs फ़ाइलें कंपाइल की जाती हैं. कॉन्टेंट को आसानी से पढ़ने के लिए, जनरेट की गई .java सोर्स फ़ाइल का नाम srcs में डालना अच्छा नहीं है. इसके बजाय, srcs में उस नियम का नाम डालें जिस पर यह नियम निर्भर करता है, जैसा कि यहां बताया गया है.

.srcjar टाइप की srcs फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule या बिल्ड एक्सटेंशन की मदद से .java फ़ाइलों का सेट जनरेट करना हो.)

ऊपर बताए गए फ़ाइल टाइप की कम से कम एक फ़ाइल मौजूद होने पर, अन्य सभी फ़ाइलों को अनदेखा कर दिया जाता है. ऐसा न करने पर, गड़बड़ी का मैसेज दिखता है.

srcs एट्रिब्यूट की वैल्यू सबमिट करना ज़रूरी है. साथ ही, अगर runtime_deps एट्रिब्यूट की वैल्यू सबमिट नहीं की जाती है, तो srcs एट्रिब्यूट की वैल्यू भी खाली नहीं होनी चाहिए.

custom_package

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

वह Java पैकेज जिसमें R क्लास जनरेट की जाएगी. डिफ़ॉल्ट रूप से, पैकेज का अनुमान उस डायरेक्ट्री से लगाया जाता है जहां नियम वाली BUILD फ़ाइल मौजूद होती है. अगर इस एट्रिब्यूट का इस्तेमाल किया जाता है, तो आपको test_class का भी इस्तेमाल करना पड़ सकता है.
densities

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

APK बनाते समय, फ़िल्टर करने के लिए डेंसिटी. अगर मेनिफ़ेस्ट में पहले से ही कोई सुपरसेट StarlarkListing मौजूद नहीं है, तो मेनिफ़ेस्ट में काम करने वाली स्क्रीन से जुड़ा एक सेक्शन भी जोड़ा जाएगा.
enable_data_binding

बूलियन; डिफ़ॉल्ट तौर पर False

अगर यह सही है, तो यह नियम इस जांच में इस्तेमाल की गई, डेटा-बाइंडिंग की सुविधा वाली डिपेंडेंसी में इस्तेमाल किए गए डेटा बाइंडिंग रेफ़रंस को प्रोसेस करता है. इस सेटिंग के बिना, डेटा-बाइंडिंग डिपेंडेंसी में ज़रूरी बाइनरी-लेवल कोड जनरेशन नहीं होगा. साथ ही, हो सकता है कि बिल्ड न हो पाए.
javacopts

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.

कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac को पास किए जाते हैं.
jvm_flags

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में जोड़ने के लिए फ़्लैग की सूची. $(location) और "Make variable" के बदले, और Bourne shell tokenization के हिसाब से.

Java बाइनरी के लिए रैपर स्क्रिप्ट में CLASSPATH परिभाषा शामिल होती है, ताकि सभी डिपेंडेंट jar ढूंढे जा सकें. साथ ही, यह सही Java इंटरप्रेटर को भी चालू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम और उसके बाद "$@" होता है, ताकि क्लास के नाम के बाद अन्य आर्ग्युमेंट पास किए जा सकें. हालांकि, JVM के पास पार्स करने के लिए, कमांड लाइन पर क्लास के नाम से पहले आर्ग्युमेंट होने चाहिए. क्लास का नाम शामिल किए जाने से पहले, jvm_flags के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ा जाता है.

ध्यान दें कि इस एट्रिब्यूट का *_deploy.jar आउटपुट पर कोई असर नहीं पड़ता.
manifest

लेबल; डिफ़ॉल्ट None है

Android मेनिफ़ेस्ट फ़ाइल का नाम, आम तौर पर AndroidManifest.xml. अगर resource_files या ऐसेट की जानकारी दी गई है या जांच में शामिल लाइब्रेरी के किसी भी मेनिफ़ेस्ट में minSdkVersion टैग है, तो इसकी जानकारी देना ज़रूरी है.
manifest_values

डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; डिफ़ॉल्ट तौर पर {}

मेनिफ़ेस्ट में बदली जाने वाली वैल्यू की डिक्शनरी. मेनिफ़ेस्ट में ${name} के किसी भी इंस्टेंस को, इस डिक्शनरी में name से जुड़ी वैल्यू से बदल दिया जाएगा. applicationId, versionCode, versionName, minSdkVersion, targetSdkVersion, और maxSdkVersion, मेनिफ़ेस्ट और uses-sdk टैग के मिलते-जुलते एट्रिब्यूट को भी बदल देंगे. packageName को अनदेखा कर दिया जाएगा. अगर applicationId की वैल्यू दी गई है, तो इसे applicationId से सेट किया जाएगा. अगर applicationId की वैल्यू नहीं दी गई है, तो इसे मेनिफ़ेस्ट में मौजूद पैकेज से सेट किया जाएगा. manifest_values का इस्तेमाल करने के लिए, यह ज़रूरी नहीं है कि नियम में मेनिफ़ेस्ट हो.
nocompress_extensions

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

उन फ़ाइल एक्सटेंशन की सूची जिन्हें रिसॉर्स APK में बिना कंप्रेस किए छोड़ा जाना है.
plugins

लेबल की सूची; डिफ़ॉल्ट [] है

कंपाइल के समय चलने वाले Java कंपाइलर प्लग इन. जब भी यह नियम बनाया जाएगा, तब इस एट्रिब्यूट में बताए गए हर java_plugin को चलाया जाएगा. लाइब्रेरी को उन डिपेंडेंसी से भी प्लग इन इनहेरिट हो सकते हैं जिनमें exported_plugins का इस्तेमाल किया जाता है. प्लग इन से जनरेट किए गए संसाधन, इस नियम के नतीजे के जार में शामिल किए जाएंगे.
resource_configuration_filters

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

'en' जैसे संसाधन कॉन्फ़िगरेशन फ़िल्टर की सूची, जो APK में मौजूद संसाधनों को सिर्फ़ 'en' कॉन्फ़िगरेशन में सीमित कर देगी.
resource_jars

लेबल की सूची; डिफ़ॉल्ट [] है

अब काम नहीं करता: इसके बजाय, java_import और deps या runtime_deps का इस्तेमाल करें.
resource_strip_prefix

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

Java रिसॉर्स से हटाने के लिए पाथ प्रीफ़िक्स.

अगर यह जानकारी दी गई है, तो resources एट्रिब्यूट में मौजूद हर फ़ाइल से यह पाथ प्रीफ़िक्स हटा दिया जाता है. अगर कोई संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है, तो यह गड़बड़ी है. अगर यह पैरामीटर तय नहीं किया गया है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ, सोर्स फ़ाइलों के Java पैकेज के उसी लॉजिक के हिसाब से तय किया जाता है. उदाहरण के लिए, stuff/java/foo/bar/a.txt पर मौजूद सोर्स फ़ाइल, foo/bar/a.txt पर मौजूद होगी.

runtime_deps

लेबल की सूची; डिफ़ॉल्ट [] है

ऐसी लाइब्रेरी जिन्हें फ़ाइनल बाइनरी या सिर्फ़ रनटाइम के दौरान टेस्ट करने के लिए उपलब्ध कराया जाता है. सामान्य deps की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, ये deps के उलट, कंपाइल-टाइम क्लासपाथ पर नहीं दिखेंगे. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी को यहां सूची में शामिल किया जाना चाहिए. डिपेंडेंसी-ऐनालिसिस टूल को उन टारगेट को अनदेखा करना चाहिए जो runtime_deps और deps, दोनों में दिखते हैं.
stamp

पूर्णांक; डिफ़ॉल्ट वैल्यू 0 है

बिल्ड की जानकारी को बाइनरी में एन्कोड करना है या नहीं. वैल्यू, इनमें से कोई हो सकती है:
  • stamp = 1: बिल्ड की जानकारी को हमेशा बाइनरी में स्टैंप करें. ऐसा --nostamp बिल्ड में भी करें. इस सेटिंग का इस्तेमाल नहीं किया जाना चाहिए, क्योंकि इससे बिटरी और उस पर निर्भर सभी डाउनस्ट्रीम ऐक्शन के लिए, रिमोट कैश मेमोरी का इस्तेमाल नहीं किया जा सकता.
  • stamp = 0: हमेशा बिल्ड की जानकारी को कॉन्स्टेंट वैल्यू से बदलें. इससे, बिल्ड के नतीजे को कैश मेमोरी में सेव करने की सुविधा मिलती है.
  • stamp = -1: बाइल्ड की जानकारी को एम्बेड करने की सुविधा, --[no]stamp फ़्लैग से कंट्रोल की जाती है.

स्टैंप की गई बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो जाए.
test_class

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

टेस्ट रनर से लोड की जाने वाली Java क्लास.

इस एट्रिब्यूट से, उस Java क्लास का नाम पता चलता है जिसे इस टेस्ट से चलाया जाना है. आम तौर पर, इसे सेट करने की ज़रूरत नहीं होती. अगर इस आर्ग्युमेंट को छोड़ दिया जाता है, तो उस Java क्लास का इस्तेमाल किया जाएगा जिसका नाम इस android_local_test नियम के name से मेल खाता है. टेस्ट क्लास को org.junit.runner.RunWith के साथ एनोटेट करना होगा.

use_launcher

बूलियन; डिफ़ॉल्ट तौर पर True

बाइनरी को कस्टम लॉन्चर का इस्तेमाल करना चाहिए या नहीं.

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

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

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

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

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

इस टारगेट के लिए यूनीक नाम.
cache

इंटिजर; ज़रूरी है

एम्युलेटर के कैश पार्टिशन का साइज़, मेगाबाइट में. इसकी कम से कम वैल्यू 16 मेगाबाइट है.
default_properties

लेबल; डिफ़ॉल्ट None है

एमुलेटर पर /default.prop में डाली जाने वाली एक प्रॉपर्टी फ़ाइल. इससे नियम बनाने वाले व्यक्ति को एमुलेटर को ज़्यादा से ज़्यादा असली डिवाइस जैसा दिखाने के लिए कॉन्फ़िगर करने में मदद मिलती है. खास तौर पर, इसकी यूज़र-एजेंट स्ट्रिंग और अन्य व्यवहार को कंट्रोल करने में, जिसकी वजह से किसी ऐप्लिकेशन या सर्वर का व्यवहार किसी खास डिवाइस के मुकाबले अलग हो सकता है. इस फ़ाइल में मौजूद प्रॉपर्टी, रीड-ओनली प्रॉपर्टी को बदल देंगी. आम तौर पर, ये प्रॉपर्टी एमुलेटर सेट करता है, जैसे कि ro.product.model.
horizontal_resolution

इंटिजर; ज़रूरी है

जिस हॉरिज़ॉन्टल स्क्रीन रिज़ॉल्यूशन को एमुलेट करना है उसका पिक्सल में साइज़. वैल्यू कम से कम 240 होनी चाहिए.
platform_apks

लेबल की सूची; डिफ़ॉल्ट [] है

डिवाइस के बूट होने पर इंस्टॉल होने वाले APK की सूची.
ram

इंटिजर; ज़रूरी है

डिवाइस के लिए, एम्युलेट करने के लिए रैम की संख्या मेगाबाइट में. यह सेटिंग, डिवाइस पर इंस्टॉल किए गए किसी खास ऐप्लिकेशन के लिए नहीं, बल्कि पूरे डिवाइस के लिए है. कम से कम वैल्यू 64 मेगाबाइट होनी चाहिए.
screen_density

इंटिजर; ज़रूरी है

एम्युलेट की गई स्क्रीन की डेंसिटी, पिक्सल प्रति इंच में. इसकी कम से कम वैल्यू 30 पीपीआई है.
system_image

लेबल; ज़रूरी है

फ़ाइल ग्रुप, जिसमें ये फ़ाइलें शामिल हैं:
  • system.img: सिस्टम पार्टीशन
  • kernel-qemu: यह Linux कर्नेल है, जिसे एम्युलेटर लोड करेगा
  • ramdisk.img: बूट के समय इस्तेमाल की जाने वाली initrd इमेज
  • userdata.img: शुरुआती userdata पार्टीशन
  • source.properties: यह एक प्रॉपर्टी फ़ाइल है, जिसमें इमेज के बारे में जानकारी होती है
ये फ़ाइलें, Android SDK का हिस्सा होती हैं या इन्हें तीसरे पक्ष उपलब्ध कराते हैं. उदाहरण के लिए, Intel, x86 इमेज उपलब्ध कराता है.
vertical_resolution

इंटिजर; ज़रूरी है

एमुलेट करने के लिए, वर्टिकल स्क्रीन रिज़ॉल्यूशन पिक्सल में. वैल्यू कम से कम 240 होनी चाहिए.
vm_heap

इंटिजर; ज़रूरी है

वर्चुअल मशीन के ढेर का साइज़, जो Android हर प्रोसेस के लिए इस्तेमाल करेगा. यह साइज़ एमबी में होता है. कम से कम वैल्यू 16 मेगाबाइट होनी चाहिए.

android_ndk_repository

नियम का सोर्स देखें 
android_ndk_repository(name, api_level, path, repo_mapping)

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

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

ध्यान दें कि Android के लिए ऐप्लिकेशन बनाने के लिए, आपकी WORKSPACE फ़ाइल में android_sdk_repository नियम भी होना चाहिए.

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

cpufeatures

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

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

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

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

इस टारगेट के लिए यूनीक नाम.
api_level

पूर्णांक; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट 0 है

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

स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट "" है

Android NDK का ऐब्सलूट या रिलेटिव पाथ. इस एट्रिब्यूट या $ANDROID_NDK_HOME एनवायरमेंट वैरिएबल में से किसी एक को सेट करना ज़रूरी है.

Android एनडीके को Android डेवलपर साइट से डाउनलोड किया जा सकता है.

repo_mapping

डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; डिफ़ॉल्ट तौर पर {}

लोकल डेटा स्टोर करने की जगह के नाम से ग्लोबल डेटा स्टोर करने की जगह के नाम की डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है.

उदाहरण के लिए, "@foo": "@bar" एंट्री से पता चलता है कि जब भी यह रिपॉज़िटरी "@foo" पर निर्भर करता है, तो उसे ग्लोबल तौर पर बताए गए "@bar" ("@bar//some:target") में उस डिपेंडेंसी को हल करना चाहिए. जैसे, "@foo//some:target" पर डिपेंडेंसी.

android_sdk_repository

नियम का सोर्स देखें 
android_sdk_repository(name, api_level, build_tools_version, path, repo_mapping)

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

उदाहरण

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

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

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

जनरेट किए गए टारगेट के नाम, Android सहायता रिपॉज़िटरी में मौजूद लाइब्रेरी के मेवन कोऑर्डिनेट से लिए जाते हैं. इन्हें @androidsdk//${group}:${artifact}-${version} के तौर पर फ़ॉर्मैट किया जाता है. इस उदाहरण में दिखाया गया है कि android_library, v7 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

नाम; यह ज़रूरी है

इस टारगेट के लिए यूनीक नाम.
api_level

पूर्णांक; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट 0 है

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

किसी खास बिल्ड के लिए इस्तेमाल किए गए एपीआई लेवल को android_sdk फ़्लैग से बदला जा सकता है. android_sdk_repository, @androidsdk//:sdk-${level} नाम वाले SDK टूल में इंस्टॉल किए गए हर एपीआई लेवल के लिए एक 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

स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट "" है

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

Bazel के लिए, बिल्ड टूल का 30.0.0 या इसके बाद का वर्शन ज़रूरी है.

path

स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट "" है

Android SDK टूल का ऐब्सलूट या रिलेटिव पाथ. इस एट्रिब्यूट या $ANDROID_HOME एनवायरमेंट वैरिएबल में से किसी एक को सेट करना ज़रूरी है.

Android SDK को Android डेवलपर साइट से डाउनलोड किया जा सकता है.

repo_mapping

डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; डिफ़ॉल्ट तौर पर {}

लोकल डेटा स्टोर करने की जगह के नाम से ग्लोबल डेटा स्टोर करने की जगह के नाम की डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है.

उदाहरण के लिए, "@foo": "@bar" एंट्री से पता चलता है कि जब भी यह रिपॉज़िटरी "@foo" पर निर्भर करता है, तो उसे ग्लोबल तौर पर बताए गए "@bar" ("@bar//some:target") में उस डिपेंडेंसी को हल करना चाहिए. जैसे, "@foo//some:target" पर डिपेंडेंसी.