Regras
- 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)
Produz arquivos de pacotes de aplicativos Android (.apk).
Destinos de saída implícitos
name.apk
: um arquivo de pacote de app Android assinado com chaves de depuração e zipaligned. Ele pode ser usado para desenvolver e depurar seu app. Não é possível lançar seu aplicativo quando assinado com as chaves de depuração.name_unsigned.apk
: uma versão não assinada do arquivo acima que pode ser assinada com as chaves de lançamento antes de ser lançada para o público.name_deploy.jar
: um arquivo Java que contém o fechamento transitivo desse destino.O jar de implantação contém todas as classes que seriam encontradas por um carregador de classe que pesquisou o caminho de classe do ambiente de execução desse destino do início ao fim.
name_proguard.jar
: um arquivo Java que contém o resultado da execução do ProGuard noname_deploy.jar
. Essa saída só será produzida se o atributo proguard_specs for especificado.name_proguard.map
: um resultado do arquivo de mapeamento da execução do ProGuard noname_deploy.jar
. Essa saída só vai ser produzida se o atributo proguard_specs for especificado e proguard_generate_mapping ou shrink_resources.
Exemplos
Exemplos de regras do Android podem ser encontrados no diretório examples/android
da
árvore de origem do Bazel.
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. |
deps
|
android_library ,
java_library com restrição android e
cc_library encapsulando ou produzindo .so bibliotecas nativas para a
plataforma de destino do Android.
|
srcs
|
Arquivos Arquivos |
assets
|
glob de todos os arquivos no diretório
assets . Também é possível referenciar outras regras (qualquer regra que produza
arquivos) ou arquivos exportados em outros pacotes, desde que todos esses arquivos estejam no diretório
assets_dir no pacote correspondente.
|
assets_dir
|
assets .
O par assets e assets_dir descrevem recursos empacotados
e ambos os atributos precisam ser fornecidos ou nenhum deles.
|
crunch_png
|
|
custom_package
|
|
debug_key
|
AVISO: não use suas chaves de produção. Elas precisam ser estritamente protegidas e não podem ser mantidas na árvore de origem. |
debug_signing_keys
|
AVISO: não use suas chaves de produção. Elas precisam ser estritamente protegidas e não podem ser mantidas na árvore de origem. |
debug_signing_lineage_file
|
AVISO: não use suas chaves de produção. Elas precisam ser estritamente protegidas e não podem ser mantidas na árvore de origem. |
densities
|
|
dex_shards
|
Cada fragmento resultará em pelo menos um dex no app final. Por esse motivo, não é recomendável definir esse valor como mais de 1 para binários de lançamento. |
dexopts
|
|
enable_data_binding
|
Para criar um app Android com vinculação de dados, também é necessário fazer o seguinte:
|
incremental_dexing
|
|
instruments
|
O objetivo Se o atributo for definido, o |
javacopts
|
Essas opções do compilador são transmitidas para javac depois das opções do compilador global |
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.classPrecisa ser usado com multidex="manual_main_dex" .
|
main_dex_list_opts
|
|
main_dex_proguard_specs
|
multidex estiver definido como legacy .
|
manifest
|
AndroidManifest.xml .
Precisa ser definido se resource_files ou recursos estiverem definidos.
|
manifest_values
|
|
multidex
|
Valores possíveis:
|
nocompress_extensions
|
|
package_id
|
Consulte o argumento |
plugins
|
java_plugin especificado no
atributo de plug-ins será executado sempre que
esse destino for criado. Os recursos gerados pelo plug-in serão incluídos no jar de resultado do destino.
|
proguard_apply_dictionary
|
|
proguard_apply_mapping
|
proguard_generate_mapping a ser
reutilizado para aplicar o mesmo mapeamento a um novo build.
|
proguard_generate_mapping
|
proguard_specs for
especificado. Esse arquivo listará o mapeamento entre os nomes original e ofuscado de classes, métodos e campos.
AVISO: se esse atributo for usado, a especificação do
Proguard não poderá conter |
proguard_specs
|
|
resource_configuration_filters
|
en_XA e/ou ar_XB .
|
resource_files
|
glob de todos os arquivos no diretório
res .
Os arquivos gerados (de regras gerais) também podem ser referenciados por Rótulo aqui. A única restrição é que as saídas geradas precisam estar no mesmo diretório " res " que todos os outros
arquivos de recurso incluídos.
|
shrink_resources
|
manifest e resource_files ) e exige o ProGuard.
Ele opera basicamente da mesma maneira que o redutor de recursos do Gradle
(https://developer.android.com/studio/build/Premium-code.html#renew-resources).
Diferenças significativas:
name_files/resource_shrinker.log
também será gerado, detalhando a análise e as exclusões realizadas.
Valores possíveis:
|
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 regra permite o uso de arquivos .aar
como bibliotecas para regras
android_library
e
android_binary
.
Exemplos
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 |
Um nome exclusivo para o destino. |
aar
|
.aar a ser fornecido aos destinos Android que dependem desse destino.
|
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 regra compila e arquiva as origens em um arquivo .jar
.
A biblioteca do Android Runtime android.jar
é colocada implicitamente no
caminho da classe de compilação.
Destinos de saída implícitos
libname.jar
: um arquivo Java.libname-src.jar
: um arquivo que contém as origens ("jar de origem").name.aar
: um pacote "aar" do Android que contém o arquivo Java e os recursos desse destino. Ele não contém a interdição transitiva.
Exemplos
Exemplos de regras do Android podem ser encontrados no diretório examples/android
da
árvore de origem do Bazel.
O exemplo abaixo mostra
como definir idl_import_root
.
Permitir que //java/bazel/helloandroid/BUILD
contenha:
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 |
Um nome exclusivo para o destino. |
deps
|
android_library ,
java_library com restrição android e
cc_library encapsulando ou produzindo .so bibliotecas nativas
para a plataforma de destino Android.
|
srcs
|
.java ou .srcjar processados para criar o destino.
Arquivos Arquivos Se |
assets
|
glob de todos os arquivos no diretório
assets . Também é possível referenciar outras regras (qualquer regra que produza
arquivos) ou arquivos exportados em outros pacotes, desde que todos esses arquivos estejam no diretório
assets_dir no pacote correspondente.
|
assets_dir
|
assets .
O par assets e assets_dir descrevem recursos empacotados
e ambos os atributos precisam ser fornecidos ou nenhum deles.
|
custom_package
|
|
enable_data_binding
|
Para criar um app Android com vinculação de dados, também é necessário fazer o seguinte:
|
exported_plugins
|
java_plugin s (por exemplo, processadores
de anotações) a serem exportados para bibliotecas que dependem diretamente dessa biblioteca.
A lista especificada de |
exports
|
exports
é considerado dependências diretas de qualquer regra que dependa diretamente do
destino com exports .
As |
exports_manifest
|
android_binary
que dependem desse destino. Os atributos uses-permissions nunca são exportados.
|
idl_import_root
|
Esse caminho será usado como a raiz de importação ao processar origens inativas que dependem dessa biblioteca. Quando Confira exemplos. |
idl_parcelables
|
android_library que dependa dessa biblioteca, diretamente
ou por meio do fechamento transitivo dele, mas não serão convertidos para Java
nem compilados.
Somente arquivos Esses arquivos precisam ser colocados corretamente para que o compilador AIL os encontre. Consulte a descrição de idl_import_root para informações sobre o que isso significa. |
idl_preprocessed
|
android_library que dependa dessa biblioteca, diretamente
ou por meio do fechamento transitivo dele, mas não serão convertidos para Java
nem compilados.
Somente arquivos |
idl_srcs
|
srcs .
Esses arquivos serão disponibilizados como importações para qualquer destino Esses arquivos precisam ser colocados corretamente para que o compilador AIL os encontre. Consulte a descrição de idl_import_root para informações sobre o que isso significa. |
javacopts
|
Essas opções do compilador são transmitidas para javac depois das opções do compilador global |
manifest
|
AndroidManifest.xml .
Precisa ser definido se resource_files ou recursos estiverem definidos.
|
neverlink
|
neverlink não serão usados na
criação de .apk . Útil quando a biblioteca for fornecida pelo ambiente de execução durante a execução.
|
plugins
|
java_plugin especificado no
atributo de plug-ins será executado sempre que
esse destino for criado. Os recursos gerados pelo plug-in serão incluídos no jar de resultado do destino.
|
proguard_specs
|
android_binary , dependendo dessa biblioteca.
Os arquivos incluídos aqui precisam ter apenas regras idempotentes, como -dontnote, -dontwarn,
suposições de efeitos colaterais e regras que começam com -keep. Outras opções só podem aparecer nas
proguard_specs de android_binary para garantir mesclagens não automáticas.
|
resource_files
|
glob de todos os arquivos no diretório
res .
Os arquivos gerados (de regras gerais) também podem ser referenciados por Rótulo aqui. A única restrição é que as saídas geradas precisam estar no mesmo diretório " res " que todos os outros
arquivos de recurso incluídos.
|
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)
Uma regra android_instrumentation_test
executa testes de instrumentação do Android. Ele
vai iniciar um emulador, instalar o aplicativo que está sendo testado, o aplicativo de teste e
quaisquer outros aplicativos necessários e executar os testes definidos no pacote de teste.
O atributo test_app especifica o
android_binary
que contém o teste. Esse android_binary
, por sua vez, especifica o aplicativo android_binary
em teste por meio do atributo instruments.
Exemplo
# 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 |
Um nome exclusivo para o destino. |
support_apks
|
|
target_device
|
O android_device em que o teste será executado. Para executar o teste em um emulador que já esteja em execução ou em um dispositivo físico, use
estes argumentos:
|
test_app
|
android_binary precisa especificar qual destino está sendo testado por meio do
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)
Essa regra é para o teste de unidade de regras android_library
localmente, e não em um dispositivo.
Funciona com o framework de testes do Android Robolectric.
Consulte o site do Android Robolectric para ver detalhes sobre
como criar testes Robolectric.
Destinos de saída implícitos
name.jar
: um arquivo Java do teste.name-src.jar
: um arquivo que contém as origens ("jar de origem").name_deploy.jar
: um arquivo de implantação Java adequado para implantação (criado apenas se solicitado explicitamente).
Exemplos
Para usar o Robolectric com android_local_test
, adicione o
repositório
do Robolectric ao seu arquivo 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(). Isso extrai as regras
maven_jar
necessárias para o Robolectric.
Então, cada regra android_local_test
precisa depender de
@robolectric//bazel:robolectric
. Veja um exemplo abaixo.
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 |
Um nome exclusivo para o destino. |
deps
|
A lista de regras permitidas em |
srcs
|
Arquivos Arquivos Todos os outros arquivos são ignorados, desde que haja pelo menos um arquivo do tipo descrito acima. Caso contrário, será gerado um erro.
O atributo |
custom_package
|
test_class .
|
densities
|
|
enable_data_binding
|
|
javacopts
|
Essas opções do compilador são transmitidas para javac depois das opções do compilador global |
jvm_flags
|
O script de wrapper de um binário Java inclui uma definição CLASSPATH (para encontrar todos os jars dependentes) e invoca o intérprete Java correto.
A linha de comando gerada pelo script de wrapper inclui o nome da classe principal seguido por um Observe que esse atributo não tem efeito nas saídas de |
manifest
|
AndroidManifest.xml .
Precisa ser definido se os resource_files ou os recursos estiverem definidos, ou se algum dos manifestos das
bibliotecas em teste tiver uma tag minSdkVersion .
|
manifest_values
|
applicationId , versionCode , versionName ,
minSdkVersion , targetSdkVersion e
maxSdkVersion também vão substituir os atributos correspondentes
das tags de manifesto e
usage-sdk. packageName será ignorado e definido em
applicationId , se
especificado, ou do pacote no manifesto.
Não é necessário ter um manifesto na regra para usar manifest_values.
|
nocompress_extensions
|
|
plugins
|
java_plugin especificado neste atributo será executado sempre que essa regra for criada. Uma biblioteca também pode herdar plug-ins de dependências que usam
exported_plugins . Os recursos gerados pelo plug-in serão incluídos no jar resultante dessa regra.
|
resource_configuration_filters
|
|
resource_jars
|
|
resource_strip_prefix
|
Se especificado, esse prefixo de caminho é removido de todos os arquivos no atributo
|
runtime_deps
|
deps comum, eles vão aparecer no caminho de classe da execução, mas, ao contrário deles, não no caminho de classe do tempo de compilação. As dependências necessárias apenas no momento da execução precisam ser listadas aqui. As ferramentas de análise de dependência precisam ignorar os destinos que aparecem em runtime_deps e deps .
|
stamp
|
Os binários carimbos não são recriados, a menos que as dependências deles mudem. |
test_class
|
Este atributo especifica o nome de uma classe Java a ser executada por este teste. É raro configurar isso. Se esse argumento for omitido, a classe Java
com o nome que corresponde ao |
use_launcher
|
Se ele for definido como falso, o
atributo launcher e a sinalização
|
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)
Essa regra cria um Android Emulator configurado com as especificações fornecidas. Esse emulador pode ser iniciado por meio de um comando "bazel run" ou da execução direta do script gerado. É recomendável depender das regras de android_device já existentes em vez de definir as próprias regras.
Esse é um destino adequado para a sinalização --run_under de teste do bazel e execução do blaze. Ele inicia um emulador, copia o destino que está sendo testado/executado para o emulador e o testa ou executa, conforme apropriado.
android_device
oferece suporte à criação de imagens KVM se a
system_image subjacente for baseada em X86 e estiver
otimizada, no máximo, para a arquitetura de CPU I686. Para usar a KVM, adicione
tags = ['requires-kvm']
à regra android_device
.
Destinos de saída implícitos
name_images/userdata.dat
: contém arquivos de imagem e snapshots para iniciar o emulador.name_images/emulator-meta-data.pb
: contém informações serializadas necessárias para transmitir ao emulador para reiniciá-lo.
Exemplos
O exemplo abaixo mostra como usar o android_device.
//java/android/helloandroid/BUILD
contém
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
contém:
ro.product.brand=google ro.product.device=crespo ro.product.manufacturer=samsung ro.product.model=Nexus S ro.product.name=soju
Esta regra vai gerar imagens e um script inicial. Para iniciar o emulador localmente, execute bazel run :nexus_s -- --action=start. O script expõe as seguintes sinalizações:
- --adb_port: a porta em que o adb será exposto. Se você quiser emitir comandos do adb para o emulador, essa é a porta em que você emitirá o adb Connect.
- --emulator_port: a porta para expor o console de gerenciamento telnet do emulador.
- --enable_display: inicia o emulador com uma exibição, se verdadeiro (o padrão é falso).
- --action: iniciar ou encerrar.
- --apks_to_install: uma lista de apks para instalar no emulador.
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o 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 o Bazel para usar um Android NDK e oferecer suporte à criação de destinos do Android com código nativo.
A criação para Android também requer uma regra android_sdk_repository
no
arquivo WORKSPACE
.
Para saber mais, leia a documentação completa sobre como usar o Android NDK com o Bazel.
Exemplos
android_ndk_repository( name = "androidndk", )
O exemplo acima localizará seu Android NDK a partir de $ANDROID_NDK_HOME
e detectará
o nível de API mais alto com suporte.
android_ndk_repository( name = "androidndk", path = "./android-ndk-r20", api_level = 24, )
O exemplo acima usará o Android NDK localizado dentro do espaço de trabalho em
./android-ndk-r20
. Ele vai usar as bibliotecas de API de nível 24 ao compilar seu código
JNI.
cpufeatures
O Android NDK contém a biblioteca cpufeatures, que pode ser usada para detectar a CPU de um dispositivo no momento da execução. O exemplo a seguir demonstra como usar cpufeatures com o 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 |
Um nome exclusivo para o destino. |
api_level
|
|
path
|
$ANDROID_NDK_HOME precisa ser definido.
O download do Android NDK pode ser feito no site para desenvolvedores Android . |
repo_mapping
|
Por exemplo, uma entrada |
android_sdk_repository
android_sdk_repository(name, api_level, build_tools_version, path, repo_mapping)
Configura o Bazel para usar um SDK do Android local para oferecer suporte à criação de destinos do Android.
Exemplos
O mínimo para configurar um SDK do Android para o Bazel é colocar uma regraandroid_sdk_repository
chamada "androidsdk" no arquivo WORKSPACE
e definir a variável de ambiente $ANDROID_HOME
como o caminho do SDK do Android. O Bazel vai usar o nível mais alto da API do Android
e a versão das ferramentas de build instalada no SDK do Android por padrão.
android_sdk_repository( name = "androidsdk", )
Para garantir builds reproduzíveis, os atributos path
, api_level
e
build_tools_version
podem ser definidos como valores específicos. O build falhará se
o SDK do Android não tiver o nível de API especificado ou a versão das ferramentas de build instalada.
android_sdk_repository( name = "androidsdk", path = "./sdk", api_level = 19, build_tools_version = "25.0.0", )
O exemplo acima também demonstra o uso de um caminho relativo a espaço de trabalho para o SDK do Android. Isso é útil se o SDK do Android faz parte do seu espaço de trabalho do Bazel (por exemplo, se ele é verificado no controle de versões).
Bibliotecas de Suporte
As Bibliotecas de Suporte estão disponíveis no Android SDK Manager como "Repositório de Suporte do Android".
Esse é um conjunto com controle de versões de bibliotecas comuns do Android, como as bibliotecas Support e AppCompat,
empacotadas como um repositório Maven local. android_sdk_repository
gera destinos
do Bazel para cada uma dessas bibliotecas que podem ser usadas nas dependências dos
destinos android_binary
e android_library
.
Os nomes dos destinos gerados são derivados das coordenadas Maven das bibliotecas no
Android Support Repository, formatados como @androidsdk//${group}:${artifact}-${version}
.
O exemplo a seguir mostra como uma android_library
pode depender da versão 25.0.0 da
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 |
Um nome exclusivo para o destino. |
api_level
|
O nível da API usado para um determinado build pode ser substituído pela
sinalização Para acessar todos os |
build_tools_version
|
O Bazel exige a versão 30.0.0 ou mais recente das ferramentas de build. |
path
|
$ANDROID_HOME precisa ser definido.
Faça o download do SDK do Android no site do desenvolvedor Android. |
repo_mapping
|
Por exemplo, uma entrada |