Regras do Android

Informar um problema Conferir origem Noite · 7,3 · 7,2 · 7,1 · 7,0 · 6,5

Regras

• android_binary
• aar_import
• android_library
• android_instrumentation_test
• android_local_test
• android_device
• android_ndk_repository
• android_sdk_repository

android_binary

Conferir origem da regra

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 ProGuard name_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 no name_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	Nome; obrigatório Um nome exclusivo para o destino.
deps	Lista de rótulos o padrão é [] A lista de outras bibliotecas a serem vinculadas ao destino binário. Os tipos de biblioteca permitidos são: 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	Lista de rótulos o padrão é [] A lista de arquivos de origem processados para criar o destino. Arquivos srcs do tipo .java são compilados. Por uma questão de legibilidade, não é bom colocar o nome de um gerou o arquivo de origem .java para o srcs. Em vez disso, coloque o nome da regra dependente no srcs, conforme descritas abaixo. Arquivos srcs do tipo .srcjar foram descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos .java com uma genrule ou uma extensão de build).
assets	Lista de rótulos o padrão é [] A lista de recursos a serem empacotados. Geralmente é um 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	String; o padrão é "" A string que fornece o caminho para os arquivos em assets. Os pares assets e assets_dir descrevem itens do pacote recursos e ambos os atributos devem ser fornecidos ou nenhum deles.
crunch_png	Booleano; o padrão é True Faça o processamento de PNG (ou não). Isso não depende do processamento Nine-Patch, que está sempre feito. Essa é uma solução alternativa descontinuada para um bug do aapt que tem corrigidos no aapt2.
custom_package	String; o padrão é "" Pacote Java para o qual as fontes Java serão geradas. Por padrão, o pacote é inferido do diretório em que o arquivo BUILD é que contém a regra é. É possível especificar um pacote diferente, altamente desencorajado, pois pode introduzir conflitos de caminho de classe com outros bibliotecas que só serão detectadas no ambiente de execução.
debug_key	Rótulo o padrão é "@bazel_tools//tools/android:debug_keystore" Arquivo contendo o keystore de depuração a ser usado para assinar o APK de depuração. Normalmente, você não quiser usar uma chave diferente da chave padrão, portanto, esse atributo deve ser omitido. 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	Lista de rótulos o padrão é [] Lista de arquivos, keystores de depuração a serem usados para assinar o apk de depuração. Normalmente, você não quiser usar chaves diferentes da chave padrão, portanto, esse atributo deve ser omitido. 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	Rótulo o padrão é None Arquivo contendo a linhagem de assinatura de debug_signing_keys. Normalmente, você não quiser usar chaves diferentes da chave padrão, portanto, esse atributo deve ser omitido. AVISO: não use suas chaves de produção. Elas devem ser rigorosamente protegidos e não mantidos na árvore de origem.
densities	Lista de strings o padrão é [] Densidades a serem filtradas ao criar o APK. Isso eliminará os recursos drawable rasterizados que não seriam carregados por um dispositivo com as densidades de tela especificadas para reduzir o tamanho do APK. Uma tela compatível correspondente também será adicionada ao manifesto se ainda não contiver um superconjunto listagem.
dex_shards	Número inteiro o padrão é 1 Número de fragmentos que precisam ser decompostos. Isso torna a dexação muito mais rápida, em detrimento do tempo de instalação do aplicativo e da inicialização. O quanto maior o binário, mais fragmentos devem ser usados. 25 é um bom valor para começar está testando. 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	Lista de strings o padrão é [] Sinalizadores de linha de comando adicionais para a ferramenta dx ao gerar classes.dex. Sujeito à substituição "Make variables" e Tokenização de Bourne Shell.
enable_data_binding	Booleano; o padrão é False Se verdadeiro, esta regra processa dados de vinculação em recursos de layout incluídos na resource_files. Sem isso as expressões de vinculação de dados produzem falhas no build. Para criar um app Android com vinculação de dados, também é necessário fazer o seguinte: Define esse atributo para todas as regras do Android que dependem transitivamente dele. Isso ocorre porque os variáveis herdam as expressões de vinculação de dados da regra usando as fusão. Portanto, eles também precisam criar com vinculação de dados para analisar essas expressões. Adicionar uma entrada deps = para a biblioteca de ambiente de execução da vinculação de dados a todos os destinos que definem esse atributo. O local dessa biblioteca depende da configuração do depósito.
incremental_dexing	Número inteiro nonconfigurable; o padrão é -1 Forçar a criação do destino com ou sem dexação incremental, substituindo os padrões e --incremental_dexing.
instruments	Rótulo o padrão é None O destino android_binary para instrumentar. Se o atributo for definido, o android_binary será tratado como um teste aplicativo para testes de instrumentação. Um android_instrumentation_test destino pode especificar esse destino em sua test_app.
javacopts	Lista de strings o padrão é [] Opções extras do compilador para esse destino. Sujeito à substituição "Make variables" e Tokenização de Bourne Shell. Essas opções do compilador são transmitidas para javac após as opções do compilador global.
key_rotation_min_sdk	String; o padrão é "" Define a versão mínima da plataforma Android (nível da API) para a qual a assinatura rotacionada de um APK deve ser usada para produzir a assinatura do APK. A chave de assinatura original do APK será usado para todas as versões anteriores da plataforma.
main_dex_list	Rótulo o padrão é None Um arquivo de texto contém uma lista de nomes de arquivo de classe. As classes definidas por esses arquivos de classe são colocar no primário classes.dex. e.g.: android/support/multidex/MultiDex$V19.class android/support/multidex/MultiDex.class android/support/multidex/MultiDexApplication.class com/google/common/base/Objects.class Precisa ser usado com multidex="manual_main_dex".
main_dex_list_opts	Lista de strings o padrão é [] Opções de linha de comando a serem transmitidas para o principal builder de listas de dex. Use essa opção para afetar as classes incluídas na lista de dex principal.
main_dex_proguard_specs	Lista de rótulos o padrão é [] Arquivos a serem usados como especificações do Proguard para determinar as classes que precisam ser mantidas dex principal. Permitido apenas se o atributo multidex estiver definido como legacy.
manifest	Rótulo obrigatório É o nome do arquivo de manifesto do Android, normalmente AndroidManifest.xml. Precisa ser definido se resource_files ou assets estiverem definidos.
manifest_values	Dicionário: String -> String; o padrão é {} Um dicionário de valores a serem substituídos no manifesto. Qualquer instância de ${name} no manifesto será substituída pelo valor correspondente ao nome neste dicionário. applicationId, versionCode e versionName. minSdkVersion, targetSdkVersion e maxSdkVersion também vai substituir os atributos correspondentes no manifesto e uses-sdk. packageName será ignorado e definido como applicationId, se especificado, ou o pacote no manifesto. Quando manifest_merger é definido como legacy, apenas applicationId, versionCode e versionName vão ter efeito algum.
multidex	String; o padrão é "native" Define se o código será dividido em vários arquivos dex. Valores possíveis: native: divide o código em vários arquivos dex quando o limite do índice de 64K de dex for excedido. Supõe suporte à plataforma nativa para carregamento de classes multidex no tempo de execução. Esse recurso funciona apenas com o Android L e versões mais recentes. legacy: divide o código em vários arquivos dex quando o limite do índice de 64K de dex for excedido. Pressupõe que as classes multidex são carregadas pelo código do aplicativo (ou seja, não suporte a plataforma nativa). manual_main_dex: divide o código em vários arquivos dex quando o dex 64K o limite de índice for excedido. O conteúdo do arquivo dex principal precisa ser especificado por fornecer uma lista de classes em um arquivo de texto usando o main_dex_list. off: compila todo o código para um único arquivo dex, mesmo que exceda o limite de índice.
nocompress_extensions	Lista de strings o padrão é [] Uma lista de extensões de arquivo para deixar descompactada no apk.
package_id	Número inteiro o padrão é 0 ID do pacote a ser atribuído aos recursos neste binário. Consulte o argumento --package-id do AAPT2 para saber mais. Isso pode (e normalmente não é definida, o que resulta no valor padrão de 127 (0x7F).
plugins	Lista de rótulos o padrão é [] Plug-ins do compilador Java para executar no momento da compilação. A cada 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	Rótulo o padrão é None Arquivo a ser usado como mapeamento para o Proguard. Um arquivo de "palavras" separado por linha extrair ao renomear turmas e membros durante ofuscação.
proguard_apply_mapping	Rótulo o padrão é None Arquivo a ser usado como mapeamento para o Proguard. Um arquivo de mapeamento gerado pelo proguard_generate_mapping a ser reutilizado para aplicar o mesmo mapeamento a um novo build.
proguard_generate_mapping	Booleano; nonconfigurable; o padrão é False Define se o arquivo de mapeamento Proguard será gerado. O arquivo de mapeamento será gerado somente se 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 -dontobfuscate nem -printmapping.
proguard_specs	Lista de rótulos o padrão é [] Arquivos a serem usados como especificação do Proguard. Esse arquivo descreve o conjunto de especificações a serem usadas pelo Proguard.
resource_configuration_filters	Lista de strings o padrão é [] Uma lista de filtros de configuração de recursos, como "en" que limita os recursos use o apk apenas para aqueles em "en" configuração do Terraform. Para ativar a pseudolocalização, inclua o Pseudolocalidades en_XA e/ou ar_XB.
resource_files	Lista de rótulos o padrão é [] A lista de recursos a serem empacotados. Geralmente é um 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	Número inteiro o padrão é -1 Define se a redução de recursos será executada. Recursos que não forem usados pelo binário serão removido do APK. Isso só é permitido para regras que usam recursos locais (como o atributos 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: em values/ serão removidos, assim como os recursos recursos usa strict mode por padrão a remoção de recursos de ID não utilizados só é compatível com o aapt2 Se a redução de recursos estiver ativada, name_files/resource_shrinker.log também serão gerados, detalhando a análise e as exclusões realizadas. Valores possíveis: shrink_resources = 1: ativa a redução de recursos do Android shrink_resources = 0: desativa a redução de recursos do Android shrink_resources = -1: a redução é controlada pelo --android_resource_reduceing.

aar_import

Conferir origem da regra

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	Nome; obrigatório Um nome exclusivo para o destino.
aar	Rótulo obrigatório O arquivo .aar a ser fornecido aos destinos Android que dependem desse destino.
exports	Lista de rótulos o padrão é [] Destinos a serem exportados para regras que dependem desta regra. Consulte java_library.exports.
srcjar	Rótulo o padrão é None Um arquivo JAR que contém o código-fonte para os arquivos JAR compilados no AAR.

android_library

Conferir origem da regra

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	Nome; obrigatório Um nome exclusivo para o destino.
deps	Lista de rótulos o padrão é [] A lista de outras bibliotecas para vincular. Os tipos de biblioteca permitidos são: android_library, java_library com android restrição e cc_library unindo ou produzindo .so bibliotecas nativas para a plataforma de destino Android.
srcs	Lista de rótulos o padrão é [] A lista de arquivos .java ou .srcjar que são processados para criar o destino. Arquivos srcs do tipo .java são compilados. Por uma questão de legibilidade, não é bom colocar o nome de um gerou o arquivo de origem .java para o srcs. Em vez disso, coloque o nome da regra dependente no srcs, conforme descritas abaixo. Arquivos srcs do tipo .srcjar foram descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos .java com uma genrule ou uma extensão de build). Se srcs for omitido, qualquer dependência especificada em O arquivo deps é exportado desta regra (consulte exportações de java_library para mais informações sobre como exportar dependências). No entanto, esse comportamento será será descontinuado em breve; tente não confiar nisso.
assets	Lista de rótulos o padrão é [] A lista de recursos a serem empacotados. Geralmente é um 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	String; o padrão é "" A string que fornece o caminho para os arquivos em assets. Os pares assets e assets_dir descrevem itens do pacote recursos e ambos os atributos devem ser fornecidos ou nenhum deles.
custom_package	String; o padrão é "" Pacote Java para o qual as fontes Java serão geradas. Por padrão, o pacote é inferido do diretório em que o arquivo BUILD é que contém a regra é. É possível especificar um pacote diferente, altamente desencorajado, pois pode introduzir conflitos de caminho de classe com outros bibliotecas que só serão detectadas no ambiente de execução.
enable_data_binding	Booleano; o padrão é False Se verdadeiro, esta regra processa dados de vinculação em recursos de layout incluídos na resource_files. Sem isso as expressões de vinculação de dados produzem falhas no build. Para criar um app Android com vinculação de dados, também é necessário fazer o seguinte: Define esse atributo para todas as regras do Android que dependem transitivamente dele. Isso ocorre porque os variáveis herdam as expressões de vinculação de dados da regra usando as fusão. Portanto, eles também precisam criar com vinculação de dados para analisar essas expressões. Adicionar uma entrada deps = para a biblioteca de ambiente de execução da vinculação de dados a todos os destinos que definem esse atributo. O local dessa biblioteca depende da configuração do depósito.
exported_plugins	Lista de rótulos o padrão é [] A lista de java_plugins (por exemplo, de anotação processadores) para exportar para bibliotecas que dependem diretamente dessa biblioteca. A lista especificada de java_plugins será aplicada a qualquer biblioteca que depende diretamente dessa biblioteca, como se a biblioteca tivesse declarado explicitamente esses rótulos em plugins.
exports	Lista de rótulos o padrão é [] Fechamento de todas as regras alcançado pelos atributos exports são consideradas dependências diretas de qualquer regra que dependa diretamente da de destino com exports. Os exports não são dependências diretas da regra a que pertencem.
exports_manifest	Número inteiro o padrão é 1 Se as entradas do manifesto serão exportadas para destinos android_binary que dependem dessa meta. Os atributos uses-permissions nunca são exportados.
idl_import_root	String; o padrão é "" Caminho relativo ao pacote para a raiz da árvore de pacotes Java que contém idl de fontes de conhecimento incluídas nessa biblioteca. Esse caminho será usado como raiz de importação ao processar origens inativas que dependem dessa biblioteca. Quando idl_import_root é especificado, idl_parcelables e idl_srcs precisa estar no caminho especificado pelo pacote Java do objeto que eles representam em idl_import_root. Quando idl_import_root for não especificado, idl_parcelables e idl_srcs devem estar no especificado pelo pacote em uma raiz Java. Consulte exemplos.
idl_parcelables	Lista de rótulos o padrão é [] Lista de definições de IDL do Android para fornecer como importações. Esses arquivos serão disponibilizados como importações 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 .aidl que correspondam diretamente a É necessário incluir .java fontes nessa biblioteca (por exemplo, personalizadas implementações de Parcelable), caso contrário, idl_srcs será usados. 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	Lista de rótulos o padrão é [] Lista de definições de IDL pré-processadas do Android para fornecer como importações. Esses arquivos serão disponibilizados como importações 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 .aidl pré-processados que correspondam diretamente a É necessário incluir .java fontes nessa biblioteca (por exemplo, personalizadas implementações de Parcelable), caso contrário, use idl_srcs para Definições de IDL do Android que precisam ser traduzidas para interfaces Java e usar idl_parcelable para arquivos AIDL não pré-processados.
idl_srcs	Lista de rótulos o padrão é [] Lista de definições de IDL do Android para traduzir para interfaces Java. Depois que as interfaces Java forem geradas, elas serão compiladas juntas com o conteúdo de srcs. Esses arquivos serão disponibilizados como importações android_library destino que depende dessa biblioteca, diretamente ou por um fechamento transitivo. 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	Lista de strings o padrão é [] Opções extras do compilador para esse destino. Sujeito à substituição "Make variables" e Tokenização de Bourne Shell. Essas opções do compilador são transmitidas para javac após as opções do compilador global.
manifest	Rótulo o padrão é None É o nome do arquivo de manifesto do Android, normalmente AndroidManifest.xml. Precisa ser definido se resource_files ou assets estiverem definidos.
neverlink	Booleano; o padrão é False Use essa biblioteca apenas para compilação e não durante a execução. As saídas de uma regra marcada como neverlink não serão usadas em Criação de .apk. Útil se a biblioteca for fornecida pelo durante a execução.
plugins	Lista de rótulos o padrão é [] Plug-ins do compilador Java para executar no momento da compilação. A cada 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	Lista de rótulos o padrão é [] Arquivos a serem usados como especificação do Proguard. Elas vão descrever o conjunto de especificações a serem usadas pelo Proguard. Se especificado, ele vai ser adicionado a qualquer destino 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	Lista de rótulos o padrão é [] A lista de recursos a serem empacotados. Geralmente é um 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

Conferir origem da regra

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	Nome; obrigatório Um nome exclusivo para o destino.
support_apks	Lista de rótulos o padrão é [] Outros APKs para instalar no dispositivo antes do início do teste de instrumentação.
target_device	Rótulo obrigatório 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_output=streamed --test_arg=--device_broker_type=LOCAL_ADB_SERVER --test_arg=--device_serial_number=$device_identifier
test_app	Rótulo obrigatório O destino android_binary que contém as classes de teste. O destino android_binary precisa especificar qual destino está sendo testado ao atributo instruments.

android_local_test

Conferir origem da regra

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-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. 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:android-all",
    ],
)

