Android के नियम

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 के नियमों के उदाहरण, बैजल सोर्स ट्री की examples/android डायरेक्ट्री में मिल सकते हैं.

तर्क

विशेषताएं
name

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

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

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

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

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

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

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

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

assets

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

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

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

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

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

PNG क्रंचिंग करें या नहीं. यह नाइन-पैच प्रोसेसिंग से अलग है, जो हमेशा की जाती है. यह aapt Bug के लिए काम नहीं करता है. इस समस्या को 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_sign_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 की बदली हुई साइनिंग कुंजी का इस्तेमाल किया जाना चाहिए. APK की ओरिजनल साइनिंग पासकोड का इस्तेमाल, प्लैटफ़ॉर्म के पिछले सभी वर्शन के लिए किया जाएगा.
main_dex_list

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

टेक्स्ट फ़ाइल में क्लास फ़ाइल के नामों की सूची होती है. उन क्लास की फ़ाइलों से तय की गई क्लास को प्राइमरी क्लास.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 को चलाया जाएगा. प्लग इन से जनरेट किए गए रिसॉर्स, टारगेट के रिज़ल्ट जार में शामिल किए जाएंगे.
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' कॉन्फ़िगरेशन में मौजूद रिसॉर्स तक सीमित हो जाएंगे. pseudolocalization को चालू करने के लिए, en_XA और/या ar_XB pseudo-locales शामिल करें.
resource_files

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

पैकेज किए जाने वाले संसाधनों की सूची. आम तौर पर, यह res डायरेक्ट्री के तहत आने वाली सभी फ़ाइलों का glob होता है.
जनरेट की गई फ़ाइलों (genआप से मिली जानकारी) का रेफ़रंस, यहां लेबल से भी दिया जा सकता है. सिर्फ़ यह पाबंदी है कि जनरेट किए गए आउटपुट, किसी भी दूसरी रिसॉर्स फ़ाइल की तरह ही "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: ऐसा संग्रह जिसमें सोर्स शामिल हों ("सोर्स जार").
  • name.aar: एक Android 'aar' बंडल, जिसमें इस टारगेट के JavaScript संग्रह और संसाधन मौजूद होते हैं. इसमें ट्रांज़िटिव क्लोज़र शामिल नहीं है.

उदाहरण

Android के नियमों के उदाहरण, बैजल सोर्स ट्री की 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 फ़ाइलें कंपाइल की जाती हैं. कॉन्टेंट को आसानी से पढ़ने के लिए, srcs में जनरेट की गई .java सोर्स फ़ाइल का नाम नहीं डालना चाहिए. इसके बजाय, 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 डेफ़िनिशन को Java इंटरफ़ेस में बदलना है उनके लिए idl_srcs का इस्तेमाल करें. साथ ही, पहले से प्रोसेस नहीं की गई AIDL फ़ाइलों के लिए idl_parcelable का इस्तेमाल करें.

idl_srcs

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

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

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

इन फ़ाइलों को सही जगह पर रखना ज़रूरी है, ताकि एडल कंपाइलर उन्हें ढूंढ सके. इसका मतलब जानने के लिए 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

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

इंस्ट्रुमेंटेशन टेस्ट शुरू होने से पहले, डिवाइस पर इंस्टॉल किए जाने वाले अन्य APKs.
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 फ़ाइलें कंपाइल की जाती हैं. कॉन्टेंट को आसानी से पढ़ने के लिए, srcs में जनरेट की गई .java सोर्स फ़ाइल का नाम नहीं डालना चाहिए. इसके बजाय, srcs में उस नियम का नाम डालें जिस पर यह नियम निर्भर करता है, जैसा कि यहां बताया गया है.

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

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

srcs एट्रिब्यूट ज़रूरी है और इसे खाली नहीं छोड़ा जा सकता. ऐसा तब तक होता है, जब तक runtime_deps न बताया गया हो.

custom_package

स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है

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

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

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

बूलियन; डिफ़ॉल्ट False है

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

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

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

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

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

इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में एम्बेड करने के लिए फ़्लैग की सूची. यह $(location) और "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है.

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

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

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

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

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

मेनिफ़ेस्ट में बदली जाने वाली वैल्यू की डिक्शनरी. मेनिफ़ेस्ट में मौजूद ${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 है

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

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

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

android_device के तहत केवीएम इमेज बनाई जा सकती हैं. इसके लिए ज़रूरी है कि मौजूदा 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

इस नियम से इमेज और स्टार्ट स्क्रिप्ट जनरेट होंगी. आपकी ओर से एम्युलेटर को स्थानीय तौर पर चालू करने के लिए बेज़ल रन :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: उपयोगकर्ता के डेटा का शुरुआती हिस्सा
  • 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 में लागू करने से बदला जा रहा है. एनडीके के 25 और इसके बाद के वर्शन के साथ-साथ आने वाले वर्शन भी android_ndk_repository के Starlark वर्शन में लागू किए जाएंगे. 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) का इस्तेमाल करेगा. आपका जेएनआई कोड कंपाइल करते समय, यह एपीआई लेवल 24 लाइब्रेरी का इस्तेमाल करेगा.

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

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

# 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 एनडीके का ऐब्सलूट या रिलेटिव पाथ. इस एट्रिब्यूट या $ANDROID_NDK_HOME एनवायरमेंट वैरिएबल में से किसी एक को सेट करना ज़रूरी है.

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

repo_mapping

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

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

उदाहरण के लिए, "@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)

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

उदाहरण

Basel के लिए Android SDK सेट अप करने का सबसे कम तरीका यह है कि आप अपनी WORKSPACE फ़ाइल में "androidsdk" नाम का android_sdk_repository नियम डालें और अपने Android SDK के पाथ के लिए $ANDROID_HOME एनवायरमेंट वैरिएबल सेट करें. 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 Manager में "Android सहायता डेटा स्टोर करने की जगह" के तौर पर उपलब्ध हैं. यह Android की सामान्य लाइब्रेरी का वर्शन वाला सेट है. जैसे, Support और AppCompat लाइब्रेरी, जो लोकल मेवन रिपॉज़िटरी के तौर पर पैकेज की जाती हैं. android_sdk_repository इन सभी लाइब्रेरी के लिए बेज़ल टारगेट जनरेट करता है, जिनका इस्तेमाल android_binary और android_library टारगेट डिपेंडेंसी में किया जा सकता है.

जनरेट किए गए टारगेट के नाम, Android सपोर्ट रिपॉज़िटरी में मौजूद लाइब्रेरी के Maven कोऑर्डिनेट से लिए जाते हैं. इनका फ़ॉर्मैट @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" पर निर्भर करती है (जैसे कि "@foo//some:target" पर डिपेंडेंसी), तो उसे दुनिया भर में एलान किए गए "@bar" ("@bar//some:target") में उस डिपेंडेंसी का समाधान करना चाहिए.