Regras
- android_binary
- aar_import
- android_library
- android_instrumentation_test
- android_local_test
- android_device
- android_ndk_repository
- android_sdk_repository
binário_android
Ver origem da regraandroid_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 apps Android (.apk).
Destinos de saída implícita
name.apk
: um arquivo de pacote de app Android assinado com chaves de depuração e zipaligned, que pode ser usado para desenvolver e depurar seu app. Não é possível liberar o aplicativo quando ele está 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 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 um carregador de classe que pesquisou o caminho de classe de tempo 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 de arquivo de mapeamento de 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 estiverem definidos.
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 esse destino. |
deps
|
android_library ,
java_library com restrição de android e
cc_library envolvendo ou produzindo bibliotecas nativas de .so para a
plataforma de destino do Android.
|
srcs
|
Os 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 nos outros pacotes, desde que todos estejam no diretório assets_dir no pacote correspondente.
|
assets_dir
|
assets .
O par assets e assets_dir descrevem os 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 totalmente 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 totalmente 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 totalmente protegidas e não podem ser mantidas na árvore de origem. |
densities
|
|
dex_shards
|
Observe que cada fragmento resulta em pelo menos um dex no app final. Por esse motivo, não é recomendável definir esse fragmento como mais de um para os binários de lançamento. |
dexopts
|
|
enable_data_binding
|
Para criar um app Android com vinculação de dados, você também precisa fazer o seguinte:
|
incremental_dexing
|
|
instruments
|
O destino Se esse atributo for definido, a |
javacopts
|
Essas opções do compilador são transmitidas para javac após as opções globais do 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.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 forem definidos.
|
manifest_values
|
|
multidex
|
Possíveis valores:
|
nocompress_extensions
|
|
package_id
|
Consulte o argumento |
plugins
|
java_plugin especificado no
atributo de plug-ins será executado sempre que
o 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 para ser reutilizado para aplicar o mesmo mapeamento a um novo build.
|
proguard_generate_mapping
|
proguard_specs for especificado. Esse arquivo lista o mapeamento entre a classe, o método e os nomes de campo originais e ofuscados.
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 .
Aqui, os arquivos gerados (de regras gerais) também podem ser referenciados por Rótulo. A única restrição é que as saídas geradas precisam estar no mesmo diretório " res " de qualquer outro
arquivo de recursos incluído.
|
shrink_resources
|
manifest e resource_files ) e requer o ProGuard.
Ele funciona quase da mesma forma 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 vai ser gerado, detalhando a análise e as exclusões realizadas.
Valores possíveis:
|
aar_import
Ver origem da regraaar_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 as 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 esse destino. |
aar
|
.aar a ser fornecido aos destinos do Android que dependem desse destino.
|
exports
|
|
srcjar
|
|
biblioteca android
Ver origem da regraandroid_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 de tempo de execução android.jar
do Android é implicitamente colocada no
caminho da classe de compilação.
Destinos de saída implícita
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. Não contém o fechamento transitivo.
Exemplos
Exemplos de regras do Android podem ser encontrados no diretório examples/android
da árvore de origem do Bazel.
O exemplo a seguir 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 esse destino. |
deps
|
android_library ,
java_library com restrição de android e
cc_library envolvendo ou produzindo bibliotecas nativas de .so
para a plataforma de destino Android.
|
srcs
|
.java ou .srcjar que são processados para criar o destino.
Os 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 nos outros pacotes, desde que todos estejam no diretório assets_dir no pacote correspondente.
|
assets_dir
|
assets .
O par assets e assets_dir descrevem os 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, você também precisa 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 uma dependência direta de qualquer regra que dependa diretamente do
destino com exports .
Os |
exports_manifest
|
android_binary destinos 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 de ID que dependem dessa biblioteca. Quando Veja exemplos. |
idl_parcelables
|
android_library que dependa dessa biblioteca, diretamente
ou pelo fechamento transitivo dela, mas não vão ser convertidos em Java
ou compilados.
Somente os arquivos Esses arquivos precisam ser colocados de forma adequada para que o compilador Aidl 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 pelo fechamento transitivo dela, mas não vão ser convertidos em Java
ou compilados.
Somente arquivos |
idl_srcs
|
srcs .
Esses arquivos vão ser disponibilizados como importações para qualquer
destino Esses arquivos precisam ser colocados de forma adequada para que o compilador Aidl 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 após as opções globais do compilador. |
manifest
|
AndroidManifest.xml .
Precisa ser definido se resource_files ou assets forem definidos.
|
neverlink
|
neverlink não serão usados na
criação de .apk . Útil se 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
o destino for criado. Os recursos gerados pelo
plug-in serão incluídos no jar de resultado do
destino.
|
proguard_specs
|
android_binary , dependendo desta biblioteca.
Os arquivos incluídos aqui precisam ter apenas regras idempotentes, como -dontnote, -dontwarn,
pressnosideeffects e regras que começam com -keep. Outras opções só podem aparecer no
proguard_specs de android_binary para garantir mesclagens não tautológicas.
|
resource_files
|
glob de todos os arquivos no
diretório res .
Aqui, os arquivos gerados (de regras gerais) também podem ser referenciados por Rótulo. A única restrição é que as saídas geradas precisam estar no mesmo diretório " res " de qualquer outro
arquivo de recursos incluído.
|
teste_de_instrumentação_android
Ver origem da regraandroid_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 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 a
android_binary
que contém o teste. Esse android_binary
especifica o aplicativo android_binary
em teste pelo
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 esse destino. |
support_apks
|
|
target_device
|
O android_device em que o teste precisa 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 usando
o atributo instruments .
|
teste_local_android
Ver origem da regraandroid_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 testes de unidade de regras android_library
localmente,
e não em um dispositivo.
Ele funciona com o framework de teste Android Robolectric.
Consulte o site do Android Robolectric para ver detalhes sobre
como programar testes do Robolectric.
Destinos de saída implícita
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 em 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 (link em inglês) ao arquivo WORKSPACE
:
http_archive( name = "robolectric", urls = ["https://github.com/robolectric/robolectric-bazel/archive/<COMMIT>.tar.gz"], strip_prefix = "robolectric-bazel-<COMMIT>", sha256 = "<HASH>", ) load("@robolectric//bazel:robolectric.bzl", "robolectric_repositories") robolectric_repositories()Isso extrai as regras
maven_jar
necessárias para o Robolectric.
Em seguida, cada regra android_local_test
depende de @robolectric//bazel:robolectric
. Veja o exemplo abaixo.
android_local_test( name = "SampleTest", srcs = [ "SampleTest.java", ], manifest = "LibManifest.xml", deps = [ ":sample_test_lib", "@robolectric//bazel:android-all", ], ) android_library( name = "sample_test_lib", srcs = [ "Lib.java", ], resource_files = glob(["res/**"]), manifest = "AndroidManifest.xml", )
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para esse destino. |
deps
|
A lista de regras permitidas em |
srcs
|
Os arquivos Arquivos Todos os outros arquivos são ignorados, desde que haja pelo menos um arquivo do tipo descrito acima. Caso contrário, um erro será 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 globais do compilador. |
jvm_flags
|
O script de wrapper de 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 de wrapper inclui o nome da
classe principal seguida de um Esse atributo não tem efeito nas saídas |
manifest
|
AndroidManifest.xml .
Precisa ser definido se resource_files ou assets forem definidos ou se um dos manifestos das
bibliotecas em teste tiver uma tag minSdkVersion .
|
manifest_values
|
applicationId , versionCode , versionName , minSdkVersion , targetSdkVersion e maxSdkVersion também substituirão os atributos correspondentes das tags "manifest" e "uses-sdk". packageName será ignorado e definido em applicationId , se especificado, ou no pacote no manifesto.
Não é necessário ter um manifesto na regra para usar manifest_values.
|
nocompress_extensions
|
|
plugins
|
java_plugin especificado nesse 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 de tempo de execução, mas ao contrário deles, não no caminho de classe de 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 destinos que aparecem em
runtime_deps e deps .
|
stamp
|
Os binários carimbados não são recriados, a menos que as dependências deles sejam alteradas. |
test_class
|
Esse atributo especifica o nome de uma classe Java a ser executada pelo
teste. É raro precisar ser configurado. Se esse argumento for omitido, a classe Java com o nome correspondente ao |
use_launcher
|
Se ele for definido como falso, o
atributo launcher e a sinalização
|
Dispositivo Android
Ver origem da regraandroid_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 um comando de execução do bazel ou executando diretamente o script gerado. É recomendável depender das regras android_device já existentes em vez de definir as suas.
Essa regra é adequada para a sinalização --run_under no teste bazel e na execução blaze. Ele inicia um emulador, copia o destino que está sendo testado/executado no emulador e o testa ou o executa conforme apropriado.
android_device
oferece suporte à criação de imagens KVM se a system_image subjacente for X86 e for 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ícita
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 e 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
Essa regra gerará imagens e um script de início. Você pode iniciar o emulador localmente executando 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 será a porta em que você vai emitir a conexão do adb.
- --emulator_port: a porta em que o console de gerenciamento de telnet do emulador será exposto.
- --enable_display: inicia o emulador com uma tela se for verdadeiro (o padrão é "false").
- --action: iniciar ou encerrar.
- --apks_to_install: uma lista de apks a serem instalados no emulador.
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para esse destino. |
cache
|
|
default_properties
|
|
horizontal_resolution
|
|
platform_apks
|
|
ram
|
|
screen_density
|
|
system_image
|
|
vertical_resolution
|
|
vm_heap
|
|
android_ndk_repository
Ver origem da regraandroid_ndk_repository(name, api_level, path, repo_mapping)
Configura o Bazel para usar um Android NDK com suporte à criação de destinos do Android com código nativo.
Essa implementação de android_ndk_repository
está sendo substituída por uma
implementação no Starlark. A compatibilidade com futuras versões do NDK, incluindo a versão 25 e mais recentes, vai ser
implementada na versão Starlark do android_ndk_repository
. Consulte
rules_android_ndk para saber a versão do
Starlark.
Observe que a criação para Android também exige 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á o Android NDK no $ANDROID_NDK_HOME
e detectará
o nível mais alto da API com suporte.
android_ndk_repository( name = "androidndk", path = "./android-ndk-r20", api_level = 24, )
O exemplo acima usará o Android NDK localizado no espaço de trabalho em
./android-ndk-r20
. Ele vai usar as bibliotecas de nível 24 da API ao compilar o código
JNI.
recursos da CPU
O Android NDK contém a biblioteca cpufeatures, que pode ser usada para detectar a CPU de um dispositivo no momento da execução. No exemplo a seguir, demonstramos como usar cpufeatures com 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 esse destino. |
api_level
|
|
path
|
$ANDROID_NDK_HOME .
É possível fazer o download do Android NDK no site para desenvolvedores Android . |
repo_mapping
|
Por exemplo, uma entrada |
android_sdk_repository
Ver origem da regraandroid_sdk_repository(name, api_level, build_tools_version, path, repo_mapping)
Configura o Bazel para usar um SDK do Android local e 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 seu arquivo WORKSPACE
e definir a variável de ambiente $ANDROID_HOME
como o caminho do SDK do Android. O Bazel usará o nível mais alto da API do Android e a versão das ferramentas de compilação instaladas no SDK do Android por padrão.
android_sdk_repository( name = "androidsdk", )
Para garantir a criação de versões, os atributos path
, api_level
e build_tools_version
podem ser definidos com 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 instaladas.
android_sdk_repository( name = "androidsdk", path = "./sdk", api_level = 19, build_tools_version = "25.0.0", )
O exemplo acima também usa um caminho relativo ao 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 for 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 de versões das bibliotecas comuns do Android, como as bibliotecas Support e AppCompat,
que são empacotados 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
Repositório de Suporte do Android, 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 esse destino. |
api_level
|
O nível da API usado para um build específico pode ser substituído pela sinalização
Para ver todos os |
build_tools_version
|
O Bazel requer ferramentas de compilação versão 30.0.0 ou posterior. |
path
|
$ANDROID_HOME .
É possível fazer o download do SDK Android no site para desenvolvedores Android. |
repo_mapping
|
Por exemplo, uma entrada |