android_library(
    name = "sample_test_lib",
    srcs = [
         "Lib.java",
    ],
    resource_files = glob(["res/**"]),
    manifest = "AndroidManifest.xml",
)

Argumentos

Atributos
name	Nome; obrigatório Um nome exclusivo para o destino.
deps	Lista de rótulos o padrão é [] A lista de bibliotecas a serem testadas, bem como as bibliotecas adicionais a serem vinculadas no destino. Todos os recursos, ativos e arquivos de manifesto declarados nas regras do Android na conjunção desse atributo são disponibilizadas no teste. A lista de regras permitidas em deps é android_library, aar_import, java_import e java_library. e java_lite_proto_library.
srcs	Lista de rótulos o padrão é [] A lista de arquivos de origem processados para criar o destino. Obrigatório, exceto no caso especial descrito abaixo. Arquivos srcs do tipo .java são compilados. Por uma questão de legibilidade, não é bom colocar o nome de um gerou o arquivo de origem .java para o srcs. Em vez disso, coloque o nome da regra dependente no srcs, conforme descritas abaixo. Arquivos srcs do tipo .srcjar foram descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos .java com uma genrule ou uma extensão de build). 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 srcs é obrigatório e não pode ficar em branco, a menos que runtime_deps é especificado.
custom_package	String; o padrão é "" O pacote Java em que a classe R será gerada. Por padrão, o pacote é inferido do diretório onde está o arquivo BUILD que contém a regra. Se você usar esse atributo, provavelmente também será necessário usar test_class.
densities	Lista de strings o padrão é [] Densidades a serem filtradas ao criar o APK. Uma tela compatível correspondente também será adicionada ao manifesto se ainda não contiver um superconjunto StarlarkListing.
enable_data_binding	Booleano; o padrão é False Se verdadeiro, esta regra processa dados de vinculação de dados usadas nas dependências com vinculação de dados ativada usadas por este teste. Sem essa configuração, as dependências de vinculação de dados não terão a geração necessária de código em nível binário, e pode produzir falhas de build.
javacopts	Lista de strings o padrão é [] Opções extras do compilador para essa biblioteca. Sujeito à substituição "Make variables" e Tokenização de Bourne Shell. Essas opções do compilador são transmitidas para javac após as opções do compilador global.
jvm_flags	Lista de strings o padrão é [] Uma lista de sinalizações a serem incorporadas no script de wrapper gerado para executar esse binário. Sujeito aos termos $(location) e Substituição "Make variables", e Tokenização de shell Bourne. 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 "$@" para que você possa transmitir outras após o classname. No entanto, os argumentos destinados à análise pela JVM deve ser especificado antes do nome da classe no comando linha O conteúdo de jvm_flags é adicionado ao wrapper. antes do nome da classe listado. Esse atributo não tem efeito em *_deploy.jar de entrada e saída.
manifest	Rótulo o padrão é None É o nome do arquivo de manifesto do Android, normalmente 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	Dicionário: String -> String; o padrão é {} Um dicionário de valores a serem substituídos no manifesto. Qualquer instância de ${name} na manifesto será substituído pelo valor correspondente ao nome neste dicionário. 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	Lista de strings o padrão é [] Uma lista de extensões de arquivo para deixar descompactadas no APK do recurso.
plugins	Lista de rótulos o padrão é [] Plug-ins do compilador Java para executar no momento da compilação. Cada 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	Lista de strings o padrão é [] Uma lista de filtros de configuração de recursos, como "en" que limita os recursos use o apk apenas para aqueles em "en" configuração do Terraform.
resource_jars	Lista de rótulos o padrão é [] Obsoleto: use java_import e deps ou runtime_deps.
resource_strip_prefix	String; o padrão é "" O prefixo do caminho a ser removido dos recursos Java. Se especificado, esse prefixo de caminho é removido de todos os arquivos no resources . É um erro se um arquivo de recurso não estiver nesse diretório. Caso contrário especificado (o padrão), o caminho do arquivo de recurso é determinado de acordo com o mesmo lógica de rede como o pacote Java de arquivos de origem. Por exemplo, um arquivo de origem stuff/java/foo/bar/a.txt estará localizado em foo/bar/a.txt.
runtime_deps	Lista de rótulos o padrão é [] Bibliotecas a serem disponibilizadas para o binário final ou para teste apenas no momento da execução. Como 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	Número inteiro o padrão é 0 Define se as informações da versão serão codificadas no binário. Valores possíveis: stamp = 1: sempre inclua as informações do build no binário, mesmo em --nostamp builds. Este deve ser evitada, já que ela pode eliminar o armazenamento em cache remoto dos binário e qualquer ação downstream que dependa dele. stamp = 0: sempre substitui as informações do build por valores constantes. Isso oferece um bom armazenamento em cache dos resultados da compilação. stamp = -1: a incorporação de informações do build é controlada pelo sinalização --[no]stamp. Os binários carimbos não são recriados, a menos que as dependências deles mudem.
test_class	String; o padrão é "" A classe Java a ser carregada pelo executor de testes. 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 name deste android_local_test regra será usada. A classe de teste precisa receber a anotação org.junit.runner.RunWith.
use_launcher	Booleano; o padrão é True Define se o binário precisa usar uma tela de início personalizada. Se este atributo for definido como falso, o atributo launcher e o relacionado Sinalização --java_launcher serão ignorados para esse destino.

