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).
Destinos de salida implícitos
name.apk
: Es una aplicación para Android. archivo de paquete firmado con claves de depuración y zipaligned, podría usarse para desarrollar y depurar tu aplicación. No puedes lanzar tu aplicación si la firmaste con las claves de depuración.name_unsigned.apk
: Es una versión sin firmar de la anterior que podría firmarse con las claves de lanzamiento antes del lanzamiento del público.name_deploy.jar
: Es un archivo Java que contiene lo siguiente: cierre transitivo de este objetivo.El jar de implementación contiene todas las clases que encontraría un archivo classloader que buscó la ruta de clase del tiempo de ejecución de este objetivo de principio a fin.
name_proguard.jar
: Es un archivo de Java que contiene lo siguiente: el resultado de ejecutar ProGuard en elname_deploy.jar
Este resultado solo se produce si proguard_specs es el especificada.name_proguard.map
: Es un resultado de archivo de asignación de ejecutando ProGuard enname_deploy.jar
Este resultado solo se produce si proguard_specs es el especificadas y proguard_generate_mapping o shrink_resources.
Ejemplos
Puedes encontrar ejemplos de reglas de Android en el directorio examples/android
de la
Á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
cc_library que une o produce bibliotecas nativas .so para el
Plataforma de segmentación de Android.
|
srcs
|
Se compilaron los archivos Se descomprimen |
assets
|
glob de todos los archivos del
assets . También puedes hacer referencia a otras reglas (cualquier regla que produzca
archivos) o exportados en los otros paquetes, siempre que todos esos archivos estén en el
assets_dir en el paquete correspondiente.
|
assets_dir
|
assets .
El par assets y assets_dir describen los paquetes
se deben proporcionar los recursos y se deben proporcionar ambos, o ninguno.
|
crunch_png
|
|
custom_package
|
|
debug_key
|
ADVERTENCIA: No uses las claves de producción, ya que estén estrictamente protegidas y no se guarden en el árbol fuente. |
debug_signing_keys
|
ADVERTENCIA: No uses las claves de producción, ya que estén estrictamente protegidas y no se guarden en el árbol fuente. |
debug_signing_lineage_file
|
ADVERTENCIA: No uses las claves de producción, ya que estén estrictamente protegidas y no se guarden en el árbol fuente. |
densities
|
|
dex_shards
|
Ten en cuenta que cada fragmento generará al menos un DEX en la app final. Por este motivo, no se recomienda configurar esto en más de 1 para los objetos binarios de lanzamiento. |
dexopts
|
|
enable_data_binding
|
Para compilar una app para Android con vinculación de datos, también debes hacer lo siguiente:
|
incremental_dexing
|
|
instruments
|
Es el objetivo Si se establece 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.class multidex="manual_main_dex" .
|
main_dex_list_opts
|
|
main_dex_proguard_specs
|
multidex se establece en legacy .
|
manifest
|
AndroidManifest.xml .
Se debe definir si se definen recursos_archivos o recursos.
|
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á siempre que
se compila este destino. Recursos generados por
el complemento se incluirá en el archivo jar de resultados de
el objetivo.
|
proguard_apply_dictionary
|
|
proguard_apply_mapping
|
proguard_generate_mapping para que se
volver a usarse para aplicar la misma asignación a una compilación nueva.
|
proguard_generate_mapping
|
proguard_specs es
especificada. Este archivo enumerará la asignación entre el original y
nombres de clases, métodos y campos ofuscados.
ADVERTENCIA: Si se usa este atributo, ProGuard
la especificación no debe contener |
proguard_specs
|
|
resource_configuration_filters
|
en_XA o ar_XB .
|
resource_files
|
glob de todos los archivos del
res .
Se puede hacer referencia a los archivos generados (desde genrules) También puedes etiquetar aquí. La única restricción es que las salidas generadas deben estar bajo el mismo “ res ” como en cualquier otro
archivos de recursos que se incluyen.
|
shrink_resources
|
manifest y resource_files ), y requiere ProGuard.
Funciona prácticamente 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
de datos, 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
android_library
y
android_binary
reglas.
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 debe proporcionar a los destinos de Android que dependen de este.
|
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
.
Se coloca implícitamente la biblioteca android.jar
del tiempo de ejecución de Android.
la ruta de la clase de compilación.
Destinos de salida implícitos
libname.jar
: Es un archivo de Java.libname-src.jar
: Es un archivo que contiene lo siguiente: de origen (“Source jar”).name.aar
: Es un "aar" de Android. paquete que contiene el archivo de Java y recursos de este objetivo. No contiene el cierre transitivo.
Ejemplos
Puedes encontrar ejemplos de reglas de Android en el directorio examples/android
de la
Á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
cc_library une o produce .so bibliotecas nativas
para la plataforma de segmentación de Android.
|
srcs
|
.java o .srcjar que
se procesan para crear el destino.
Se compilaron los archivos Se descomprimen Si se omite |
assets
|
glob de todos los archivos del
assets . También puedes hacer referencia a otras reglas (cualquier regla que produzca
archivos) o exportados en los otros paquetes, siempre que todos esos archivos estén en el
assets_dir en el paquete correspondiente.
|
assets_dir
|
assets .
El par assets y assets_dir describen los paquetes
se deben proporcionar los recursos y se deben proporcionar ambos, o ninguno.
|
custom_package
|
|
enable_data_binding
|
Para compilar una app para Android con vinculación de datos, también debes hacer lo siguiente:
|
exported_plugins
|
java_plugin (p.ej., anotación
procesadores) para exportarlos a bibliotecas que dependen directamente de ella.
La lista especificada de |
exports
|
exports
se consideran dependencias directas de cualquier regla que depende directamente del
se orienta con exports .
Los |
exports_manifest
|
android_binary
que dependen de este objetivo. Los atributos uses-permissions nunca se exportan.
|
idl_import_root
|
Esta ruta se usará como raíz de importación cuando se procesen fuentes inactivas que depender de esta biblioteca. Cuando se especifica Consulta ejemplos comunes. |
idl_parcelables
|
android_library que depende de esta biblioteca, directamente
o a través de su cierre transitivo, pero no se traducirá a Java
o compilarse.
Solo los Estos archivos deben estar ubicados correctamente 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 depende de esta biblioteca, directamente
o a través de su cierre transitivo, pero no se traducirá a Java
o compilarse.
Solo los archivos |
idl_srcs
|
srcs .
Estos archivos estarán disponibles como importaciones para cualquier
Destino Estos archivos deben estar ubicados correctamente 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 .
Se debe definir si se definen recursos_archivos o recursos.
|
neverlink
|
neverlink no se usarán en
Creación de .apk . Es útil si la biblioteca se proporciona a través del
del entorno de ejecución durante la ejecución.
|
plugins
|
java_plugin especificado en
el atributo de complementos se ejecutará siempre que
se compila este destino. Recursos generados por
el complemento se incluirá en el archivo jar de resultados de
el objetivo.
|
proguard_specs
|
android_binary según la biblioteca.
Los archivos incluidos aquí solo deben tener reglas idempotentes, es decir, -dontnote, -dontwarn,
asume 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
res .
Se puede hacer referencia a los archivos generados (desde genrules) También puedes etiquetar aquí. La única restricción es que las salidas generadas deben estar bajo el mismo “ res ” como en cualquier otro
archivos de recursos que se incluyen.
|
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. Si
iniciar un emulador, instalar la aplicación que se está probando, la aplicación de prueba y
cualquier otra aplicación necesaria y ejecuta las pruebas definidas en el paquete de pruebas.
El atributo test_app especifica la
android_binary
, que contiene la prueba. Este android_binary
a la vez
especifica la aplicación de android_binary
que se está probando mediante su
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
|
Es el elemento 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 el destino durante el que realiza pruebas
su 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 es para probar unidades de reglas android_library
de forma local
(a diferencia de un dispositivo).
Funciona con el framework de pruebas de Robolectric de Android.
Consulta el sitio de Android Robolectric para obtener más información sobre
escribiendo pruebas de Robolectric.
Destinos de salida implícitos
name.jar
: Es un archivo Java de la prueba.name-src.jar
: Es un archivo que contiene las fuentes. ("archivo de origen").name_deploy.jar
: Es un archivo de implementación de Java adecuado. para la implementación (solo se compila si se solicita explícitamente).
Ejemplos
Para usar Robolectric con android_local_test
, agrega
Robolectric's
repositorio 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()
maven_jar
necesarias para Robolectric.
Luego, cada regla android_local_test
debería depender
@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 compilaron los archivos Se descomprimen Se ignoran todos los demás archivos, siempre y cuando hay al menos un archivo de uno de los tipos descritos anteriormente. De lo contrario, se si 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 de Java incluye una definición de 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 del
la clase principal seguida de un elemento Ten en cuenta que este atributo no tiene efecto en |
manifest
|
AndroidManifest.xml .
Debe definirse si se definen recursos_files o assets, o si alguno de los manifiestos de
Las bibliotecas que se están probando tienen una etiqueta minSdkVersion .
|
manifest_values
|
applicationId , versionCode y versionName
minSdkVersion , targetSdkVersion y
maxSdkVersion también anulará los atributos correspondientes
del manifiesto y
uses-sdk. packageName se ignorará y se establecerá desde cualquiera de las dos opciones
applicationId si
especificado o 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á cada vez que esta regla
la infraestructura. Una biblioteca también puede heredar complementos de dependencias que usan
exported_plugins Recursos
que genera 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 cada archivo en el |
runtime_deps
|
deps comunes, estos aparecerán en la ruta de clase del tiempo de ejecución, pero, a diferencia de
no en la ruta de clase del tiempo de compilación. Las dependencias que se necesitan solo en el entorno de ejecución
que se enumeran aquí. Las herramientas de análisis de dependencias deben ignorar los objetivos que aparecen en ambos
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 Java que ejecutará
esta prueba. No es común establecer esta configuración. Si se omite este argumento, la clase Java
cuyo nombre corresponde al |
use_launcher
|
Si este atributo se establece en falso,
launcher y los atributos relacionados
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 Android Emulator configurado con el y las especificaciones del servicio. Este emulador puede iniciarse mediante una ejecución de Bazel o ejecutando directamente la secuencia de comandos generada. Se recomienda que dependa según las reglas existentes de android_device, en lugar de definir la tuya.
Esta regla es un destino adecuado para que la marca --run_under realice pruebas de Bazel y Blaze. cuando se ejecute. Inicia un emulador, copia el destino que se está probando o ejecuta en el emulador. y lo prueba o ejecuta según corresponda.
android_device
admite la creación de imágenes de KVM si la instancia
system_image se basa en X86 y
como máximo para la arquitectura de CPU I686. Para usar KVM, agrega
tags = ['requires-kvm']
a la regla android_device
.
Destinos de salida implícitos
name_images/userdata.dat
: Contiene instantáneas y archivos de imagen para iniciar el emuladorname_images/emulator-meta-data.pb
: Contiene información serializada necesaria para pasar al emulador al reiniciarla.
Ejemplos
En el siguiente ejemplo, se muestra la manera de 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 lo siguiente:
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 localmente ejecutando bazel run :nexus_s -- --action=start. La secuencia de comandos expone las siguientes marcas:
- --adb_port: Es el puerto en el que se debe exponer adb. Si deseas emitir adb al emulador, este es el puerto en el que se emitirá adb connect a los que tiene acceso una cuenta.
- --emulator_port: Es el puerto en el que se expone la administración de Telnet del emulador. la consola de Cloud.
- --enable_display: Inicia el emulador con una pantalla si es verdadero (valor predeterminado). como falso).
- --action: Comienza o termina.
- --apks_to_install: Una 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 que use un NDK de Android y admita la compilación de destinos de Android con formatos nativos. código.
Ten en cuenta que compilar para Android también requiere una regla android_sdk_repository
en tu
archivo WORKSPACE
.
Para obtener más información, consulta el documentación completa sobre el uso del NDK de Android con Bazel.
Ejemplos
android_ndk_repository( name = "androidndk", )
El ejemplo anterior ubicará tu NDK de Android en $ANDROID_NDK_HOME
y detectará
el nivel de API más alto que admita.
android_ndk_repository( name = "androidndk", path = "./android-ndk-r20", api_level = 24, )
El ejemplo anterior usará el NDK de Android ubicado dentro de tu espacio de trabajo en
./android-ndk-r20
Usará las bibliotecas de nivel de API 24 cuando compile tu JNI
código.
funciones de CPU
Android NDK contiene las Biblioteca cpufeatures que se puede usar para detectar la CPU de un dispositivo durante 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 .
El NDK de Android se puede descargar 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 que use un SDK de Android local para admitir la compilación de destinos de Android.
Ejemplos
Lo mínimo para configurar un SDK de Android para Bazel es colocar una reglaandroid_sdk_repository
.
llamado "androidsdk" en tu archivo WORKSPACE
y establece el $ANDROID_HOME
variable de entorno a la ruta de acceso de tu SDK de Android. Bazel usará el nivel de API de Android más alto
y la versión de las herramientas de compilación
instalada en el SDK de Android de forma predeterminada.
android_sdk_repository( name = "androidsdk", )
Para garantizar compilaciones reproducibles, path
, api_level
y
Los atributos build_tools_version
se pueden establecer en valores específicos. La compilación fallará si
El SDK de Android no tiene instalado el nivel de API especificado ni la versión de las 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 demuestra el uso de una ruta de acceso relativa del espacio de trabajo al SDK de Android. Este es Es útil si el SDK de Android forma parte de tu espacio de trabajo de Bazel (p.ej., si está registrado en la versión control).
Bibliotecas de compatibilidad
Las bibliotecas de compatibilidad están disponibles en SDK Manager de Android como "Repositorio de compatibilidad de Android".
Se trata de un conjunto con control de versiones de bibliotecas de Android comunes, como las bibliotecas de compatibilidad y AppCompat,
empaquetado como un repositorio local de Maven. android_sdk_repository
genera Bazel.
objetivos para cada una de estas bibliotecas que se pueden usar en las dependencias
Destinos android_binary
y android_library
.
Los nombres de los destinos generados derivan de las coordenadas de Maven de las bibliotecas en la
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 v7.
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
|
El nivel de API que se usa para una compilación determinada se puede anular con Para ver todos los destinos de |
build_tools_version
|
Bazel requiere la versión 30.0.0 o posterior de las herramientas de compilación. |
path
|
$ANDROID_HOME .
El SDK de Android se puede descargar el sitio para desarrolladores de Android. |
repo_mapping
|
Por ejemplo, una entrada |