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 pacote de aplicativo Android (.apk).
Destinos de saída implícitos
name.apk
: um app Android arquivo de pacote assinado com chaves de depuração e zipaligned, ele pode ser usado para desenvolver e depurar seu aplicativo. Não é possível lançar o aplicativo quando assinado com as chaves de depuração.name_unsigned.apk
: uma versão não assinada da acima, que pode ser assinado com as chaves de lançamento antes do lançamento ao 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 uma carregador de classe que pesquisou o caminho de classe do tempo de execução deste destino do início ao fim.
name_proguard.jar
: um arquivo Java contendo o resultado de executar o ProGuardname_deploy.jar
. Essa saída só é produzida se atributo proguard_specs é especificado.name_proguard.map
: um resultado do arquivo de mapeamento de executando o ProGuard noname_deploy.jar
. Essa saída só é produzida se atributo proguard_specs é especificado, e proguard_generate_mapping ou shrink_resources está definido.
Exemplos
Exemplos de regras do Android podem ser encontrados no diretório examples/android
do
Árvore de origem do Bazel.
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. |
deps
|
android_library ,
java_library com android restrição e
cc_library unindo ou produzindo bibliotecas nativas .so para o
Plataforma de destino do Android.
|
srcs
|
Arquivos Arquivos |
assets
|
glob de todos os arquivos na pasta
assets . Você também pode referenciar outras regras (qualquer regra que produza
ou arquivos exportados em outros pacotes, desde que todos esses arquivos estejam na pasta
assets_dir no pacote correspondente.
|
assets_dir
|
assets .
Os pares assets e assets_dir descrevem itens do pacote
recursos e ambos os atributos devem ser fornecidos ou nenhum deles.
|
crunch_png
|
|
custom_package
|
|
debug_key
|
AVISO: não use suas chaves de produção. Elas devem ser rigorosamente protegidos e não mantidos na árvore de origem. |
debug_signing_keys
|
AVISO: não use suas chaves de produção. Elas devem ser rigorosamente protegidos e não mantidos na árvore de origem. |
debug_signing_lineage_file
|
AVISO: não use suas chaves de produção. Elas devem ser rigorosamente protegidos e não mantidos na árvore de origem. |
densities
|
|
dex_shards
|
Observe que cada fragmento resultará em pelo menos um dex no app final. Por isso, não é recomendável definir esse valor para 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 destino Se o atributo for definido, o |
javacopts
|
Essas opções do compilador são transmitidas para javac após as 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 assets estiverem definidos.
|
manifest_values
|
|
multidex
|
Valores possíveis:
|
nocompress_extensions
|
|
package_id
|
Consulte o argumento |
plugins
|
java_plugin especificado em
o atributo de plug-ins será executado
esse destino é criado. Recursos gerados por
o plug-in será incluído no jar de resultados de
ao alvo.
|
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 o original e
nomes ofuscados de classes, métodos e campos.
AVISO: se este atributo for usado, o Proguard
a especificação não pode conter |
proguard_specs
|
|
resource_configuration_filters
|
en_XA e/ou ar_XB .
|
resource_files
|
glob de todos os arquivos na pasta
res .
Os arquivos gerados (de regras gerais) podem ser referenciados por Rótulo aqui também. A única restrição é que as saídas geradas precisam estar sob o mesmo " res " como qualquer outro
arquivos de recursos incluídos.
|
shrink_resources
|
manifest e resource_files ) e requer o ProGuard.
Ele funciona basicamente da mesma maneira que o redutor de recursos do Gradle.
(https://developer.android.com/studio/build/shrink-code.html#shrink-resources).
Diferenças significativas:
name_files/resource_shrinker.log
também serão gerados, 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)
Essa regra permite o uso de arquivos .aar
como bibliotecas para
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)
Essa regra compila e arquiva as origens em um arquivo .jar
.
A biblioteca do Android Runtime android.jar
é implicitamente colocada em
o caminho da classe de compilação.
Destinos de saída implícitos
libname.jar
: um arquivo Java.libname-src.jar
: um arquivo contendo o fontes ("jar de origem").name.aar
: um "aar" do Android. pacote contendo o arquivo Java e recursos deste destino. Ele não contém o fechamento transitivo.
Exemplos
Exemplos de regras do Android podem ser encontrados no diretório examples/android
do
Árvore de origem do Bazel.
O exemplo a seguir mostra
como definir idl_import_root
.
Permita 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 android restrição e
cc_library unindo ou produzindo .so bibliotecas nativas
para a plataforma de destino Android.
|
srcs
|
.java ou .srcjar que
são processados para criar o destino.
Arquivos Arquivos Se |
assets
|
glob de todos os arquivos na pasta
assets . Você também pode referenciar outras regras (qualquer regra que produza
ou arquivos exportados em outros pacotes, desde que todos esses arquivos estejam na pasta
assets_dir no pacote correspondente.
|
assets_dir
|
assets .
Os pares assets e assets_dir descrevem itens do pacote
recursos e ambos os atributos devem 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, de anotação
processadores) para exportar para bibliotecas que dependem diretamente dessa biblioteca.
A lista especificada de |
exports
|
exports
são consideradas dependências diretas de qualquer regra que dependa diretamente da
de destino com exports .
Os |
exports_manifest
|
android_binary
que dependem dessa meta. Os atributos uses-permissions nunca são exportados.
|
idl_import_root
|
Esse caminho será usado como raiz de importação ao processar origens inativas que dependem dessa biblioteca. Quando Consulte exemplos. |
idl_parcelables
|
android_library destino que depende dessa biblioteca, diretamente
ou por meio do fechamento transitivo, mas não são traduzidos para Java
ou compilados.
Somente arquivos Esses arquivos devem ser colocados de forma apropriada para que o compilador AID os encontre. Veja a descrição de idl_import_root para saber o que isso significa. |
idl_preprocessed
|
android_library destino que depende dessa biblioteca, diretamente
ou por meio do fechamento transitivo, mas não são traduzidos para Java
ou compilados.
Somente arquivos |
idl_srcs
|
srcs .
Esses arquivos serão disponibilizados como importações
Esses arquivos devem ser colocados de forma apropriada para que o compilador AID os encontre. Veja a descrição de idl_import_root para saber o que isso significa. |
javacopts
|
Essas opções do compilador são transmitidas para javac após as opções do compilador global. |
manifest
|
AndroidManifest.xml .
Precisa ser definido se resource_files ou assets estiverem definidos.
|
neverlink
|
neverlink não serão usadas em
Criação de .apk . Útil se a biblioteca for fornecida pelo
durante a execução.
|
plugins
|
java_plugin especificado em
o atributo de plug-ins será executado
esse destino é criado. Recursos gerados por
o plug-in será incluído no jar de resultados de
ao alvo.
|
proguard_specs
|
android_binary , dependendo dessa biblioteca.
Os arquivos incluídos aqui só podem ter regras idempotentes, como -dontnote, -dontwarn
presumanocolaterais e regras que começam com -keep. Outras opções só podem aparecer em
Proguard_specs de android_binary , para garantir mesclas não tautológicas.
|
resource_files
|
glob de todos os arquivos na pasta
res .
Os arquivos gerados (de regras gerais) podem ser referenciados por Rótulo aqui também. A única restrição é que as saídas geradas precisam estar sob o mesmo " res " como qualquer outro
arquivos de recursos 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 execute os testes definidos no pacote de testes.
O atributo test_app especifica o
android_binary
, que contém o teste. Este android_binary
, por sua vez
especifica o aplicativo android_binary
em teste pela própria
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 deve 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
ao 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 regra é válida para testes de unidade de regras android_library
localmente
(não em um dispositivo).
Ele funciona com o framework de testes Robolectric do Android.
Consulte o site do Android Robolectric para mais detalhes sobre
escrever testes Robolectric.
Destinos de saída implícitos
name.jar
: um arquivo Java do teste.name-src.jar
: um arquivo contendo 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 o android_local_test
, adicione
do Robolectric
repositório 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
vai depender
@robolectric//bazel:robolectric
. Confira o 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 serão ignorados, desde que há pelo menos um arquivo do tipo descrito acima. Caso contrário, um é gerado.
O atributo |
custom_package
|
test_class .
|
densities
|
|
enable_data_binding
|
|
javacopts
|
Essas opções do compilador são transmitidas para javac após as opções do compilador global. |
jvm_flags
|
O script de wrapper para um binário Java inclui uma definição de CLASSPATH
(para encontrar todos os jars dependentes) e invoca o interpretador Java correto.
A linha de comando gerada pelo script do wrapper inclui o nome do
a classe principal seguida por um Esse atributo não tem efeito em |
manifest
|
AndroidManifest.xml .
Deve ser definido se resource_files ou assets forem definidos ou se algum dos manifestos de
as bibliotecas em teste têm uma tag minSdkVersion .
|
manifest_values
|
applicationId , versionCode e versionName .
minSdkVersion , targetSdkVersion e
maxSdkVersion também vai substituir os atributos correspondentes
do manifesto e
usa-sdk. packageName será ignorado e definido como
applicationId se
especificado ou o 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 esta regra
é construído. Uma biblioteca também pode herdar plug-ins de dependências que usam
exported_plugins : 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 |
runtime_deps
|
deps comum, eles vão aparecer no caminho de classe do tempo de execução, mas, ao contrário
e não no caminho de classe do tempo de compilação. As dependências necessárias apenas no ambiente de execução devem ser
listadas aqui. As ferramentas de análise de dependência devem ignorar os destinos que aparecem em ambos
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
nesse teste. É raro precisar definir isso. Se este argumento for omitido, a classe Java
cujo nome corresponde ao |
use_launcher
|
Se este atributo for definido como falso, o
atributo launcher e o relacionado
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)
Esta regra cria um emulador Android configurado com a especificações. Este emulador pode ser iniciado por uma execução do Bazel ou executando diretamente o script gerado. É recomendado que você dependa com base em regras android_device existentes, em vez de definir suas próprias regras.
Esta regra é um destino adequado para a flag --run_under fazer o teste do Bazel e o blaze. correr. Ele inicia um emulador, copia o destino que está sendo testado/executado para o emulador e testa ou executa conforme apropriado.
android_device
oferece suporte à criação de imagens KVM se o componente
system_image é baseado em X86 e é
otimizada para, no máximo, 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 emuladorname_images/emulator-meta-data.pb
: Contém informações serializadas necessárias para transmitir ao emulador reiniciá-lo.
Exemplos
O exemplo abaixo mostra como usar 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 de inicialização. Você pode iniciar o emulador localmente, executando bazel run :nexus_s --action=start. O script apresenta as seguintes sinalizações:
- --adb_port: a porta em que o adb será exposto. Se você quiser emitir o adb para o emulador, essa é a porta em que você emitirá o adb connect
- -- emulator_port: a porta para expor o gerenciamento de telnet do emulador o console.
- --enable_display: inicia o emulador com uma tela, se verdadeira (o padrão é como falso).
- --action: iniciar ou encerrar.
- --apks_to_install: uma lista de APKs a serem instalados 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 Android com dados nativos. o código-fonte.
A criação para Android também exige uma regra android_sdk_repository
na sua
arquivo WORKSPACE
.
Para mais informações, 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 de $ANDROID_NDK_HOME
e detectará
API de nível mais alto com suporte.
android_ndk_repository( name = "androidndk", path = "./android-ndk-r20", api_level = 24, )
O exemplo acima vai usar o Android NDK localizado no espaço de trabalho do
./android-ndk-r20
: Ele usará as bibliotecas de API de nível 24 ao compilar seu JNI
o código-fonte.
cpufeatures
O Android NDK contém as Biblioteca cpufeatures que pode ser usado para detectar a CPU de um dispositivo durante a 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 definida.
O Android NDK pode ser baixado em o site do desenvolvedor 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 local do Android com suporte à criação de destinos do Android.
Exemplos
O mínimo para configurar um SDK do Android para Bazel é colocar uma regraandroid_sdk_repository
chamado "androidsdk" no arquivo WORKSPACE
e defina $ANDROID_HOME
variável de ambiente para 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 instaladas no SDK do Android por padrão.
android_sdk_repository( name = "androidsdk", )
Para garantir builds reproduzíveis, path
, api_level
e
Os atributos build_tools_version
podem ser definidos para valores específicos. O build falhará se
o SDK do Android não tem o nível especificado da API ou da versão das ferramentas de build instalado.
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 ao espaço de trabalho para o SDK do Android. Isso é Útil se o SDK do Android fizer parte do seu espaço de trabalho do Bazel (por exemplo, se for verificado na versão controle).
Bibliotecas de Suporte
As Bibliotecas de Suporte estão disponíveis no Android SDK Manager como "Repositório de Suporte do Android".
Este é um conjunto com controle de versões de bibliotecas comuns do Android, como as bibliotecas Support e AppCompat,
empacotado como repositório Maven local. android_sdk_repository
gera o Bazel
destinos para cada uma dessas bibliotecas que podem ser usados nas dependências do
Metas android_binary
e android_library
.
Os nomes dos destinos gerados são derivados das coordenadas do Maven das bibliotecas na
Repositório de Suporte do Android, formatado como @androidsdk//${group}:${artifact}-${version}
.
O exemplo a seguir mostra como um android_library
pode depender da versão 25.0.0 do
Biblioteca appcompatibilidade 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 pelo Para conferir todos os destinos |
build_tools_version
|
O Bazel exige a versão 30.0.0 ou mais recente das ferramentas de build. |
path
|
$ANDROID_HOME precisa ser definida.
Baixe o SDK do Android em site para desenvolvedores Android. |
repo_mapping
|
Por exemplo, uma entrada |