android_device

Conferir origem da regra

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 emulador
• name_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	Nome; obrigatório Um nome exclusivo para o destino.
cache	Número inteiro obrigatório O tamanho em megabytes da partição de cache do emulador. O valor mínimo é 16 megabytes.
default_properties	Rótulo o padrão é None Um único arquivo de propriedades a ser colocado em /default.prop no emulador. Isso permite que o autor da regra configure ainda mais o emulador para que ele seja semelhante a um dispositivo real (especialmente controlando as strings do UserAgent e outros que pode fazer com que um aplicativo ou servidor se comporte de maneira diferente um dispositivo específico). As propriedades neste arquivo substituirão o recurso somente leitura propriedades normalmente definidas pelo emulador, como ro.product.model.
horizontal_resolution	Número inteiro obrigatório A resolução horizontal da tela em pixels a serem emulados. O valor mínimo é 240.
platform_apks	Lista de rótulos o padrão é [] Uma lista de APKs a serem instalados no dispositivo no momento da inicialização.
ram	Número inteiro obrigatório A quantidade de memória RAM em megabytes a ser emulada para o dispositivo. Isso vale para todo o dispositivo, não apenas para um app específico instalado nele. O o valor mínimo é 64 megabytes.
screen_density	Número inteiro obrigatório É a densidade da tela emulada em pixels por polegada. O valor mínimo é 30 ppi.
system_image	Rótulo obrigatório Um grupo de arquivos contendo os seguintes arquivos: system.img: a partição do sistema kernel-qemu: o kernel do Linux que o emulador vai carregar ramdisk.img: a imagem initrd a ser usada na inicialização userdata.img: a partição inicial userdata source.properties: um arquivo de propriedades que contém informações sobre a imagens Esses arquivos fazem parte do SDK do Android ou são fornecidos por terceiros (por exemplo da Intel oferece imagens x86).
vertical_resolution	Número inteiro obrigatório A resolução vertical da tela em pixels a serem emulados. O valor mínimo é 240.
vm_heap	Número inteiro obrigatório O tamanho em megabytes da heap da máquina virtual que o Android usará para cada processo. O valor mínimo é 16 megabytes.

