नियम
- android_binary
- aar_Import
- android_library
- android_console_test
- android_local_test
- android_device
- android_ndk_repository
- android_sdk_repository
Android_बाइनरी
android_binary(name, deps, srcs, assets, assets_dir, compatible_with, crunch_png, custom_package, debug_key, debug_signing_keys, debug_signing_lineage_file, densities, deprecation, dex_shards, dexopts, distribs, enable_data_binding, exec_compatible_with, exec_properties, features, incremental_dexing, instruments, javacopts, key_rotation_min_sdk, licenses, main_dex_list, main_dex_list_opts, main_dex_proguard_specs, manifest, manifest_values, multidex, nocompress_extensions, package_id, plugins, proguard_apply_dictionary, proguard_apply_mapping, proguard_generate_mapping, proguard_specs, resource_configuration_filters, resource_files, restricted_to, shrink_resources, tags, target_compatible_with, testonly, visibility)
Android ऐप्लिकेशन पैकेज फ़ाइलें (.apk) बनाता है.
इंप्लिसिट आउटपुट टारगेट
name.apk
: Android ऐप्लिकेशन पैकेज फ़ाइल, डीबग कुंजियों और zipaligned से साइन की गई है. इसका इस्तेमाल, आपके ऐप्लिकेशन को डेवलप करने और डीबग करने के लिए किया जा सकता है. आप डीबग कुंजियों से साइन किए हुए अपने ऐप्लिकेशन को रिलीज़ नहीं कर सकते.name_unsigned.apk
: ऊपर दी गई फ़ाइल का एक ऐसा वर्शन जो साइन नहीं किया गया है और जिसे सार्वजनिक तौर पर रिलीज़ करने से पहले, रिलीज़ कुंजियों पर हस्ताक्षर किया जा सकता है.name_deploy.jar
: एक Java संग्रह, जिसमें इस टारगेट का ट्रांज़िटिव बंद होना होता है.डिप्लॉयमेंट जार में वे सभी क्लास होती हैं जो एक क्लासलोडर से मिलती हैं जिन्होंने इस टारगेट के रनटाइम क्लास पाथ को शुरू से आखिर तक खोजा है.
name_proguard.jar
: एक Java संग्रह, जिसमेंname_deploy.jar
पर ProGuard चलाने का नतीजा शामिल है. यह आउटपुट सिर्फ़ तब बनाया जाता है, जब proGuard_specs एट्रिब्यूट के बारे में बताया गया हो.name_proguard.map
:name_deploy.jar
पर ProGuard चलाने के लिए मैप करने की फ़ाइल का नतीजा. यह आउटपुट सिर्फ़ तब बनाया जाता है, जब proguard_specs एट्रिब्यूट के बारे में बताया गया हो और proguard_Generate_mapping या shrink_resources को सेट किया गया हो.
उदाहरण
Android के नियमों के उदाहरण,
Bazel का सोर्स ट्री
की examples/android
डायरेक्ट्री में मौजूद हैं.
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
deps
|
android_library ,
java_library में android की सीमा है, और
cc_library टारगेट की गई लाइब्रेरी के लिए, 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
|
ध्यान दें कि फ़ाइनल ऐप्लिकेशन में हर शार्ड का कम से कम एक डेक्स होगा. इस वजह से, इसे बाइनरी से ज़्यादा पर सेट करने का सुझाव नहीं दिया जाता है. |
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 .
अगर रिसॉर्स_फ़ाइल या एसेट तय किए जाते हैं, तो इसकी जानकारी देना ज़रूरी है.
|
manifest_values
|
|
multidex
|
ये वैल्यू हो सकती हैं:
|
nocompress_extensions
|
|
package_id
|
ज़्यादा जानकारी के लिए, AAPT2's के |
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_लाइब्रेरी
android_library(name, deps, srcs, data, assets, assets_dir, compatible_with, custom_package, deprecation, distribs, enable_data_binding, exec_compatible_with, exec_properties, exported_plugins, exports, exports_manifest, features, idl_import_root, idl_parcelables, idl_preprocessed, idl_srcs, javacopts, licenses, manifest, neverlink, plugins, proguard_specs, resource_files, restricted_to, tags, target_compatible_with, testonly, visibility)
यह नियम अपने स्रोतों को कंपाइल करता है और उन्हें एक .jar
फ़ाइल में संग्रहित करता है.
Android रनटाइम लाइब्रेरी android.jar
को, कंपाइल होने वाले क्लास में शामिल कर दिया गया है.
इंप्लिसिट आउटपुट टारगेट
libname.jar
: Java संग्रह.libname-src.jar
: संग्रह वाला स्रोत ("source Jar").name.aar
: एक Android और #39;aar' बंडल, जिसमें java संग्रह और इस टारगेट के संसाधन शामिल हैं. इसमें ट्रांज़िटिव बंद होने की जानकारी शामिल नहीं है.
उदाहरण
Android के नियमों के उदाहरण,
Bazel का सोर्स ट्री
की examples/android
डायरेक्ट्री में मौजूद हैं.
इस उदाहरण में, idl_import_root
को सेट करने का तरीका बताया गया है.
//java/bazel/helloandroid/BUILD
में शामिल करें:
android_library( name = "parcelable", srcs = ["MyParcelable.java"], # bazel.helloandroid.MyParcelable # MyParcelable.aidl will be used as import for other .aidl # files that depend on it, but will not be compiled. idl_parcelables = ["MyParcelable.aidl"] # bazel.helloandroid.MyParcelable # We don't need to specify idl_import_root since the aidl file # which declares bazel.helloandroid.MyParcelable # is present at java/bazel/helloandroid/MyParcelable.aidl # underneath a java root (java/). ) android_library( name = "foreign_parcelable", srcs = ["src/android/helloandroid/OtherParcelable.java"], # android.helloandroid.OtherParcelable idl_parcelables = [ "src/android/helloandroid/OtherParcelable.aidl" # android.helloandroid.OtherParcelable ], # We need to specify idl_import_root because the aidl file which # declares android.helloandroid.OtherParcelable is not positioned # at android/helloandroid/OtherParcelable.aidl under a normal java root. # Setting idl_import_root to "src" in //java/bazel/helloandroid # adds java/bazel/helloandroid/src to the list of roots # the aidl compiler will search for imported types. idl_import_root = "src", ) # Here, OtherInterface.aidl has an "import android.helloandroid.CallbackInterface;" statement. android_library( name = "foreign_interface", idl_srcs = [ "src/android/helloandroid/OtherInterface.aidl" # android.helloandroid.OtherInterface "src/android/helloandroid/CallbackInterface.aidl" # android.helloandroid.CallbackInterface ], # As above, idl_srcs which are not correctly positioned under a java root # must have idl_import_root set. Otherwise, OtherInterface (or any other # interface in a library which depends on this one) will not be able # to find CallbackInterface when it is imported. idl_import_root = "src", ) # MyParcelable.aidl is imported by MyInterface.aidl, so the generated # MyInterface.java requires MyParcelable.class at compile time. # Depending on :parcelable ensures that aidl compilation of MyInterface.aidl # specifies the correct import roots and can access MyParcelable.aidl, and # makes MyParcelable.class available to Java compilation of MyInterface.java # as usual. android_library( name = "idl", idl_srcs = ["MyInterface.aidl"], deps = [":parcelable"], ) # Here, ServiceParcelable uses and thus depends on ParcelableService, # when it's compiled, but ParcelableService also uses ServiceParcelable, # which creates a circular dependency. # As a result, these files must be compiled together, in the same android_library. android_library( name = "circular_dependencies", srcs = ["ServiceParcelable.java"], idl_srcs = ["ParcelableService.aidl"], idl_parcelables = ["ServiceParcelable.aidl"], )
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
deps
|
android_library ,
java_library में android कंस्ट्रेंट और
cc_library टारगेट किया जाता है. साथ ही, Android टारगेट प्लैटफ़ॉर्म के लिए .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 .
अगर रिसॉर्स_फ़ाइल या एसेट तय किए जाते हैं, तो इसकी जानकारी देना ज़रूरी है.
|
neverlink
|
neverlink के तौर पर मार्क किए गए नियम के आउटपुट का इस्तेमाल, .apk बनाने में नहीं किया जाएगा. अगर लाइब्रेरी एक्ज़ीक्यूशन के दौरान रनटाइम एनवायरमेंट से मिलेगी, तो यह मददगार होता है.
|
plugins
|
java_plugin चलाया जाएगा. प्लग इन से जनरेट हुए रिसॉर्स को
टारगेट के नतीजे के जार में शामिल
किया जाएगा.
|
proguard_specs
|
android_binary टारगेट में जोड़ा जाएगा.
यहां शामिल की गई फ़ाइलों में सिर्फ़ नियम लागू होने चाहिए. इन नियमों के नाम -dontnote, -dontvarn,
benonosides, और -keep से शुरू होने वाले नियम होने चाहिए. दूसरे विकल्प, सिर्फ़
android_binary 'sGuard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि वे गैर-ऑटोलॉजिकल मर्ज में शामिल न हों.
|
resource_files
|
res डायरेक्ट्री में मौजूद सभी फ़ाइलों का glob होता है.
जनरेट की गई फ़ाइलों (जेनरल से) का रेफ़रंस यहां लेबल से भी लिया जा सकता है. एकमात्र पाबंदी यह है कि जनरेट किए गए आउटपुट उसी कोट & res ;कोटेशन के तहत होने चाहिए जो अन्य रिसॉर्स फ़ाइलों में शामिल हैं.
|
Android_testation_test
android_instrumentation_test(name, data, args, compatible_with, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, licenses, local, restricted_to, shard_count, size, support_apks, tags, target_compatible_with, target_device, test_app, testonly, timeout, toolchains, visibility)
एक android_instrumentation_test
नियम Android इंस्ट्रूमेंटेशन परीक्षण चलाता है. यह एक एम्युलेटर शुरू करेगा, टेस्ट किए जा रहे ऐप्लिकेशन को इंस्टॉल करेगा, टेस्ट ऐप्लिकेशन, और किसी भी दूसरे ज़रूरी ऐप्लिकेशन को इंस्टॉल करेगा और टेस्ट पैकेज में बताए गए टेस्ट चलाएगा.
test_app एट्रिब्यूट में उस android_binary
के बारे में बताया जाता है जिसमें टेस्ट होता है. यह android_binary
, इसके बदले में अपने प्लैटफ़ॉर्म एट्रिब्यूट का इस्तेमाल करके, android_binary
ऐप्लिकेशन की जांच करता है.
उदाहरण
# java/com/samples/hello_world/BUILD android_library( name = "hello_world_lib", srcs = ["Lib.java"], manifest = "LibraryManifest.xml", resource_files = glob(["res/**"]), ) # The app under test android_binary( name = "hello_world_app", manifest = "AndroidManifest.xml", deps = [":hello_world_lib"], )
# javatests/com/samples/hello_world/BUILD android_library( name = "hello_world_test_lib", srcs = ["Tests.java"], deps = [ "//java/com/samples/hello_world:hello_world_lib", ... # test dependencies such as Espresso and Mockito ], ) # The test app android_binary( name = "hello_world_test_app", instruments = "//java/com/samples/hello_world:hello_world_app", manifest = "AndroidManifest.xml", deps = [":hello_world_test_lib"], ) android_instrumentation_test( name = "hello_world_uiinstrumentation_tests", target_device = ":some_target_device", test_app = ":hello_world_test_app", )
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
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 Robolectic टेस्टिंग फ़्रेमवर्क के साथ काम करता है.
रोबोलेट्रिक टेस्ट लिखने के बारे में ज़्यादा जानने के लिए, Android Robolectic साइट देखें.
इंप्लिसिट आउटपुट टारगेट
name.jar
: टेस्ट का Java संग्रह.name-src.jar
: संग्रह वाला स्रोत ("source Jar").name_deploy.jar
: Java डिप्लॉयमेंट संग्रह, जो डिप्लॉयमेंट के लिए सही है (सिर्फ़ तब ही बनाया जा सकता है, जब साफ़ तौर पर अनुरोध किया गया हो).
उदाहरण
android_local_test
के लिए Robolectract का इस्तेमाल करने के लिए, अपनी WORKSPACE
फ़ाइल में
Robolecric's.repository जोड़ें:
http_archive( name = "robolectric", urls = ["https://github.com/robolectric/robolectric/archive/<COMMIT>.tar.gz"], strip_prefix = "robolectric-<COMMIT>", sha256 = "<HASH>", ) load("@robolectric//bazel:robolectric.bzl", "robolectric_repositories") robolectric_repositories()इससे, Robolectic के लिए ज़रूरी
maven_jar
नियम लागू हो जाते हैं.
इसके बाद, हर android_local_test
नियम @robolectric//bazel:robolectric
पर निर्भर होना चाहिए. नीचे उदाहरण देखें।
android_local_test( name = "SampleTest", srcs = [ "SampleTest.java", ], manifest = "LibManifest.xml", deps = [ ":sample_test_lib", "@robolectric//bazel:robolectric", ], ) android_library( name = "sample_test_lib", srcs = [ "Lib.java", ], resource_files = glob(["res/**"]), manifest = "AndroidManifest.xml", )
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
deps
|
|
srcs
|
बाकी सभी फ़ाइलों को अनदेखा किया जाता है. हालांकि, ऊपर बताई गई फ़ाइल टाइप में से कम से कम एक फ़ाइल का होना ज़रूरी है. ऐसा न करने पर, गड़बड़ी की सूचना मिलती है.
अगर |
custom_package
|
test_class का भी इस्तेमाल करना पड़ सकता है.
|
densities
|
|
enable_data_binding
|
|
javacopts
|
ग्लोबल कंपाइलर विकल्पों के बाद, इन कंपाइलर विकल्पों को javac को पास किया जाता है. |
jvm_flags
|
Java बाइनरी की रैपर स्क्रिप्ट में क्लासपाथ की परिभाषा
(सभी निर्भर जार ढूंढने के लिए) शामिल होती है और सही Java इंटरप्रेटर को शुरू किया जाता है.
रैपर स्क्रिप्ट से जनरेट की जाने वाली कमांड लाइन में मुख्य क्लास का नाम और फिर ध्यान दें कि इस एट्रिब्यूट का |
manifest
|
AndroidManifest.xml .
अगर संसाधन_फ़ाइलें या एसेट के बारे में बताया गया है या जांच में शामिल लाइब्रेरी के किसी भी मेनिफ़ेस्ट में minSdkVersion टैग है, तो यह तय किया जाना चाहिए.
|
manifest_values
|
applicationId , versionCode , versionName , minSdkVersion , targetSdkVersion , और maxSdkVersion , मेनिफ़ेस्ट के एट्रिब्यूट को भी बदल देंगे. साथ ही, यह sdk टैग का इस्तेमाल भी करेगा. packageName को नज़रअंदाज़ कर दिया जाएगा. अगर मेनिफ़ेस्ट में पैकेज
या पैकेज की जानकारी दी गई है, तो इसे
applicationId से सेट किया जाएगा.
मेनिफ़ेस्ट का इस्तेमाल करने के लिए, नियम में मेनिफ़ेस्ट लागू करना ज़रूरी नहीं है.
|
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 क्लास का नाम बताता है. इसे सेट करना कम ही होता है. अगर यह आर्ग्युमेंट हटाया जाता है, तो उस Java क्लास का इस्तेमाल किया जाएगा जिसका नाम इस |
use_launcher
|
अगर यह एट्रिब्यूट 'गलत है' पर सेट किया गया है, तो इस टारगेट के लिए,
लॉन्चर एट्रिब्यूट और इससे जुड़े
|
Android डिवाइस
android_device(name, cache, compatible_with, default_properties, deprecation, distribs, exec_compatible_with, exec_properties, features, horizontal_resolution, licenses, platform_apks, ram, restricted_to, screen_density, system_image, tags, target_compatible_with, testonly, vertical_resolution, visibility, vm_heap)
यह नियम दिए गए निर्देशों के साथ कॉन्फ़िगर किया गया Android एम्युलेटर बनाता है. यह एम्युलेटर बेज़ल रन कमांड की मदद से या जनरेट की गई स्क्रिप्ट को सीधे लागू करके शुरू किया जा सकता है. हमारा सुझाव है कि आप अपना Android डिवाइस तय करने के बजाय, मौजूदा android_device के नियमों पर निर्भर रहें.
बेज़ल टेस्ट और ब्लेज़ रन के लिए, यह नियम --run_under फ़्लैग के लिए सही टारगेट है. यह एक एम्युलेटर शुरू करता है, टेस्ट किए जा रहे टारगेट/एम्युलेटर को चलाता है. साथ ही, इसकी जांच करता है या ज़रूरत के मुताबिक इसे चलाता है.
अगर बुनियादी system_image X86 पर आधारित है और इसे ज़्यादा से ज़्यादा I686 सीपीयू आर्किटेक्चर के लिए ऑप्टिमाइज़ किया गया है, तो android_device
केएमवी इमेज बनाने में मदद कर सकता है. केवीएम का इस्तेमाल करने के लिए,
android_device
नियम में tags = ['requires-kvm']
जोड़ें.
इंप्लिसिट आउटपुट टारगेट
name_images/userdata.dat
: एम्युलेटर शुरू करने के लिए, इमेज फ़ाइलें और स्नैपशॉट शामिल होंname_images/emulator-meta-data.pb
: इसमें ऐसी सीरियल जानकारी होती है जो एम्युलेटर को पास करने के लिए, उसे फिर से शुरू करना ज़रूरी होता है.
उदाहरण
नीचे दिए गए उदाहरण में android_device को इस्तेमाल करने का तरीका बताया गया है.
//java/android/helloandroid/BUILD
में शामिल है
android_device( name = "nexus_s", cache = 32, default_properties = "nexus_s.properties", horizontal_resolution = 480, ram = 512, screen_density = 233, system_image = ":emulator_images_android_16_x86", vertical_resolution = 800, vm_heap = 32, ) filegroup( name = "emulator_images_android_16_x86", srcs = glob(["androidsdk/system-images/android-16/**"]), )
//java/android/helloandroid/nexus_s.properties
में ये शामिल हैं:
ro.product.brand=google ro.product.device=crespo ro.product.manufacturer=samsung ro.product.model=Nexus S ro.product.name=soju
इस नियम से इमेज जनरेट होंगी और एक स्क्रिप्ट शुरू होगी. आप बेज़ल रन :nexus_s -- --action=start में जाकर, एम्युलेटर को स्थानीय तौर पर शुरू कर सकते हैं. स्क्रिप्ट में ये फ़्लैग दिखते हैं:
- --adb_port: adb को सार्वजनिक करने के लिए पोर्ट. अगर आप एम्युलेटर को adb निर्देश जारी करना चाहते हैं, तो यह वह पोर्ट है जिस पर आप adb कनेक्ट जारी करेंगे.
- --emulator_port: एम्युलेटर का टेलीनेट प्रबंधन कंसोल चालू करने वाला पोर्ट.
- --enable_display: सही होने पर डिसप्ले के साथ एम्युलेटर शुरू करता है (डिफ़ॉल्ट तौर पर 'गलत').
- --कार्रवाई: या तो शुरू करें या बंद करें.
- --apks_to_ install: एम्युलेटर पर इंस्टॉल करने के लिए apk की सूची.
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
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)
बेज़ल को Android कोड NDK का इस्तेमाल करके कॉन्फ़िगर करता है, ताकि नेटिव कोड के साथ Android टारगेट बनाने में मदद मिल सके.
ध्यान रखें कि Android के लिए भवन बनाने के लिए आपकी WORKSPACE
फ़ाइल में android_sdk_repository
नियम की भी ज़रूरत होती है.
ज़्यादा जानकारी के लिए, Bzel के साथ Android NDK का इस्तेमाल करने के बारे में पूरा दस्तावेज़ पढ़ें.
उदाहरण
android_ndk_repository( name = "androidndk", )
ऊपर दिया गया उदाहरण $ANDROID_NDK_HOME
से आपके Android NDK का पता लगाएगा और इसके साथ काम करने वाले
सबसे ऊंचे एपीआई लेवल का पता लगाएगा.
android_ndk_repository( name = "androidndk", path = "./android-ndk-r20", api_level = 24, )
ऊपर दिया गया उदाहरण, ./android-ndk-r20
में आपके फ़ाइल फ़ोल्डर के अंदर मौजूद Android NDK का इस्तेमाल करेगा. यह आपका जेएनआई कोड कंपाइल करते समय, एपीआई लेवल 24 लाइब्रेरी का इस्तेमाल करेगा.
cpufeatures
Android NDK में cpufeatures लाइब्रेरी है, जिसका इस्तेमाल रनटाइम के दौरान डिवाइस के सीपीयू की पहचान करने के लिए किया जा सकता है. नीचे दिए गए उदाहरण में Bazel की सीपीयू सुविधाओं का इस्तेमाल करने का तरीका बताया गया है.
# jni.cc #include "ndk/sources/android/cpufeatures/cpu-features.h" ...
# BUILD cc_library( name = "jni", srcs = ["jni.cc"], deps = ["@androidndk//:cpufeatures"], )
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
api_level
|
|
path
|
$ANDROID_NDK_HOME एनवायरमेंट वैरिएबल सेट करना ज़रूरी है.
Android NDK, Android डेवलपर साइट से डाउनलोड किया जा सकता है. |
repo_mapping
|
उदाहरण के लिए, किसी एंट्री के बारे में यह बताया गया है कि किसी भी समय,
|
android_sdk_repository
android_sdk_repository(name, api_level, build_tools_version, path, repo_mapping)
Android टारगेट बनाने के लिए, बेज़ल को किसी स्थानीय Android SDK टूल का इस्तेमाल करने के लिए कॉन्फ़िगर करता है.
उदाहरण
बेज़ेल के लिए Android का SDK टूल सेट अप करने का सबसे कम तरीका है कि अपनीWORKSPACE
फ़ाइल में android_sdk_repository
नियम का नाम रखें "androidsdk" और $ANDROID_HOME
Android एनवायरमेंट पाथ की वैल्यू को अपने Android SDK टूल के पाथ पर सेट करें. Bazel, Android के सबसे अच्छे एपीआई लेवल का इस्तेमाल करेगा
और डिफ़ॉल्ट रूप से, Android SDK में इंस्टॉल किए गए टूल का वर्शन बनाएगा.
android_sdk_repository( name = "androidsdk", )
फिर से बनाए जा सकने वाले बिल्ड को पक्का करने के लिए, path
, api_level
औरbuild_tools_version
एट्रिब्यूट को खास वैल्यू पर सेट किया जा सकता है. अगर Android SDK में तय किया गया एपीआई लेवल नहीं है या बिल्ड टूल का वर्शन इंस्टॉल नहीं किया गया है, तो हो सकता है कि यह वर्शन काम न करे.
android_sdk_repository( name = "androidsdk", path = "./sdk", api_level = 19, build_tools_version = "25.0.0", )
ऊपर दिया गया उदाहरण, Android SDK के लिए फ़ाइल टाइप-रिलेटिव पाथ का इस्तेमाल करने के बारे में भी बताता है. अगर Android SDK आपके Bazel फ़ाइल फ़ोल्डर का हिस्सा है, तो इसका इस्तेमाल किया जा सकता है. उदाहरण के लिए, अगर SDK टूल के वर्शन कंट्रोल में इसका इस्तेमाल किया जाता है.
लाइब्रेरी की मदद करें
सहायता लाइब्रेरी, Android SDK Manager में "Android सहायता डेटा स्टोर करने की जगह" के तौर पर उपलब्ध हैं.
यह सामान्य Android लाइब्रेरी का वर्शन वाला सेट है, जैसे कि Support और AppCompat लाइब्रेरी.
इसे लोकल मेवन रिपॉज़िटरी के तौर पर पैकेज किया जाता है. android_sdk_repository
इन सभी लाइब्रेरी के लिए बेज़ल टारगेट जनरेट करता है. इनका इस्तेमाल android_binary
और android_library
टारगेट की निर्भरता में किया जा सकता है.
जनरेट किए गए टारगेट के नाम, Android सपोर्ट रिपॉज़िटरी में लाइब्रेरी के Maven निर्देशांकों से लिए जाते हैं. इन्हें @androidsdk//${group}:${artifact}-${version}
के तौर पर फ़ॉर्मैट किया जाता है.
नीचे दिए गए उदाहरण में बताया गया है कि android_library
, वर्शन सात वर्शन वाली Appcompat लाइब्रेरी के 25.0.0 वर्शन के हिसाब से कैसे काम कर सकता है.
android_library( name = "lib", srcs = glob(["*.java"]), manifest = "AndroidManifest.xml", resource_files = glob(["res/**"]), deps = ["@androidsdk//com.android.support:appcompat-v7-25.0.0"], )
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
api_level
|
दिए गए बिल्ड के लिए इस्तेमाल किया गया एपीआई लेवल,
|
build_tools_version
|
Bazel को 30.0.0 या इसके बाद के वर्शन पर बिल्ड टूल का इस्तेमाल करना होगा. |
path
|
$ANDROID_HOME एनवायरमेंट वैरिएबल सेट करना ज़रूरी है.
Android SDK टूल, Android डेवलपर साइट से डाउनलोड किया जा सकता है. |
repo_mapping
|
उदाहरण के लिए, किसी एंट्री के बारे में यह बताया गया है कि किसी भी समय,
|