Android के नियम

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

नियम

android_binary

नियम का सोर्स देखें 
android_binary(name, deps, srcs, assets, assets_dir, compatible_with, crunch_png, custom_package, debug_key, debug_signing_keys, debug_signing_lineage_file, densities, deprecation, dex_shards, dexopts, distribs, enable_data_binding, exec_compatible_with, exec_properties, features, incremental_dexing, instruments, javacopts, key_rotation_min_sdk, licenses, main_dex_list, main_dex_list_opts, main_dex_proguard_specs, manifest, manifest_values, multidex, nocompress_extensions, package_id, plugins, proguard_apply_dictionary, proguard_apply_mapping, proguard_generate_mapping, proguard_specs, resource_configuration_filters, resource_files, restricted_to, shrink_resources, tags, target_compatible_with, testonly, visibility)

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

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

  • name.apk: यह Android ऐप्लिकेशन पैकेज फ़ाइल है. इस पर डीबग की से हस्ताक्षर किया गया है. साथ ही, यह zipaligned है. इसका इस्तेमाल, ऐप्लिकेशन को डेवलप और डीबग करने के लिए किया जा सकता है. डीबग कुंजियों से साइन किए गए ऐप्लिकेशन को रिलीज़ नहीं किया जा सकता.
  • name_unsigned.apk: ऊपर दी गई फ़ाइल का बिना हस्ताक्षर किया गया वर्शन. इसे सार्वजनिक तौर पर रिलीज़ करने से पहले, रिलीज़ की कुंजियों से साइन किया जा सकता है.
  • name_deploy.jar: यह एक Java संग्रह है. इसमें इस टारगेट का ट्रांज़िटिव क्लोज़र शामिल होता है.

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

  • name_proguard.jar: यह एक Java संग्रह है. इसमें name_deploy.jar पर ProGuard चलाने का नतीजा शामिल होता है. यह आउटपुट सिर्फ़ तब जनरेट होता है, जब proguard_specs एट्रिब्यूट की वैल्यू दी गई हो.
  • name_proguard.map: यह name_deploy.jar पर ProGuard चलाने के बाद मिली मैपिंग फ़ाइल का नतीजा है. यह आउटपुट सिर्फ़ तब जनरेट होता है, जब proguard_specs एट्रिब्यूट की वैल्यू दी गई हो और proguard_generate_mapping या shrink_resources एट्रिब्यूट की वैल्यू सेट की गई हो.

उदाहरण

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

तर्क

विशेषताएं
name

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

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

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

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

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

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

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