android_ndk_repository

Conferir origem da regra

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.

Essa implementação de android_ndk_repository está sendo substituída por uma implementação no Starlark. O suporte para versões futuras do NDK, incluindo a versão 25 e mais recentes, ser implementado na versão Starlark do android_ndk_repository. Consulte rules_android_ndk para o Starlark para a versão anterior.

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	Nome; obrigatório Um nome exclusivo para o destino.
api_level	Número inteiro nonconfigurable; o padrão é 0 O nível da API do Android em que o build será usado. Se não for especificado, o nível mais alto da API instalado será usado.
path	String; nonconfigurable; o padrão é "" Um caminho absoluto ou relativo para um Android NDK. Esse atributo ou o A variável de ambiente $ANDROID_NDK_HOME precisa ser definida. O Android NDK pode ser baixado em o site do desenvolvedor Android
repo_mapping	Dicionário: String -> String; o padrão é {} Um dicionário do nome do repositório local para o nome do repositório global. Isso permite controles resolução de dependência do espaço de trabalho para dependências deste repositório. Por exemplo, uma entrada "@foo": "@bar" declara que, para qualquer momento que esse repositório depende de "@foo" (como uma dependência do "@foo//some:target"), ele vai resolver essa dependência declaração global de "@bar" ("@bar//some:target").

