Reglas
- 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)
Produce archivos de paquetes de aplicaciones para Android (.apk).
Objetivos de salida implícitos
name.apk
: Es un archivo de paquete de aplicación para Android firmado con claves de depuración y zipalign que podría usarse para desarrollar y depurar tu aplicación. No puedes lanzar tu aplicación cuando está firmada con las claves de depuración.name_unsigned.apk
: Es una versión sin firmar del archivo anterior que se podía firmar con las claves de lanzamiento antes del lanzamiento público.name_deploy.jar
: Es un archivo Java que contiene el cierre transitivo de este destino.El archivo jar de implementación contiene todas las clases que encontraría un cargador de clases que buscó la ruta de clase de tiempo de ejecución de este destino de principio a fin.
name_proguard.jar
: Es un archivo Java que contiene el resultado de la ejecución de ProGuard enname_deploy.jar
. Este resultado solo se produce si se especifica el atributo proguard_specs.name_proguard.map
: Es el resultado de un archivo de asignación de la ejecución de ProGuard enname_deploy.jar
. Este resultado solo se produce si se especifica el atributo proguard_specs y se configuran proguard_generate_mapping o shrink_resources.
Ejemplos
Puedes encontrar ejemplos de reglas de Android en el directorio examples/android
del árbol de fuentes de Bazel.
Argumentos
Atributos | |
---|---|
name |
Un nombre único para este destino. |
deps
|
android_library , java_library con la restricción android y la unión de cc_library o la producción de bibliotecas nativas .so para la plataforma de destino de Android.
|
srcs
|
Se compilan los archivos Se descomprimen y compilan los archivos |
assets
|
glob de todos los archivos del directorio assets . También puedes hacer referencia a otras reglas (cualquier regla que genere archivos) o a archivos exportados en los otros paquetes, siempre que todos esos archivos estén en el directorio assets_dir del paquete correspondiente.
|
assets_dir
|
assets .
El par assets y assets_dir describen los elementos empaquetados. Se deben proporcionar ambos atributos o ninguno.
|
crunch_png
|
|
custom_package
|
|
debug_key
|
ADVERTENCIA: No uses tus claves de producción. Debes protegerlas estrictamente y no debes guardarlas en el árbol fuente. |
debug_signing_keys
|
ADVERTENCIA: No uses tus claves de producción. Debes protegerlas estrictamente y no debes guardarlas en el árbol fuente. |
debug_signing_lineage_file
|
ADVERTENCIA: No uses tus claves de producción. Debes protegerlas estrictamente y no debes guardarlas en el árbol fuente. |
densities
|
|
dex_shards
|
Ten en cuenta que cada fragmento generará al menos un archivo DEX en la app final. Por este motivo, no se recomienda establecerlo en más de 1 para los objetos binarios de lanzamiento. |
dexopts
|
|
enable_data_binding
|
Si deseas compilar una app para Android con vinculación de datos, también debes hacer lo siguiente:
|
incremental_dexing
|
|
instruments
|
El objetivo Si se configura este atributo, este |
javacopts
|
Estas opciones del compilador se pasan a javac después de las opciones globales del compilador. |
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.classSe debe usar con multidex="manual_main_dex" .
|
main_dex_list_opts
|
|
main_dex_proguard_specs
|
multidex está configurado como legacy .
|
manifest
|
AndroidManifest.xml .
Debe definirse si se definen archivos o recursos resource_files o los elementos.
|
manifest_values
|
|
multidex
|
Valores posibles:
|
nocompress_extensions
|
|
package_id
|
Para obtener más información, consulta el argumento |
plugins
|
java_plugin especificado en el atributo de complementos se ejecutará cada vez que se compile este destino. Los recursos que genera el complemento se incluirán en el archivo jar de resultados del destino.
|
proguard_apply_dictionary
|
|
proguard_apply_mapping
|
proguard_generate_mapping para que se vuelva a usar a fin de aplicar la misma asignación a una compilación nueva.
|
proguard_generate_mapping
|
proguard_specs . En este archivo, se mostrará la asignación entre los nombres de las clases, del método y de los campos originales y ofuscados.
ADVERTENCIA: Si se usa este atributo, la especificación de ProGuard no debería contener |
proguard_specs
|
|
resource_configuration_filters
|
en_XA o ar_XB .
|
resource_files
|
glob de todos los archivos del directorio res .
Aquí también se puede hacer referencia a los archivos generados (desde genrules) mediante Etiqueta. La única restricción es que los resultados generados deben estar en el mismo directorio " res " que cualquier otro archivo de recursos incluido.
|
shrink_resources
|
manifest y resource_files ) y requiere ProGuard.
Funciona casi de la misma manera que el reductor de recursos de Gradle (https://developer.android.com/studio/build/shrink-code.html#shrink-resources).
Diferencias destacadas:
name_files/resource_shrinker.log , que detalla el análisis y las eliminaciones realizadas.
Valores posibles:
|
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)
Esta regla permite el uso de archivos .aar
como bibliotecas para las reglas android_library
y android_binary
.
Ejemplos
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"], )
Argumentos
Atributos | |
---|---|
name |
Un nombre único para este destino. |
aar
|
.aar que se proporciona a los destinos de Android que dependen de él.
|
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)
Esta regla compila y archiva sus fuentes en un archivo .jar
.
La biblioteca android.jar
del tiempo de ejecución de Android se coloca implícitamente en la ruta de acceso de la clase de compilación.
Objetivos de salida implícitos
libname.jar
: Es un archivo Java.libname-src.jar
: Es un archivo que contiene las fuentes ("jar de origen").name.aar
: Es un paquete "aar" de Android que contiene el archivo Java y los recursos de este destino. No contiene el cierre transitivo.
Ejemplos
Puedes encontrar ejemplos de reglas de Android en el directorio examples/android
del árbol de fuentes de Bazel.
En el siguiente ejemplo, se muestra cómo configurar idl_import_root
.
Deja que //java/bazel/helloandroid/BUILD
contenga lo siguiente:
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"], )
Argumentos
Atributos | |
---|---|
name |
Un nombre único para este destino. |
deps
|
android_library , java_library con la restricción android y la unión de cc_library o la producción de bibliotecas nativas .so para la plataforma de destino de Android.
|
srcs
|
.java o .srcjar que se procesan para crear el destino.
Se compilan los archivos Se descomprimen y compilan los archivos Si se omite |
assets
|
glob de todos los archivos del directorio assets . También puedes hacer referencia a otras reglas (cualquier regla que genere archivos) o a archivos exportados en los otros paquetes, siempre que todos esos archivos estén en el directorio assets_dir del paquete correspondiente.
|
assets_dir
|
assets .
El par assets y assets_dir describen los elementos empaquetados. Se deben proporcionar ambos atributos o ninguno.
|
custom_package
|
|
enable_data_binding
|
Si deseas compilar una app para Android con vinculación de datos, también debes hacer lo siguiente:
|
exported_plugins
|
java_plugin (p.ej., procesadores de anotaciones) para exportar a bibliotecas que dependen directamente de esta biblioteca.
La lista especificada de |
exports
|
exports se considera dependencias directas de cualquier regla que dependa directamente del destino con exports .
Los |
exports_manifest
|
android_binary
que dependen de este destino. Los atributos uses-permissions nunca se exportan.
|
idl_import_root
|
Esta ruta se usará como la raíz de importación cuando se procesen fuentes inactivas que dependan de esta biblioteca. Cuando se especifica Consulta los ejemplos. |
idl_parcelables
|
android_library que dependa de esta biblioteca, directamente o a través de su cierre transitivo, pero no se traducirán a Java ni se compilarán.
Solo se deben incluir los archivos Estos archivos deben ubicarse de manera correcta para que el compilador Aidl los encuentre. Consulta la descripción de idl_import_root para obtener información sobre lo que esto significa. |
idl_preprocessed
|
android_library que dependa de esta biblioteca, directamente o a través de su cierre transitivo, pero no se traducirán a Java ni se compilarán.
Solo se deben incluir los archivos |
idl_srcs
|
srcs .
Estos archivos estarán disponibles como importaciones para cualquier destino Estos archivos deben ubicarse de manera correcta para que el compilador Aidl los encuentre. Consulta la descripción de idl_import_root para obtener información sobre lo que esto significa. |
javacopts
|
Estas opciones del compilador se pasan a javac después de las opciones globales del compilador. |
manifest
|
AndroidManifest.xml .
Debe definirse si se definen archivos o recursos resource_files o los elementos.
|
neverlink
|
neverlink no se usarán en la creación de .apk . Es útil si el entorno de ejecución proporciona la biblioteca durante la ejecución.
|
plugins
|
java_plugin especificado en el atributo de complementos se ejecutará cada vez que se compile este destino. Los recursos que genera el complemento se incluirán en el archivo jar de resultados del destino.
|
proguard_specs
|
android_binary según esta biblioteca.
Los archivos que se incluyen aquí solo deben tener reglas idempotentes, es decir, -dontnote, -dontwarn, asunción de efectos secundarios y reglas que comienzan con -keep. Otras opciones solo pueden aparecer en proguard_specs de android_binary para garantizar combinaciones no tautológicas.
|
resource_files
|
glob de todos los archivos del directorio res .
Aquí también se puede hacer referencia a los archivos generados (desde genrules) mediante Etiqueta. La única restricción es que los resultados generados deben estar en el mismo directorio " res " que cualquier otro archivo de recursos incluido.
|
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)
Una regla android_instrumentation_test
ejecuta pruebas de instrumentación de Android. Este iniciará un emulador, instalará la aplicación que se está probando, la aplicación de prueba y cualquier otra aplicación necesaria, y ejecutará las pruebas definidas en el paquete de pruebas.
El atributo test_app especifica el android_binary
que contiene la prueba. Este android_binary
, a su vez, especifica la aplicación android_binary
que se está probando a través del atributo instruments.
Ejemplo
# 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", )
Argumentos
Atributos | |
---|---|
name |
Un nombre único para este destino. |
support_apks
|
|
target_device
|
El android_device en el que se debe ejecutar la prueba Para ejecutar la prueba en un emulador que ya se está ejecutando o en un dispositivo físico, usa
estos argumentos:
|
test_app
|
android_binary debe especificar qué objetivo se está probando a través del atributo 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)
Esta regla sirve para probar las reglas android_library
de forma local (en lugar de hacerlo en un dispositivo).
Funciona con el framework de prueba de Android Robolectric.
Consulta el sitio de Android Robolectric para obtener detalles sobre cómo escribir pruebas de Robolectric.
Objetivos de salida implícitos
name.jar
: Es un archivo Java de la prueba.name-src.jar
: Es un archivo que contiene las fuentes ("jar fuente").name_deploy.jar
: Es un archivo de implementación de Java adecuado para la implementación (solo se compila si se solicita de forma explícita).
Ejemplos
Para usar Robolectric con android_local_test
, agrega el repositorio de Robolectric a tu archivo WORKSPACE
:
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(). De esta manera, se extraen las reglas
maven_jar
necesarias para Robolectric.
Luego, cada regla android_local_test
debe depender de @robolectric//bazel:robolectric
. Consulta el siguiente ejemplo.
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", )
Argumentos
Atributos | |
---|---|
name |
Un nombre único para este destino. |
deps
|
La lista de reglas permitidas en |
srcs
|
Se compilan los archivos Se descomprimen y compilan los archivos Se ignorarán todos los demás archivos, siempre que haya al menos un archivo de un tipo de archivo descrito anteriormente. De lo contrario, se genera un error.
El atributo |
custom_package
|
test_class .
|
densities
|
|
enable_data_binding
|
|
javacopts
|
Estas opciones del compilador se pasan a javac después de las opciones globales del compilador. |
jvm_flags
|
La secuencia de comandos del wrapper para un objeto binario Java incluye una definición CLASSPATH (para encontrar todos los archivos jar dependientes) y, luego, invoca el intérprete de Java correcto.
La línea de comandos que genera la secuencia de comandos del wrapper incluye el nombre de la clase principal seguido de un Ten en cuenta que este atributo no tiene efecto en los resultados de |
manifest
|
AndroidManifest.xml .
Debe definirse si se definen los recursos o archivos_resource, o si alguno de los manifiestos de las bibliotecas evaluadas tiene una etiqueta minSdkVersion .
|
manifest_values
|
applicationId , versionCode , versionName , minSdkVersion , targetSdkVersion y maxSdkVersion también anularán los atributos correspondientes del manifiesto y las etiquetas uses-sdk. Se ignorará packageName y se establecerá desde applicationId si se especifica o desde el paquete en el manifiesto.
No es necesario tener un manifiesto en la regla para usar manifest_values.
|
nocompress_extensions
|
|
plugins
|
java_plugin especificado en este atributo se ejecutará cuando se cree esta regla. Una biblioteca también puede heredar complementos de dependencias que usan exported_plugins . Los recursos
generados por el complemento se incluirán en el archivo jar resultante de esta regla.
|
resource_configuration_filters
|
|
resource_jars
|
|
resource_strip_prefix
|
Si se especifica, este prefijo de ruta de acceso se quita de todos los archivos en el atributo |
runtime_deps
|
deps comunes, estos aparecerán en la ruta de clase de tiempo de ejecución, pero, a diferencia de ellos, no en la ruta de clase de tiempo de compilación. Aquí se deben enumerar las dependencias que solo se necesitan en el entorno de ejecución. Las herramientas de análisis de dependencias deben ignorar los objetivos que aparecen en runtime_deps y deps .
|
stamp
|
Los objetos binarios sellados no se vuelven a compilar, a menos que cambien sus dependencias. |
test_class
|
Este atributo especifica el nombre de una clase de Java que ejecutará esta prueba. Es raro que se necesite configurar esto. Si se omite este argumento, se usará la clase Java cuyo nombre corresponda al |
use_launcher
|
Si este atributo se establece como falso, se ignorarán el atributo del selector y la marca |
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)
Esta regla crea un emulador de Android configurado con las especificaciones determinadas. Este emulador se puede iniciar con un comando de ejecución de Bazel o la ejecución directa de la secuencia de comandos generada. Te recomendamos que dependas de las reglas existentes de android_device en lugar de definir las tuyas.
Esta regla es un objetivo adecuado para la marca --run_under en la prueba de Bazel y la ejecución blaze. Inicia un emulador, copia el destino que se está probando o ejecutando en el emulador, y lo prueba o lo ejecuta según corresponda.
android_device
admite la creación de imágenes de KVM si la system_image subyacente se basa en X86 y está optimizada como máximo para la arquitectura de CPU I686. Para usar KVM, agrega tags = ['requires-kvm']
a la regla android_device
.
Objetivos de salida implícitos
name_images/userdata.dat
: Contiene instantáneas y archivos de imagen para iniciar el emulador.name_images/emulator-meta-data.pb
: Contiene información serializada necesaria para pasarlo al emulador a fin de reiniciarlo.
Ejemplos
En el siguiente ejemplo, se muestra cómo usar android_device.
//java/android/helloandroid/BUILD
contiene
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
contiene:
ro.product.brand=google ro.product.device=crespo ro.product.manufacturer=samsung ro.product.model=Nexus S ro.product.name=soju
Esta regla generará imágenes y una secuencia de comandos de inicio. Puedes iniciar el emulador de forma local si ejecutas bazel run :nexus_s -- --action=start. La secuencia de comandos expone las siguientes marcas:
- --adb_port: Es el puerto en el que se expondrá adb. Si deseas emitir comandos adb al emulador, este es el puerto al que emitirás la conexión de adb.
- --emulator_port: es el puerto en el que se expondrá la consola de administración telnet del emulador.
- --enable_display: Inicia el emulador con una pantalla si es verdadero (el valor predeterminado es falso).
- --action: iniciar o eliminar.
- --apks_to_install: lista de APK para instalar en el emulador.
Argumentos
Atributos | |
---|---|
name |
Un nombre único para este destino. |
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)
Configura Bazel para usar un NDK de Android a fin de admitir la compilación de destinos de Android con código nativo.
Ten en cuenta que compilar para Android también requiere una regla android_sdk_repository
en el archivo WORKSPACE
.
Para obtener más información, consulta la documentación completa sobre el uso del NDK de Android con Bazel.
Ejemplos
android_ndk_repository( name = "androidndk", )
En el ejemplo anterior, se ubicará tu NDK de Android desde $ANDROID_NDK_HOME
y se detectará el nivel de API más alto que admita.
android_ndk_repository( name = "androidndk", path = "./android-ndk-r20", api_level = 24, )
En el ejemplo anterior, se usará el NDK de Android ubicado dentro de tu lugar de trabajo en ./android-ndk-r20
. Utilizará las bibliotecas de nivel de API 24 cuando compile tu código JNI.
cpufeatures
El NDK de Android contiene la biblioteca de cpufeatures que se puede usar para detectar la CPU de un dispositivo en el tiempo de ejecución. En el siguiente ejemplo, se muestra cómo usar cpufeatures con Bazel.
# jni.cc #include "ndk/sources/android/cpufeatures/cpu-features.h" ...
# BUILD cc_library( name = "jni", srcs = ["jni.cc"], deps = ["@androidndk//:cpufeatures"], )
Argumentos
Atributos | |
---|---|
name |
Un nombre único para este destino. |
api_level
|
|
path
|
$ANDROID_NDK_HOME .
Puedes descargar el NDK de Android desde el sitio para desarrolladores de Android . |
repo_mapping
|
Por ejemplo, una entrada |
android_sdk_repository
android_sdk_repository(name, api_level, build_tools_version, path, repo_mapping)
Configura Bazel para usar un SDK de Android local y admitir la compilación de destinos de Android.
Ejemplos
El mínimo para configurar un SDK de Android para Bazel es incluir una reglaandroid_sdk_repository
llamada "androidsdk" en el archivo WORKSPACE
y establecer la variable de entorno $ANDROID_HOME
en la ruta del SDK de Android. De forma predeterminada, Bazel usará el nivel de API de Android más alto y la versión de herramientas de compilación instaladas en el SDK de Android de forma predeterminada.
android_sdk_repository( name = "androidsdk", )
Para garantizar compilaciones reproducibles, los atributos path
, api_level
y build_tools_version
se pueden establecer en valores específicos. La compilación fallará si el SDK de Android no tiene instalada el nivel de API especificado o la versión de herramientas de compilación.
android_sdk_repository( name = "androidsdk", path = "./sdk", api_level = 19, build_tools_version = "25.0.0", )
En el ejemplo anterior, también se muestra el uso de una ruta relativa al lugar de trabajo al SDK de Android. Esto es útil si el SDK de Android forma parte de tu lugar de trabajo de Bazel (p.ej., si se registra en el control de versión).
Bibliotecas de compatibilidad
Las bibliotecas de compatibilidad están disponibles en Android SDK Manager como "Repositorio de compatibilidad de Android".
Este es un conjunto con versión de bibliotecas comunes de Android, como las bibliotecas de compatibilidad y AppCompat, que se empaqueta como un repositorio Maven local. android_sdk_repository
genera destinos
de Bazel para cada una de estas bibliotecas que se pueden usar en las dependencias de los destinos
android_binary
y android_library
.
Los nombres de los destinos generados derivan de las coordenadas de Maven de las bibliotecas del Repositorio de compatibilidad de Android, con el formato @androidsdk//${group}:${artifact}-${version}
.
En el siguiente ejemplo, se muestra cómo un android_library
puede depender de la versión 25.0.0 de la biblioteca appcompat versión 7.
android_library( name = "lib", srcs = glob(["*.java"]), manifest = "AndroidManifest.xml", resource_files = glob(["res/**"]), deps = ["@androidsdk//com.android.support:appcompat-v7-25.0.0"], )
Argumentos
Atributos | |
---|---|
name |
Un nombre único para este destino. |
api_level
|
La marca Para ver todos los destinos |
build_tools_version
|
Bazel requiere la versión 30.0.0 o una posterior de las herramientas de compilación. |
path
|
$ANDROID_HOME .
Puedes descargar el SDK de Android desde el sitio para desarrolladores de Android. |
repo_mapping
|
Por ejemplo, una entrada |