नियम
- android_binary
- aar_import
- android_library
- android_instrumentation_test
- android_local_test
- android_device
- android_ndk_repository
- android_sdk_repository
android_binary
android_binary(name, deps, srcs, assets, assets_dir, compatible_with, crunch_png, custom_package, debug_key, debug_signing_keys, debug_signing_lineage_file, densities, deprecation, dex_shards, dexopts, distribs, enable_data_binding, exec_compatible_with, exec_properties, features, incremental_dexing, instruments, javacopts, key_rotation_min_sdk, licenses, main_dex_list, main_dex_list_opts, main_dex_proguard_specs, manifest, manifest_values, multidex, nocompress_extensions, package_id, plugins, proguard_apply_dictionary, proguard_apply_mapping, proguard_generate_mapping, proguard_specs, resource_configuration_filters, resource_files, restricted_to, shrink_resources, tags, target_compatible_with, testonly, visibility)
Android ऐप्लिकेशन पैकेज फ़ाइलें (.apk) बनाता है.
इंप्लिसिट आउटपुट टारगेट
name.apk
: एक Android ऐप्लिकेशन पैकेज फ़ाइल जिसे डीबग कुंजियों से साइन किया गया हो और zipaligned बनाया गया हो, इसका इस्तेमाल आपके ऐप्लिकेशन को डेवलप और डीबग करने के लिए किया जा सकता है. डीबग कुंजियों से साइन किए हुए होने पर आप अपने ऐप्लिकेशन को रिलीज़ नहीं कर सकते.name_unsigned.apk
: ऊपर दी गई फ़ाइल का बिना हस्ताक्षर वाला वर्शन, जिसे सार्वजनिक रूप से रिलीज़ करने से पहले, रिलीज़ कुंजियों की मदद से साइन किया जा सकता है.name_deploy.jar
: एक Java संग्रह, जिसमें इस टारगेट को ट्रांज़िटिव क्लोज़र के तौर पर दिखाया गया है.डिप्लॉय किए गए जार में वे सभी क्लास शामिल होती हैं जो क्लासलोडर को मिलेंगी. यह वह क्लास होती है जिसने इस टारगेट के रनटाइम क्लासपाथ को शुरू से आखिर तक खोजा था.
name_proguard.jar
: एक Java संग्रह, जिसमेंname_deploy.jar
पर ProGuard चलाने का नतीजा शामिल है. यह आउटपुट सिर्फ़ तब बनता है, जब proguard_specs एट्रिब्यूट के बारे में बताया गया हो.name_proguard.map
:name_deploy.jar
पर ProGuard चलाने से मैप करने वाली फ़ाइल का नतीजा. यह आउटपुट सिर्फ़ तब बनता है, जब proguard_specs एट्रिब्यूट के बारे में बताया गया हो और proguard_generate_mapping या shrink_resources को सेट किया गया हो.
उदाहरण
Android के नियमों के उदाहरण, बेज़ल सोर्स ट्री की examples/android
डायरेक्ट्री में देखे जा सकते हैं.
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट के लिए एक खास नाम. |
deps
|
android_library ,
java_library , android कंस्ट्रेंट के साथ, और
Android टारगेट प्लैटफ़ॉर्म के लिए, .so नेटिव लाइब्रेरी
cc_library रैप कर रहे हैं या बना रहे हैं.
|
srcs
|
|
assets
|
assets डायरेक्ट्री में मौजूद सभी फ़ाइलों का glob होता है. आपके पास दूसरे पैकेज में एक्सपोर्ट किए गए या दूसरे नियमों (फ़ाइलें बनाने का नियम) या एक्सपोर्ट की गई फ़ाइलों का रेफ़रंस देने का विकल्प भी है. हालांकि, इसके लिए ज़रूरी है कि वे सभी फ़ाइलें, संबंधित पैकेज में मौजूद assets_dir डायरेक्ट्री में हों.
|
assets_dir
|
assets में मौजूद फ़ाइलों का पाथ देने वाली स्ट्रिंग.
assets और assets_dir , पैकेज की गई एसेट के बारे में जानकारी देते हैं.
साथ ही, दोनों एट्रिब्यूट की वैल्यू दी जानी चाहिए या किसी भी एट्रिब्यूट का इस्तेमाल नहीं किया जाना चाहिए.
|
crunch_png
|
|
custom_package
|
|
debug_key
|
चेतावनी: अपनी प्रोडक्शन कुंजियों का इस्तेमाल न करें. उनकी सुरक्षा के उपाय ज़रूर किए जाने चाहिए और उन्हें आपके सोर्स ट्री में नहीं रखा जाना चाहिए. |
debug_signing_keys
|
चेतावनी: अपनी प्रोडक्शन कुंजियों का इस्तेमाल न करें. उनकी सुरक्षा के उपाय ज़रूर किए जाने चाहिए और उन्हें आपके सोर्स ट्री में नहीं रखा जाना चाहिए. |
debug_signing_lineage_file
|
चेतावनी: अपनी प्रोडक्शन कुंजियों का इस्तेमाल न करें. उनकी सुरक्षा के उपाय ज़रूर किए जाने चाहिए और उन्हें आपके सोर्स ट्री में नहीं रखा जाना चाहिए. |
densities
|
|
dex_shards
|
ध्यान दें कि फ़ाइनल ऐप्लिकेशन में हर शार्ड के नतीजे में कम से कम एक dex मिलेगा. इस वजह से, रिलीज़ बाइनरी के लिए इसे 1 से ज़्यादा पर सेट करने का सुझाव नहीं दिया जाता. |
dexopts
|
|
enable_data_binding
|
डेटा बाइंडिंग वाला Android ऐप्लिकेशन बनाने के लिए, आपको ये काम भी करने होंगे:
|
incremental_dexing
|
|
instruments
|
अगर इस एट्रिब्यूट को सेट किया जाता है, तो इस |
javacopts
|
कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं. |
key_rotation_min_sdk
|
|
main_dex_list
|
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
|
multidex एट्रिब्यूट को legacy पर सेट किया गया हो.
|
manifest
|
AndroidManifest.xml .
अगर research_files या एसेट के बारे में जानकारी दी गई है, तो यह बताना ज़रूरी है.
|
manifest_values
|
|
multidex
|
वैल्यू इस तरह की हो सकती हैं:
|
nocompress_extensions
|
|
package_id
|
ज़्यादा जानकारी के लिए, AAPT2 का |
plugins
|
java_plugin
चलाया जाएगा. प्लगिन से जनरेट किए गए रिसॉर्स,
टारगेट के नतीजे वाले जार में शामिल किए जाएंगे.
|
proguard_apply_dictionary
|
|
proguard_apply_mapping
|
proguard_generate_mapping से जनरेट होती है. इसे नए बिल्ड पर उसी मैपिंग को लागू करने के लिए, फिर से इस्तेमाल किया जाता है.
|
proguard_generate_mapping
|
proguard_specs
के बारे में बताया गया हो. इस फ़ाइल में, ओरिजनल और
अस्पष्ट क्लास, तरीके, और फ़ील्ड के नामों के बीच मैपिंग की जानकारी दी जाएगी.
चेतावनी: अगर इस एट्रिब्यूट का इस्तेमाल किया जाता है, तो ProGuard की जानकारी में |
proguard_specs
|
|
resource_configuration_filters
|
en_XA और/या ar_XB स्यूडो-लोकलाइज़ करें.
|
resource_files
|
res डायरेक्ट्री में मौजूद सभी फ़ाइलों का glob होता है.
जनरेट की गई फ़ाइलों (जेनरूल से) का रेफ़रंस यहां लेबल में भी दिया जा सकता है. इस शर्त पर सिर्फ़ यह पाबंदी है कि जनरेट किए गए आउटपुट उसी " res " डायरेक्ट्री में हों, जिसमें शामिल की गई अन्य
रिसॉर्स फ़ाइलें मौजूद हैं.
|
shrink_resources
|
manifest और resource_files एट्रिब्यूट) का इस्तेमाल करने वाले नियमों के लिए काम करता है और इसके लिए ProGuard की ज़रूरत होती है.
यह ज़्यादातर Gradle रिसॉर्स श्रिंकर की तरह ही काम करता है
(https://developer.android.com/studio/build/shrink-code.html#shrink-resources).
अहम अंतर:
name_files/resource_shrinker.log
भी जनरेट होगा. इस डेटा में, विश्लेषण और मिटाए जाने की जानकारी शामिल होगी.
जितनी तरह के साइटमैप हो सकते हैं उनकी जानकारी यहां दी गई है:
|
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
|
.aar फ़ाइल.
|
exports
|
|
srcjar
|
|
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 कंस्ट्रेंट के साथ और
Android टारगेट प्लैटफ़ॉर्म के लिए, cc_library नेटिव लाइब्रेरी
.so रैप करना या बनाना.
|
srcs
|
.java या .srcjar फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए
प्रोसेस किया जाता है.
अगर |
assets
|
assets डायरेक्ट्री में मौजूद सभी फ़ाइलों का glob होता है. आपके पास दूसरे पैकेज में एक्सपोर्ट किए गए या दूसरे नियमों (फ़ाइलें बनाने का नियम) या एक्सपोर्ट की गई फ़ाइलों का रेफ़रंस देने का विकल्प भी है. हालांकि, इसके लिए ज़रूरी है कि वे सभी फ़ाइलें, संबंधित पैकेज में मौजूद assets_dir डायरेक्ट्री में हों.
|
assets_dir
|
assets में मौजूद फ़ाइलों का पाथ देने वाली स्ट्रिंग.
assets और assets_dir , पैकेज की गई एसेट के बारे में जानकारी देते हैं.
साथ ही, दोनों एट्रिब्यूट की वैल्यू दी जानी चाहिए या किसी भी एट्रिब्यूट का इस्तेमाल नहीं किया जाना चाहिए.
|
custom_package
|
|
enable_data_binding
|
डेटा बाइंडिंग वाला Android ऐप्लिकेशन बनाने के लिए, आपको ये काम भी करने होंगे:
|
exported_plugins
|
java_plugin की सूची जो सीधे तौर पर इस लाइब्रेरी पर निर्भर हैं. जैसे, एनोटेशन प्रोसेसर.
|
exports
|
exports एट्रिब्यूट से जिन नियमों तक पहुंचा जा सकता है उन्हें
किसी भी नियम की डिपेंडेंसी माना जाता है, जो सीधे तौर पर exports वाले टारगेट पर निर्भर करता है.
|
exports_manifest
|
android_binary टारगेट में एक्सपोर्ट करना है या नहीं, जो इस टारगेट पर निर्भर है. uses-permissions एट्रिब्यूट कभी एक्सपोर्ट नहीं किए जाते.
|
idl_import_root
|
इस लाइब्रेरी पर निर्भर आईडीएल सोर्स को प्रोसेस करते समय, इस पाथ का इस्तेमाल इंपोर्ट रूट के तौर पर किया जाएगा. अगर उदाहरण देखें. |
idl_parcelables
|
android_library टारगेट के लिए, इंपोर्ट के तौर पर उपलब्ध कराई जाएंगी.
ये फ़ाइलें, सीधे तौर पर या इसके ट्रांज़िटिव क्लोज़र के ज़रिए उपलब्ध होंगी. हालांकि, इनका अनुवाद Java में
या कंपाइल नहीं किया जाएगा.
इस लाइब्रेरी में मौजूद
इन फ़ाइलों को सही तरीके से रखा जाना चाहिए, ताकि एडल कंपाइलर उन्हें ढूंढ सके. इसका मतलब जानने के लिए, idl_Import_root की जानकारी देखें. |
idl_preprocessed
|
android_library टारगेट के लिए, इंपोर्ट के तौर पर उपलब्ध कराई जाएंगी.
ये फ़ाइलें, सीधे तौर पर या इसके ट्रांज़िटिव क्लोज़र के ज़रिए उपलब्ध होंगी. हालांकि, इनका अनुवाद Java में
या कंपाइल नहीं किया जाएगा.
पहले से प्रोसेस की गई सिर्फ़ ऐसी |
idl_srcs
|
srcs के कॉन्टेंट के साथ कंपाइल किया जाएगा.
ये फ़ाइलें, इस लाइब्रेरी पर निर्भर किसी भी
इन फ़ाइलों को सही तरीके से रखा जाना चाहिए, ताकि एडल कंपाइलर उन्हें ढूंढ सके. इसका मतलब जानने के लिए, idl_Import_root की जानकारी देखें. |
javacopts
|
कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं. |
manifest
|
AndroidManifest.xml .
अगर research_files या एसेट के बारे में जानकारी दी गई है, तो यह बताना ज़रूरी है.
|
neverlink
|
neverlink के तौर पर मार्क किए गए नियम के आउटपुट का इस्तेमाल,
.apk बनाने में नहीं किया जाएगा. यह तब काम आता है, जब प्रोग्राम चलाने के दौरान रनटाइम एनवायरमेंट से लाइब्रेरी उपलब्ध कराई जाएगी.
|
plugins
|
java_plugin
चलाया जाएगा. प्लगिन से जनरेट किए गए रिसॉर्स,
टारगेट के नतीजे वाले जार में शामिल किए जाएंगे.
|
proguard_specs
|
android_binary टारगेट में जोड़ दिया जाएगा.
यहां शामिल की गई फ़ाइलों में सिर्फ़ एक आदर्श नियम होना चाहिए, जैसे कि -dontnote, -dontwarn,
गुमाद रखने वाले और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़
android_binary के proGuard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि नॉन-टॉलॉजिकल मर्जिंग हो.
|
resource_files
|
res डायरेक्ट्री में मौजूद सभी फ़ाइलों का glob होता है.
जनरेट की गई फ़ाइलों (जेनरूल से) का रेफ़रंस यहां लेबल में भी दिया जा सकता है. इस शर्त पर सिर्फ़ यह पाबंदी है कि जनरेट किए गए आउटपुट उसी " res " डायरेक्ट्री में हों, जिसमें शामिल की गई अन्य
रिसॉर्स फ़ाइलें मौजूद हैं.
|
android_instrumentation_test
android_instrumentation_test(name, data, args, compatible_with, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, licenses, local, restricted_to, shard_count, size, support_apks, tags, target_compatible_with, target_device, test_app, testonly, timeout, toolchains, visibility)
android_instrumentation_test
नियम के तहत Android इंस्ट्रुमेंटेशन की जांच की जाती है. इससे एम्युलेटर, जांचा जा रहा ऐप्लिकेशन, टेस्ट ऐप्लिकेशन, और
ज़रूरी अन्य ऐप्लिकेशन को इंस्टॉल करेगा. साथ ही, टेस्ट पैकेज में दिए गए टेस्ट करेगा.
test_app एट्रिब्यूट, उस android_binary
के बारे में बताता है जिसमें टेस्ट शामिल है. यह android_binary
अपने इंस्ट्रूमेंट एट्रिब्यूट की मदद से, उस android_binary
ऐप्लिकेशन के बारे में बताता है जिसकी जांच की जा रही है.
उदाहरण
# java/com/samples/hello_world/BUILD android_library( name = "hello_world_lib", srcs = ["Lib.java"], manifest = "LibraryManifest.xml", resource_files = glob(["res/**"]), ) # The app under test android_binary( name = "hello_world_app", manifest = "AndroidManifest.xml", deps = [":hello_world_lib"], )
# javatests/com/samples/hello_world/BUILD android_library( name = "hello_world_test_lib", srcs = ["Tests.java"], deps = [ "//java/com/samples/hello_world:hello_world_lib", ... # test dependencies such as Espresso and Mockito ], ) # The test app android_binary( name = "hello_world_test_app", instruments = "//java/com/samples/hello_world:hello_world_app", manifest = "AndroidManifest.xml", deps = [":hello_world_test_lib"], ) android_instrumentation_test( name = "hello_world_uiinstrumentation_tests", target_device = ":some_target_device", test_app = ":hello_world_test_app", )
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट के लिए एक खास नाम. |
support_apks
|
|
target_device
|
वह android_device जिस पर टेस्ट चलना चाहिए. पहले से चल रहे या किसी फ़िज़िकल डिवाइस पर चल रहे एम्युलेटर पर टेस्ट करने के लिए, इन तर्कों का इस्तेमाल करें:
|
test_app
|
android_binary टारगेट को यह बताना होगा कि वह किस टारगेट की जांच कर रहा है. इसके लिए,
instruments एट्रिब्यूट की मदद लेनी होगी.
|
android_local_test
android_local_test(name, deps, srcs, data, args, compatible_with, custom_package, densities, deprecation, enable_data_binding, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, licenses, local, manifest, manifest_values, nocompress_extensions, plugins, resource_configuration_filters, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, visibility)
यह नियम, स्थानीय तौर पर android_library
नियमों की यूनिट टेस्टिंग के लिए है
(यह किसी डिवाइस पर लागू नहीं होता).
यह Android Robolectric टेस्टिंग फ़्रेमवर्क के साथ काम करता है.
Robolectric टेस्ट लिखने के बारे में ज़्यादा जानकारी के लिए, Android Robolectric साइट देखें.
इंप्लिसिट आउटपुट टारगेट
name.jar
: टेस्ट का Java संग्रह.name-src.jar
: ऐसा संग्रह जिसमें सोर्स ("सोर्स जार") मौजूद हों.name_deploy.jar
: Java डिप्लॉय संग्रह, डिप्लॉयमेंट के लिए सही है (सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर इसका अनुरोध किया गया हो).
उदाहरण
android_local_test
के साथ Robolectric का इस्तेमाल करने के लिए, अपनी WORKSPACE
फ़ाइल में
Robolectric's डेटा संग्रह स्थान जोड़ें:
http_archive( name = "robolectric", urls = ["https://github.com/robolectric/robolectric/archive/<COMMIT>.tar.gz"], strip_prefix = "robolectric-<COMMIT>", sha256 = "<HASH>", ) load("@robolectric//bazel:robolectric.bzl", "robolectric_repositories") robolectric_repositories()इससे Robolectric के लिए ज़रूरी
maven_jar
नियमों को शामिल किया जाता है.
इसके बाद, android_local_test
का हर नियम
@robolectric//bazel:robolectric
पर निर्भर होना चाहिए. नीचे उदाहरण देखें।
android_local_test( name = "SampleTest", srcs = [ "SampleTest.java", ], manifest = "LibManifest.xml", deps = [ ":sample_test_lib", "@robolectric//bazel:robolectric", ], ) android_library( name = "sample_test_lib", srcs = [ "Lib.java", ], resource_files = glob(["res/**"]), manifest = "AndroidManifest.xml", )
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट के लिए एक खास नाम. |
deps
|
|
srcs
|
दूसरी सभी फ़ाइलों को तब तक अनदेखा किया जाता है, जब तक ऊपर बताए गए फ़ाइल टाइप की कम से कम एक फ़ाइल मौजूद हो. ऐसा न होने पर, गड़बड़ी का मैसेज दिखता है.
|
custom_package
|
test_class का भी इस्तेमाल करना पड़ सकता है.
|
densities
|
|
enable_data_binding
|
|
javacopts
|
कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं. |
jvm_flags
|
Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल है (सभी डिपेंडेंट जार को ढूंढने के लिए) और सही Java इंटरप्रेटर को शुरू करती है.
रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम होता है. इसके बाद, ध्यान दें कि इस एट्रिब्यूट का |
manifest
|
AndroidManifest.xml .
अगर research_files या एसेट को परिभाषित किया गया है या टेस्ट की जा रही लाइब्रेरी के किसी मेनिफ़ेस्ट में minSdkVersion टैग है, तो इस बारे में बताना ज़रूरी है.
|
manifest_values
|
applicationId , versionCode , versionName ,
minSdkVersion , targetSdkVersion , और
maxSdkVersion भी, मेनिफ़ेस्ट और
इस्तेमाल-sdk टैग से जुड़े एट्रिब्यूट को बदल देंगे. packageName को अनदेखा कर दिया जाएगा और अगर बताया गया हो, तो इसे
applicationId से या मेनिफ़ेस्ट में पैकेज के तौर पर सेट कर दिया जाएगा.
Manifest_values का इस्तेमाल करने के लिए, नियम में मेनिफ़ेस्ट का होना ज़रूरी नहीं है.
|
nocompress_extensions
|
|
plugins
|
java_plugin को
लागू किया जाएगा. लाइब्रेरी,
exported_plugins का इस्तेमाल करने वाली डिपेंडेंसी से भी प्लगिन इनहेरिट कर सकती है. प्लगिन
से जनरेट किए गए रिसॉर्स,
इस नियम के बनने वाले जार में शामिल किए जाएंगे.
|
resource_configuration_filters
|
|
resource_jars
|
|
resource_strip_prefix
|
अगर बताया गया हो, तो इस पाथ प्रीफ़िक्स को |
runtime_deps
|
deps की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे, लेकिन इनसे अलग, कंपाइल-टाइम क्लासपाथ पर नहीं. सिर्फ़ रनटाइम के दौरान ज़रूरी डिपेंडेंसी यहां दी जानी चाहिए. डिपेंडेंसी-विश्लेषण टूल को runtime_deps और deps , दोनों में दिखने वाले टारगेट को अनदेखा करना चाहिए.
|
stamp
|
स्टैंप वाली बाइनरी को तब तक नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी नहीं बदलतीं. |
test_class
|
यह एट्रिब्यूट, इस टेस्ट से चलाए जाने वाले Java क्लास का नाम बताता है. इसे सेट करने की ज़रूरत बहुत कम होती है. अगर यह तर्क हटा दिया जाता है, तो इस
|
use_launcher
|
अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो
लॉन्चर एट्रिब्यूट और इससे जुड़े
|
android_device
android_device(name, cache, compatible_with, default_properties, deprecation, distribs, exec_compatible_with, exec_properties, features, horizontal_resolution, licenses, platform_apks, ram, restricted_to, screen_density, system_image, tags, target_compatible_with, testonly, vertical_resolution, visibility, vm_heap)
यह नियम ऐसा Android Emulator बनाता है जिसे दी गई खास जानकारी के हिसाब से कॉन्फ़िगर किया गया हो. इस एम्युलेटर को bazel रन कमांड के ज़रिए या सीधे जनरेट की गई स्क्रिप्ट को चलाकर शुरू किया जा सकता है. हमारा सुझाव है कि आप अपना तय करने के बजाय, मौजूदा android_device के नियमों पर निर्भर रहें.
यह नियम --run_under फ़्लैग टू बाज़ल टेस्ट और ब्लेज़ रन के लिए सही टारगेट है. यह एम्युलेटर को शुरू करता है, टेस्ट किए जा रहे/चल रहे टारगेट को एम्युलेटर पर कॉपी करता है, और उसे टेस्ट करता है या ज़रूरत के मुताबिक चलाता है.
android_device
के लिए KVM इमेज बनाने की सुविधा काम करती है. ऐसा तब होता है,
जब system_image की मूल इमेज X86 पर आधारित हो और इसे ज़्यादा से ज़्यादा I686 सीपीयू आर्किटेक्चर के हिसाब से ऑप्टिमाइज़ किया गया हो. केवीएम का इस्तेमाल करने के लिए, android_device
नियम में
tags = ['requires-kvm']
जोड़ें.
इंप्लिसिट आउटपुट टारगेट
name_images/userdata.dat
: एम्युलेटर को शुरू करने के लिए, इसमें इमेज फ़ाइलें और स्नैपशॉट होते हैंname_images/emulator-meta-data.pb
: इसमें सीरियल के हिसाब से जानकारी होती है, जो एम्युलेटर को रीस्टार्ट करने के लिए ज़रूरी होती है.
उदाहरण
यहां दिए गए उदाहरण में, android_device को इस्तेमाल करने का तरीका बताया गया है.
//java/android/helloandroid/BUILD
में शामिल है
android_device( name = "nexus_s", cache = 32, default_properties = "nexus_s.properties", horizontal_resolution = 480, ram = 512, screen_density = 233, system_image = ":emulator_images_android_16_x86", vertical_resolution = 800, vm_heap = 32, ) filegroup( name = "emulator_images_android_16_x86", srcs = glob(["androidsdk/system-images/android-16/**"]), )
//java/android/helloandroid/nexus_s.properties
में शामिल है:
ro.product.brand=google ro.product.device=crespo ro.product.manufacturer=samsung ro.product.model=Nexus S ro.product.name=soju
यह नियम इमेज और शुरुआती स्क्रिप्ट जनरेट करेगा. आपके पास स्थानीय तौर पर एम्युलेटर को चालू करने का विकल्प है. इसके लिए, bazel play :nexus_s -- --action=start. का इस्तेमाल करें. स्क्रिप्ट ये फ़्लैग दिखाती है:
- --adb_port: adb को सार्वजनिक करने के लिए पोर्ट. अगर आपको एम्युलेटर को adb निर्देश देने हैं, तो यह वह पोर्ट है जिससे adb कनेक्ट किया जाएगा.
- --emulator_port: वह पोर्ट, जो एम्युलेटर के टेलनेट मैनेजमेंट कंसोल को चालू करता है.
- --enable_display: सही होने पर एम्युलेटर को डिसप्ले के साथ शुरू करता है (डिफ़ॉल्ट पर गलत पर सेट होता है).
- --action: या तो शुरू करो या बंद करो.
- --apks_to_install: एम्युलेटर पर इंस्टॉल किए जाने वाले apks की सूची.
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट के लिए एक खास नाम. |
cache
|
|
default_properties
|
|
horizontal_resolution
|
|
platform_apks
|
|
ram
|
|
screen_density
|
|
system_image
|
|
vertical_resolution
|
|
vm_heap
|
|
android_ndk_repository
android_ndk_repository(name, api_level, path, repo_mapping)
यह नीति, Bazel को Android एनडीके का इस्तेमाल करने के लिए कॉन्फ़िगर करती है, ताकि नेटिव कोड की मदद से Android टारगेट बनाने में मदद मिल सके.
ध्यान दें कि Android के लिए बिल्डिंग बनाने के लिए भी आपकी WORKSPACE
फ़ाइल में android_sdk_repository
नियम होना ज़रूरी है.
ज़्यादा जानकारी के लिए, Gazel के साथ Android NDK का इस्तेमाल करने के बारे में पूरा दस्तावेज़ पढ़ें.
उदाहरण
android_ndk_repository( name = "androidndk", )
ऊपर दिया गया उदाहरण, $ANDROID_NDK_HOME
से आपके Android NDK की पहचान करेगा. साथ ही, उस एपीआई लेवल
का पता लगाएगा जिस पर यह काम करता है.
android_ndk_repository( name = "androidndk", path = "./android-ndk-r20", api_level = 24, )
ऊपर दिए गए उदाहरण में, ./android-ndk-r20
में आपके फ़ाइल फ़ोल्डर में मौजूद Android एनडीके का इस्तेमाल किया जाएगा. यह आपके जेएनआई कोड को कंपाइल करते समय, एपीआई लेवल 24 की लाइब्रेरी का
इस्तेमाल करेगा.
सीपीयू
Android एनडीके में cpufeatures लाइब्रेरी होती है जिसका इस्तेमाल रनटाइम के दौरान, किसी डिवाइस के सीपीयू की पहचान करने के लिए किया जा सकता है. इस उदाहरण में, Bazel के साथ सीपीयू इस्तेमाल करने का तरीका बताया गया है.
# jni.cc #include "ndk/sources/android/cpufeatures/cpu-features.h" ...
# BUILD cc_library( name = "jni", srcs = ["jni.cc"], deps = ["@androidndk//:cpufeatures"], )
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट के लिए एक खास नाम. |
api_level
|
|
path
|
$ANDROID_NDK_HOME एनवायरमेंट वैरिएबल को सेट करना ज़रूरी है.
Android एनडीके को Android डेवलपर साइट से डाउनलोड किया जा सकता है. |
repo_mapping
|
उदाहरण के लिए, |
android_sdk_repository
android_sdk_repository(name, api_level, build_tools_version, path, repo_mapping)
यह नीति, Bazel को कॉन्फ़िगर करती है, ताकि वह लोकल Android SDK टूल का इस्तेमाल कर सके, ताकि Android टारगेट बनाने में मदद मिल सके.
उदाहरण
Bazel के लिए Android SDK टूल सेट अप करने के लिए, अपनीWORKSPACE
फ़ाइल में "androidsdk" नाम वाला android_sdk_repository
नियम सेट करें. साथ ही, $ANDROID_HOME
एनवायरमेंट वैरिएबल को अपने Android SDK के पाथ पर सेट करें. Bazel, Android SDK में डिफ़ॉल्ट रूप से इंस्टॉल किए गए सबसे अच्छे Android
एपीआई लेवल और बिल्ड टूल वर्शन का इस्तेमाल करेगा.
android_sdk_repository( name = "androidsdk", )
यह पक्का करने के लिए कि फिर से बनाए जा सकने वाले बिल्ड हों, path
, api_level
, और
build_tools_version
एट्रिब्यूट को किसी खास वैल्यू पर सेट किया जा सकता है. अगर Android SDK में, बताया गया एपीआई लेवल या बिल्ड टूल वर्शन इंस्टॉल नहीं किया गया है, तो बिल्ड काम नहीं करेगा.
android_sdk_repository( name = "androidsdk", path = "./sdk", api_level = 19, build_tools_version = "25.0.0", )
ऊपर दिया गया उदाहरण, Android SDK टूल के फ़ाइल फ़ोल्डर-रिलेटिव पाथ का इस्तेमाल करने के बारे में भी बताता है. यह तब फ़ायदेमंद होता है, जब Android SDK आपके Bazel फ़ाइल फ़ोल्डर का हिस्सा हो (उदाहरण के लिए, अगर इसे वर्शन कंट्रोल में चेक किया गया हो).
सपोर्ट लाइब्रेरी
Android SDK Manager में सपोर्ट लाइब्रेरी, "Android सपोर्ट रिपॉज़िटरी" के तौर पर उपलब्ध हैं.
यह सामान्य Android लाइब्रेरी का वर्शन वाला सेट है, जैसे कि Support और AppCompat लाइब्रेरी,
जिसे स्थानीय Maven रिपॉज़िटरी के तौर पर पैकेज किया जाता है. android_sdk_repository
इनमें से हर लाइब्रेरी के लिए, Bazel टारगेट जनरेट करता है. इसे android_binary
और android_library
टारगेट की डिपेंडेंसी में इस्तेमाल किया जा सकता है.
जनरेट किए गए टारगेट के नाम, Android सपोर्ट रिपॉज़िटरी में मौजूद लाइब्रेरी के Maven कोऑर्डिनेट से लिए जाते हैं.
इनका फ़ॉर्मैट @androidsdk//${group}:${artifact}-${version}
होता है.
इस उदाहरण में दिखाया गया है कि android_library
, appcompat लाइब्रेरी के 25.0.0 वर्शन पर कैसे निर्भर हो सकता है.
android_library( name = "lib", srcs = glob(["*.java"]), manifest = "AndroidManifest.xml", resource_files = glob(["res/**"]), deps = ["@androidsdk//com.android.support:appcompat-v7-25.0.0"], )
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट के लिए एक खास नाम. |
api_level
|
किसी बिल्ड के लिए इस्तेमाल किए जाने वाले एपीआई लेवल को
|
build_tools_version
|
Bazel के लिए बिल्ड टूल का 30.0.0 या उसके बाद का वर्शन ज़रूरी है. |
path
|
$ANDROID_HOME एनवायरमेंट वैरिएबल को सेट करना ज़रूरी है.
Android SDK को, Android डेवलपर साइट से डाउनलोड किया जा सकता है. |
repo_mapping
|
उदाहरण के लिए, |