android_sdk_repository

Conferir origem da regra

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 regra android_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	Nome; obrigatório Um nome exclusivo para o destino.
api_level	Número inteiro nonconfigurable; o padrão é 0 O nível da API do Android para compilação por padrão. Se não for especificado, o nível mais alto da API instalada será usada. O nível da API usado para um determinado build pode ser substituído pelo android_sdk. . android_sdk_repository cria um destino android_sdk para cada nível de API instalado no SDK com o nome @androidsdk//:sdk-${level}; se esse atributo é especificado ou não. Por exemplo, para criar com base em uma API não padrão nível: bazel build --android_sdk=@androidsdk//:sdk-19 //java/com/example:app. Para conferir todos os destinos android_sdk gerados por android_sdk_repository , execute bazel query "kind(android_sdk, @androidsdk//...)".
build_tools_version	String; nonconfigurable; o padrão é "" A versão das ferramentas de compilação do Android a ser usada no SDK do Android. Se não for especificado, a versão mais recente das ferramentas de build instalada será usada. O Bazel exige a versão 30.0.0 ou mais recente das ferramentas de build.
path	String; nonconfigurable; o padrão é "" Um caminho absoluto ou relativo para um SDK do Android. Esse atributo ou o A variável de ambiente $ANDROID_HOME precisa ser definida. Baixe o SDK do Android em site para desenvolvedores Android.
repo_mapping	Dicionário: String -> String; o padrão é {} Um dicionário do nome do repositório local para o nome do repositório global. Isso permite controles resolução de dependência do espaço de trabalho para dependências deste repositório. Por exemplo, uma entrada "@foo": "@bar" declara que, para qualquer momento que esse repositório depende de "@foo" (como uma dependência do "@foo//some:target"), ele vai resolver essa dependência declaração global de "@bar" ("@bar//some:target").