srcs फ़ाइलें अनपैक की जाती हैं और .srcjar टाइप की फ़ाइलों को कंपाइल किया जाता है. (यह तब काम आता है, जब आपको 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 का साइज़ कम हो जाएगा. अगर मेनिफ़ेस्ट में पहले से ही सुपरसेट की सूची शामिल नहीं है, तो उसमें compatible-screens सेक्शन भी जोड़ दिया जाएगा.
dex_shards

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

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

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

dexopts

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

classes.dex जनरेट करते समय, dx टूल के लिए अतिरिक्त कमांड-लाइन फ़्लैग. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है.
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

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

इस टारगेट के लिए कंपाइलर के अतिरिक्त विकल्प. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है.

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

स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है

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

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

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

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

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

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

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

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

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

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

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

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

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

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

manifest_merger को legacy पर सेट करने पर, सिर्फ़ applicationId, versionCode, और versionName का असर होगा.

multidex

स्ट्रिंग; डिफ़ॉल्ट वैल्यू "native" है

कोड को कई डेक्स फ़ाइलों में बांटना है या नहीं.
इन वैल्यू का इस्तेमाल किया जा सकता है:
  • native: जब dex 64K इंडेक्स की सीमा पार हो जाती है, तब कोड को कई dex फ़ाइलों में बाँटें. यह मानकर चलता है कि नेटिव प्लैटफ़ॉर्म, रनटाइम के दौरान मल्टीडेक्स क्लास लोड करने की सुविधा देता है. यह सुविधा सिर्फ़ Android L और उसके बाद के वर्शन पर काम करती है.
  • legacy: जब dex 64K इंडेक्स की सीमा पार हो जाती है, तब कोड को कई dex फ़ाइलों में बाँटें. यह मान लिया जाता है कि मल्टीडेक्स क्लास, ऐप्लिकेशन कोड के ज़रिए लोड की जाती हैं. इसका मतलब है कि नेटिव प्लैटफ़ॉर्म के लिए कोई सहायता उपलब्ध नहीं है.
  • manual_main_dex: जब dex 64K इंडेक्स की सीमा पार हो जाती है, तब कोड को कई dex फ़ाइलों में बाँटें. मुख्य डेक्स फ़ाइल के कॉन्टेंट के बारे में बताने के लिए, main_dex_list एट्रिब्यूट का इस्तेमाल करके, टेक्स्ट फ़ाइल में क्लास की सूची दें.
  • off: सभी कोड को एक ही डेक्स फ़ाइल में कंपाइल करें. भले ही, यह इंडेक्स की सीमा से ज़्यादा हो.
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' कॉन्फ़िगरेशन वाले संसाधनों तक सीमित हो जाएंगे. स्यूडोलोकल सेटिंग चालू करने के लिए, en_XA और/या ar_XB स्यूडो-लोकल शामिल करें.
resource_files

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

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

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

उदाहरण

    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

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

.aar फ़ाइल, Android के उन टारगेट को दी जाती है जो इस टारगेट पर निर्भर करते हैं.
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' बंडल है. इसमें इस टारगेट का 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 रैप या .so नेटिव लाइब्रेरी जनरेट करती हो Android टारगेट प्लैटफ़ॉर्म के लिए.
srcs

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

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

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

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

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

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_plugin की सूची (जैसे, एनोटेशन प्रोसेसर). इन्हें उन लाइब्रेरी में एक्सपोर्ट किया जाता है जो सीधे तौर पर इस लाइब्रेरी पर निर्भर करती हैं.

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

exports

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

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

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

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

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

स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है

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

इस पाथ का इस्तेमाल, इंपोर्ट रूट के तौर पर किया जाएगा. ऐसा उन आईडीएल सोर्स को प्रोसेस करते समय किया जाएगा जो इस लाइब्रेरी पर निर्भर करते हैं.

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 में अनुवादित या कंपाइल नहीं किया जाएगा.

इस लाइब्रेरी में, सीधे तौर पर .java सोर्स से जुड़ी सिर्फ़ .aidl फ़ाइलें शामिल की जानी चाहिए.उदाहरण के लिए, 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

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

इस टारगेट के लिए कंपाइलर के अतिरिक्त विकल्प. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

custom_package

स्ट्रिंग; डिफ़ॉल्ट वैल्यू "" है

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

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

एपीके बनाते समय फ़िल्टर करने के लिए डेंसिटी. अगर मेनिफ़ेस्ट में पहले से कोई superset StarlarkListing शामिल नहीं है, तो उसमें compatible-screens सेक्शन भी जोड़ दिया जाएगा.
enable_data_binding

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

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

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

इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है.

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

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

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

Java बाइनरी के लिए रैपर स्क्रिप्ट में CLASSPATH की परिभाषा शामिल होती है. इससे सभी डिपेंडेंट जार फ़ाइलें मिलती हैं. साथ ही, यह सही 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 से सेट किया जाएगा. अगर यह जानकारी दी गई है, तो इसे मेनिफ़ेस्ट में मौजूद पैकेज से सेट किया जाएगा. 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 की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, उनसे अलग, ये कंपाइल-टाइम क्लासपाथ पर नहीं दिखेंगे. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी यहां दी जानी चाहिए. डिपेंडेंसी का विश्लेषण करने वाले टूल को उन टारगेट को अनदेखा करना चाहिए जो 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 टेस्ट और Blaze रन के लिए --run_under फ़्लैग का सही टारगेट है. यह एक एम्युलेटर शुरू करता है. साथ ही, जिस टारगेट की जांच की जा रही है/चलाया जा रहा है उसे एम्युलेटर पर कॉपी करता है. इसके बाद, टारगेट की जांच करता है या उसे ज़रूरत के हिसाब से चलाता है.

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

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

  • 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: Either start or kill.
  • --apks_to_install: एम्युलेटर पर इंस्टॉल किए जाने वाले APK की सूची.

तर्क

विशेषताएं
name

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

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

पूर्णांक; ज़रूरी है

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

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

एक प्रॉपर्टी फ़ाइल, जिसे एम्युलेटर पर /default.prop में रखा जाना है. इससे नियम बनाने वाला व्यक्ति, एम्युलेटर को और ज़्यादा कॉन्फ़िगर कर सकता है, ताकि वह किसी असली डिवाइस की तरह दिखे. खास तौर पर, वह इसके UserAgent स्ट्रिंग और अन्य व्यवहार को कंट्रोल कर सकता है. इससे कोई ऐप्लिकेशन या सर्वर, किसी खास डिवाइस के साथ अलग तरह से काम कर सकता है. इस फ़ाइल में मौजूद प्रॉपर्टी, रीड-ओनली प्रॉपर्टी को बदल देंगी. ये प्रॉपर्टी आम तौर पर, एम्युलेटर सेट करता है. जैसे, 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 में लागू किए गए वर्शन से बदला जा रहा है. एनडीके के आने वाले वर्शन के लिए सहायता, android_ndk_repository के Starlark वर्शन में लागू की जाएगी. इसमें वर्शन 25 और इसके बाद के वर्शन शामिल हैं. Starlark वर्शन के लिए, rules_android_ndk देखें.

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

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

उदाहरण

android_ndk_repository(
    name = "androidndk",
)

ऊपर दिए गए उदाहरण में, आपके Android NDK को $ANDROID_NDK_HOME से खोजा जाएगा. साथ ही, यह पता लगाया जाएगा कि यह सबसे ज़्यादा किस एपीआई लेवल के साथ काम करता है. 

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

ऊपर दिए गए उदाहरण में, आपके फ़ाइल फ़ोल्डर में मौजूद Android NDK का इस्तेमाल किया जाएगा. यह ./android-ndk-r20 में मौजूद है. यह आपके 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 NDK को 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)

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

उदाहरण

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

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

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

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

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

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

जनरेट किए गए टारगेट के नाम, Android Support Repository में मौजूद लाइब्रेरी के मेवन कोऑर्डिनेट से लिए जाते हैं. इन्हें @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, एसडीके में इंस्टॉल किए गए हर एपीआई लेवल के लिए android_sdk टारगेट बनाता है. इसका नाम @androidsdk//:sdk-${level} होता है. भले ही, इस एट्रिब्यूट की जानकारी दी गई हो या नहीं. उदाहरण के लिए, किसी नॉन-डिफ़ॉल्ट एपीआई लेवल के लिए: bazel build --android_sdk=@androidsdk//:sdk-19 //java/com/example:app.

android_sdk_repository से जनरेट किए गए सभी android_sdk टारगेट देखने के लिए, bazel query "kind(android_sdk, @androidsdk//...)" चलाया जा सकता है.

build_tools_version

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

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") के अंदर उस निर्भरता को हल करना चाहिए.