Esta página foi traduzida pela API Cloud Translation.

Regras do Android

Informar um problema Ver código-fonte {19/Night} {19/Night}

Regras

android_binary

aar_import

android_library

android_instrumentation_test

android_local_test

android_device

android_ndk_repository

android_sdk_repository

android_binary
Exibir 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 arquivo de pacote de aplicativo Android assinado com chaves de depuração e zipaligned (em inglês). Ele pode ser usado para desenvolver e depurar seu app. 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 do arquivo acima que pode ser assinada com as chaves de lançamento antes do lançamento para o público.

name_deploy.jar: um arquivo Java que contém o fechamento transitivo desse destino.
O jar de implantação contém todas as classes que seriam encontradas por um carregador de classe que pesquisou o caminho de classe do ambiente de execução desse destino do início ao fim.

name_proguard.jar: um arquivo Java contendo o resultado da execução do ProGuard no name_deploy.jar. Essa saída só será produzida se o atributo proguard_specs for especificado.

name_proguard.map: um resultado do arquivo de mapeamento da execução do ProGuard no name_deploy.jar. Essa saída só será produzida se o atributo proguard_specs for especificado e proguard_generate_mapping ou shrink_resources estiver definido.

Exemplos

Exemplos de regras do Android podem ser encontrados no diretório examples/android da á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 restrição android e cc_library unindo ou produzindo bibliotecas nativas .so para a 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 arquivo de origem .java gerado no srcs. Em vez disso, coloque o nome da regra dependente em srcs, conforme descrito abaixo.

Arquivos srcs do tipo .srcjar são descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos .java com uma extensão de genrule ou de build.)

assets
Lista de rótulos. O padrão é [].
A lista de recursos a serem empacotados. Geralmente, é um glob de todos os arquivos no diretório assets. Também é possível referenciar outras regras (qualquer regra que produza arquivos) ou arquivos exportados em outros pacotes, desde que todos esses arquivos estejam no diretório assets_dir no pacote correspondente.

assets_dir
String. O padrão é "".
A string que fornece o caminho para os arquivos em assets. O par assets e assets_dir descrevem recursos empacotados, e um dos dois atributos precisa ser fornecido 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 do Nine-Patch, que é sempre feito. Esta é uma solução alternativa descontinuada para um bug do aapt que foi corrigido 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 está o arquivo BUILD que contém a regra. É possível especificar um pacote diferente, mas isso não é recomendado, porque pode introduzir conflitos de caminho de classe com outras 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, o ideal é usar uma chave diferente da padrão, portanto, esse atributo precisa ser omitido.
AVISO: não use suas chaves de produção. Elas precisam ser estritamente protegidas e não mantidas 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, não é recomendável usar chaves diferentes da chave padrão, portanto, esse atributo precisa ser omitido.
AVISO: não use suas chaves de produção. Elas precisam ser estritamente protegidas e não mantidas 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, não é recomendável usar chaves diferentes da chave padrão, portanto, esse atributo precisa ser omitido.
AVISO: não use suas chaves de produção. Elas precisam ser estritamente protegidas e não mantidas na árvore de origem.

densities
Lista de strings. O padrão é [].
Densidades a serem filtradas ao criar o APK. Isso remove 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 seção correspondente de telas compatíveis também será adicionada ao manifesto se ainda não tiver uma listagem de superconjuntos.

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. Quanto maior o binário, mais fragmentos precisam ser usados. 25 é um bom valor para começar a fazer experimentos.
Observe que cada fragmento resultará em pelo menos um dex no app final. Por esse motivo, não é recomendável definir esse valor como mais de 1 para binários de lançamento.

dexopts
Lista de strings. O padrão é [].
Sinalizadores de linha de comando adicionais para a ferramenta dx ao gerar classes.dex. Sujeito à substituição de "Make variables" e à tokenização de shell Bourne.

enable_data_binding
Booleano. O padrão é False.
Se for verdadeira, essa regra processará expressões de vinculação de dados em recursos de layout incluídos por meio do atributo resource_files. Sem essa configuração, as expressões de vinculação de dados produzem falhas de 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 dependentes herdam as expressões de vinculação de dados da regra pela mesclagem de recursos. Portanto, eles também precisam criar com vinculação de dados para analisar essas expressões.
Adicione uma entrada deps = para a biblioteca de execução de 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; não configurável; o padrão é -1
Força a compilação do destino com ou sem dexação incremental, substituindo os padrões e a sinalização --incremental_dexing.

instruments
Rótulo; o padrão é None

O destino android_binary para instrumentar.

Se esse atributo for definido, esse android_binary será tratado como um aplicativo de teste de instrumentação. Um destino android_instrumentation_test pode especificar esse destino no atributo test_app.

javacopts
Lista de strings. O padrão é [].
Opções extras do compilador para esse destino. Sujeito à substituição de "Make variables" e à tokenização de shell Bourne.
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 de API) em que a chave de assinatura alternada de um APK precisa ser usada para produzir a assinatura do APK. A chave de assinatura original do APK será usada em 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 colocadas em classes primárias.dex. Por exemplo:
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 no dex principal. Permitido apenas se o atributo multidex estiver definido como legacy.

manifest
Label, 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, versionName, minSdkVersion, targetSdkVersion e maxSdkVersion também vão substituir os atributos correspondentes no manifesto e nas tags uses-sdk.
packageName será ignorado e definido usando applicationId, se especificado, ou do pacote no manifesto.
Quando manifest_merger for definido como legacy, apenas applicationId, versionCode e versionName terão algum efeito.

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 de índice de 64 K é 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 de índice de 64 K é excedido. Pressupõe que as classes multidex são carregadas pelo código do app (ou seja, não são compatíveis com a plataforma nativa).

manual_main_dex: divide o código em vários arquivos dex quando o limite do índice de 64 K é excedido. O conteúdo do arquivo dex principal precisa ser especificado fornecendo uma lista de classes em um arquivo de texto usando o atributo main_dex_list.

off: compila todo o código em um único arquivo dex, mesmo que ele exceda o limite do í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 precisa) ser deixado sem definição, resultando 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. Cada java_plugin especificado no atributo de plug-ins será executado sempre que esse destino for criado. Os recursos gerados pelo plug-in serão incluídos no jar de resultados do destino.

proguard_apply_dictionary
Rótulo; o padrão é None
Arquivo a ser usado como mapeamento para o Proguard. Um arquivo separado por linhas de "palavras" que será extraída ao renomear classes e membros durante a 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 por proguard_generate_mapping a ser reutilizado para aplicar o mesmo mapeamento a um novo build.

proguard_generate_mapping
Booleano; não configurável; 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 lista o mapeamento entre os nomes originais e ofuscados das classes, dos métodos e dos campos.
AVISO: se esse atributo for usado, a especificação do Proguard não poderá 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 no apk apenas àqueles na configuração "en". Para ativar a pseudolocalização, inclua as 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 no diretório res.
Os arquivos gerados (das regras gerais) também podem ser referenciados pelo Label aqui. A única restrição é que as saídas geradas precisam estar no mesmo diretório "res" que qualquer outro arquivo de recursos incluído.

shrink_resources
Número inteiro. O padrão é -1.
Define se a redução de recursos será executada. Recursos que não são usados pelo binário serão removidos do APK. Isso só é compatível com regras que usam recursos locais (ou seja, os atributos manifest e resource_files) e exige o ProGuard. Ele funciona praticamente da mesma maneira que o redutor de recursos do Gradle (https://developer.android.com/studio/build/Pesquisa-code.html#reduce-resources).
Diferenças significativas:

Os recursos em values/ serão removidos, assim como os recursos baseados em arquivos

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á gerado, 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 pela sinalização --android_resource_ Acessar.

aar_import
Exibir 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 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
Nome, obrigatório

Um nome exclusivo para o destino.

aar
Label, 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
Exibir 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 android.jar do Android Runtime é colocada implicitamente no caminho da classe de compilação.

Destinos de saída implícitos

libname.jar: um arquivo Java.

libname-src.jar: um arquivo que contém as origens ("jar de origem").

name.aar: um pacote "aar" do Android contendo o arquivo Java e os recursos do destino. Ele 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 abaixo 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 restrição android e cc_library unindo ou produzindo bibliotecas nativas .so para a plataforma de destino do 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 arquivo de origem .java gerado no srcs. Em vez disso, coloque o nome da regra dependente em srcs, conforme descrito abaixo.

Arquivos srcs do tipo .srcjar são descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos .java com uma extensão de genrule ou de build.)

Se srcs for omitido, qualquer dependência especificada em deps será exportada dessa regra. Consulte Exportações de java_library para mais informações sobre como exportar dependências. No entanto, esse comportamento será suspenso em breve. Não confie nele.

assets
Lista de rótulos. O padrão é [].
A lista de recursos a serem empacotados. Geralmente, é um glob de todos os arquivos no diretório assets. Também é possível referenciar outras regras (qualquer regra que produza arquivos) ou arquivos exportados em outros pacotes, desde que todos esses arquivos estejam no diretório assets_dir no pacote correspondente.

assets_dir
String. O padrão é "".
A string que fornece o caminho para os arquivos em assets. O par assets e assets_dir descrevem recursos empacotados, e um dos dois atributos precisa ser fornecido 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 está o arquivo BUILD que contém a regra. É possível especificar um pacote diferente, mas isso não é recomendado, porque pode introduzir conflitos de caminho de classe com outras bibliotecas que só serão detectadas no ambiente de execução.

enable_data_binding
Booleano. O padrão é False.
Se for verdadeira, essa regra processará expressões de vinculação de dados em recursos de layout incluídos por meio do atributo resource_files. Sem essa configuração, as expressões de vinculação de dados produzem falhas de 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 dependentes herdam as expressões de vinculação de dados da regra pela mesclagem de recursos. Portanto, eles também precisam criar com vinculação de dados para analisar essas expressões.
Adicione uma entrada deps = para a biblioteca de execução de 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, processadores de anotações) para exportar para bibliotecas que dependem diretamente dessa biblioteca.
A lista especificada de java_plugins será aplicada a qualquer biblioteca que dependa diretamente dessa biblioteca, como se essa biblioteca tivesse declarado explicitamente esses rótulos em plugins.

exports
Lista de rótulos. O padrão é [].
O fechamento de todas as regras alcançadas pelos atributos exports são considerados dependências diretas de qualquer regra que depende diretamente do 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.
Define se as entradas do manifesto serão exportadas para destinos android_binary que dependem desse destino. 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 as origens idl incluídas nesta 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 precisam estar no caminho especificado pelo pacote Java do objeto que representam em idl_import_root. Quando idl_import_root não é especificado, idl_parcelables e idl_srcs precisam estar no caminho especificado pelo pacote em uma raiz Java.

Confira 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 para qualquer destino android_library que dependa dessa biblioteca, diretamente ou por meio do fechamento transitivo, mas não serão traduzidos para Java nem compilados.
Somente arquivos .aidl que correspondem diretamente a fontes .java nessa biblioteca precisam ser incluídos (por exemplo, implementações personalizadas de Parcelable). Caso contrário, idl_srcs precisa ser usado.

Esses arquivos devem ser colocados de forma apropriada para que o compilador AID os encontre. Consulte a descrição de idl_import_root para mais informações sobre 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 para qualquer destino android_library que dependa dessa biblioteca, diretamente ou por meio do fechamento transitivo, mas não serão traduzidos para Java nem compilados.
Somente arquivos .aidl pré-processados que correspondem diretamente a origens .java nesta biblioteca precisam ser incluídos (por exemplo, implementações personalizadas de Parcelable). Caso contrário, use idl_srcs para definições de IDL do Android que precisam ser traduzidas para interfaces Java e use 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 com o conteúdo de srcs.
Esses arquivos serão disponibilizados como importações para qualquer destino android_library que dependa dessa biblioteca, diretamente ou por meio do fechamento transitivo.

Esses arquivos devem ser colocados de forma apropriada para que o compilador AID os encontre. Consulte a descrição de idl_import_root para mais informações sobre o que isso significa.

javacopts
Lista de strings. O padrão é [].
Opções extras do compilador para esse destino. Sujeito à substituição de "Make variables" e à tokenização de shell Bourne.
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. Os resultados de uma regra marcada como 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
Lista de rótulos. O padrão é [].
Plug-ins do compilador Java para executar no momento da compilação. Cada java_plugin especificado no atributo de plug-ins será executado sempre que esse destino for criado. Os recursos gerados pelo plug-in serão incluídos no jar de resultados do destino.

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, eles serão adicionados a qualquer destino android_binary, dependendo dessa biblioteca. Os arquivos incluídos aqui só podem ter regras idempotentes, como -dontnote, -dontwarn, assumenosideeffectives e regras que começam com -keep. Outras opções só podem aparecer em proguard_specs de android_binary para garantir mesclagens 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 no diretório res.
Os arquivos gerados (das regras gerais) também podem ser referenciados pelo Label aqui. A única restrição é que as saídas geradas precisam estar no mesmo diretório "res" que qualquer outro arquivo de recursos incluído.

android_instrumentation_test
Exibir 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 iniciará um emulador, instalará o aplicativo que está sendo testado, o aplicativo de teste e todos os outros aplicativos necessários e executará os testes definidos no pacote de teste.

O atributo test_app especifica o android_binary que contém o teste. Esse android_binary, por sua vez, especifica o aplicativo android_binary em teste usando o 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
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
Label, 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
Label, obrigatório
O destino android_binary que contém as classes de teste. O destino android_binary precisa especificar o destino que está sendo testado por meio do atributo instruments.

android_local_test
Exibir 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 regras de teste de unidade android_library localmente, e não em um dispositivo. Ele funciona com o framework de testes Robolectric do Android. Consulte o site do Android Robolectric para ver detalhes sobre como escrever testes do Robolectric.

Destinos de saída implícitos

name.jar: um arquivo Java do teste.

name-src.jar: um arquivo que contém as origens ("jar de origem").

name_deploy.jar: um arquivo de implantação Java adequado para implantação (criado apenas se explicitamente solicitado).

Exemplos

Para usar o Robolectric com o android_local_test, adicione o repositório do Robolectric 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 de @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 ao destino. Todos os recursos, ativos e arquivos de manifesto declarados nas regras do Android no fechamento transitivo desse atributo são disponibilizados no teste.
A lista de regras permitidas em deps é android_library, aar_import, java_import, 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 arquivo de origem .java gerado no srcs. Em vez disso, coloque o nome da regra dependente em srcs, conforme descrito abaixo.

Arquivos srcs do tipo .srcjar são descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos .java com uma extensão de genrule ou de build.)

Todos os outros arquivos serão ignorados, desde que haja pelo menos um arquivo do tipo descrito acima. Caso contrário, um erro será gerado.

O atributo srcs é obrigatório e não pode ficar vazio, a menos que runtime_deps seja 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 em que está o arquivo BUILD que contém a regra. Se você usar esse atributo, provavelmente também precisará usar test_class.

densities
Lista de strings. O padrão é [].
Densidades a serem filtradas ao criar o APK. Uma seção correspondente de telas compatíveis também será adicionada ao manifesto se ainda não contiver um superconjunto StarlarkListing.

enable_data_binding
Booleano. O padrão é False.
Se verdadeira, essa regra processa referências de vinculação de dados usadas nas dependências ativadas pela vinculação de dados 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 no nível binário e podem produzir falhas de build.

javacopts
Lista de strings. O padrão é [].
Opções extras do compilador para essa biblioteca. Sujeito à substituição de "Make variables" e à tokenização de shell Bourne.
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 à substituição $(location) e "Make variables" e à tokenização do shell Bourne.
O script de wrapper de um binário Java inclui uma definição 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 seguido por um "$@" para que você possa transmitir outros argumentos após o nome da classe. No entanto, os argumentos destinados à análise pela JVM precisam ser especificados antes do nome da classe na linha de comando. O conteúdo de jvm_flags é adicionado ao script do wrapper antes que o nome da classe seja listado.

Esse atributo não tem efeito nas saídas *_deploy.jar.

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 forem definidos ou se algum dos manifestos das bibliotecas em teste tiver 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} no manifesto será substituída pelo valor correspondente ao nome neste dicionário. 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 pelo applicationId, se especificado, ou pelo 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 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
Lista de strings. O padrão é [].
Uma lista de filtros de configuração de recursos, como "en", que limita os recursos no apk apenas aos que estão na configuração "en".

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 será removido de todos os arquivos no atributo resources. É um erro se um arquivo de recurso não estiver nesse diretório. Se não for especificado (o padrão), o caminho do arquivo de recursos será determinado de acordo com a mesma lógica do pacote Java de arquivos de origem. Por exemplo, um arquivo de origem em 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 serão exibidos no caminho de classe do tempo de execução, mas, ao contrário deles, não no caminho de classe do tempo de compilação. As dependências necessárias apenas no tempo de execução são listadas aqui. As ferramentas de análise de dependência precisam ignorar os destinos que aparecem em 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 inclui as informações do build no binário, mesmo em builds --nostamp. Evite essa configuração, já que ela possivelmente elimina o armazenamento em cache remoto do binário e qualquer ação downstream que dependa dele.

stamp = 0: sempre substitui as informações do build por valores constantes. Isso fornece um bom armazenamento em cache dos resultados da compilação.

stamp = -1: a incorporação de informações do build é controlada pela flag --[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.

Esse atributo especifica o nome de uma classe Java a ser executada por esse teste. É raro precisar definir isso. Se esse argumento for omitido, será usada a classe Java cujo nome corresponde ao name da regra android_local_test. 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 o atributo for definido como "false", o atributo launcher e a sinalização --java_launcher relacionada serão ignorados para esse destino.

android_device
Exibir 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 as especificações fornecidas. Esse emulador pode ser iniciado por um comando do Bazel ou pela execução direta do script gerado. É recomendável depender das regras existentes do android_device em vez de definir suas próprias regras.

Essa regra é um destino adequado para a sinalização --run_under para testar o Bazel e executar o blaze. Ele inicia um emulador, copia o destino que está sendo testado/executado para o emulador e o testa ou o executa conforme apropriado.

android_device oferece suporte à criação de imagens KVM se a system_image subjacente é baseada em X86 e está otimizada, no máximo, para a arquitetura de CPU I686. Para usar a KVM, adicione tags = ['requires-kvm'] à regra android_device.

Destinos de saída implícitos

name_images/userdata.dat: contém arquivos de imagem e snapshots para iniciar o emulador

name_images/emulator-meta-data.pb: contém informações serializadas necessárias para reiniciá-lo no emulador.

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. Para iniciar o emulador localmente, execute bazel run :nexus_s -- --action=start. O script expõe as seguintes sinalizações:

--adb_port: a porta em que o adb será exposto. Se você quiser emitir comandos do adb para o emulador, essa é a porta em que você 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 "true" (o padrão é "false").

--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 se pareça mais como um dispositivo real, em especial, controlando as strings do user agent e outros comportamentos que podem fazer com que um aplicativo ou servidor se comporte de maneira diferente de um dispositivo específico. As propriedades nesse arquivo substituirão as propriedades somente leitura 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 valor mínimo é de 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
Label, 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 as imagens

Esses arquivos fazem parte do SDK do Android ou são fornecidos por terceiros (por exemplo, a 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
Exibir origem da regra
android_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 do android_ndk_repository está sendo substituída por uma implementação no Starlark. O suporte a versões futuras do NDK, incluindo a versão 25 e mais recentes, vai ser implementado na versão Starlark de android_ndk_repository. Consulte rules_android_ndk para ver a versão do Starlark.
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 vai localizar seu Android NDK em $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 vai usar o Android NDK localizado no espaço de trabalho em ./android-ndk-r20. Ele usará as bibliotecas da API de nível 24 ao compilar o código JNI.
cpufeatures

O Android NDK contém a biblioteca cpufeatures, que pode ser usada 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; não configurável; o padrão é 0
O nível da API do Android em que o build será usado. Se não for especificado, será usado o nível mais alto da API instalado.

path
String; não configurável; o padrão é ""
Um caminho absoluto ou relativo para um Android NDK. É preciso definir esse atributo ou a variável de ambiente $ANDROID_NDK_HOME.
É possível fazer o download do Android NDK no 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 sobre a resolução de dependências do espaço de trabalho para dependências deste repositório.
Por exemplo, uma entrada "@foo": "@bar" declara que, sempre que esse repositório depender de "@foo" (como uma dependência de "@foo//some:target"), ele precisará resolver essa dependência no "@bar" declarado globalmente ("@bar//some:target").

android_sdk_repository
Exibir 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 chamada "androidsdk" no arquivo WORKSPACE e definir a variável de ambiente $ANDROID_HOME como o caminho do SDK do Android. Por padrão, 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.
android_sdk_repository( name = "androidsdk", )

Para garantir builds reproduzíveis, os atributos path, api_level e build_tools_version podem ser definidos para valores específicos. O build falhará se o SDK do Android não tiver o nível da API especificado ou a versão das ferramentas de build instalada.
android_sdk_repository( name = "androidsdk", path = "./sdk", api_level = 19, build_tools_version = "25.0.0", )

O exemplo acima também demonstra o uso de um caminho relativo 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 ele faz check-in 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". Este é um conjunto com controle de versões de bibliotecas comuns do Android, como as bibliotecas Support e AppCompat, empacotado 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, formatadas como @androidsdk//${group}:${artifact}-${version}. O exemplo a seguir mostra como um android_library pode depender da versão 25.0.0 da 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; não configurável; o padrão é 0
O nível da API do Android para compilação por padrão. Se não for especificado, será usado o nível de API mais alto instalado.
O nível da API usado para um determinado build pode ser substituído pela sinalização 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}, independente desse atributo estar especificado ou não. Por exemplo, para criar em um nível de API não padrão: 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; não configurável; o padrão é ""
A versão das ferramentas de compilação do Android a ser usada no SDK do Android. Se não for especificada, 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; não configurável; o padrão é ""
Um caminho absoluto ou relativo para um SDK do Android. É preciso definir esse atributo ou a variável de ambiente $ANDROID_HOME.
O download do SDK do Android pode ser feito no site para desenvolvedores do 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 sobre a resolução de dependências do espaço de trabalho para dependências deste repositório.
Por exemplo, uma entrada "@foo": "@bar" declara que, sempre que esse repositório depender de "@foo" (como uma dependência de "@foo//some:target"), ele precisará resolver essa dependência no "@bar" declarado globalmente ("@bar//some:target").

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 restrição `android` e `cc_library` unindo ou produzindo bibliotecas nativas `.so` para a 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 arquivo de origem `.java` gerado no `srcs`. Em vez disso, coloque o nome da regra dependente em `srcs`, conforme descrito abaixo. Arquivos `srcs` do tipo `.srcjar` são descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos .java com uma extensão de genrule ou de build.)
`assets`	Lista de rótulos. O padrão é `[]`. A lista de recursos a serem empacotados. Geralmente, é um `glob` de todos os arquivos no diretório `assets`. Também é possível referenciar outras regras (qualquer regra que produza arquivos) ou arquivos exportados em outros pacotes, desde que todos esses arquivos estejam no diretório `assets_dir` no pacote correspondente.
`assets_dir`	String. O padrão é `""`. A string que fornece o caminho para os arquivos em `assets`. O par `assets` e `assets_dir` descrevem recursos empacotados, e um dos dois atributos precisa ser fornecido 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 do Nine-Patch, que é sempre feito. Esta é uma solução alternativa descontinuada para um bug do aapt que foi corrigido 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 está o arquivo BUILD que contém a regra. É possível especificar um pacote diferente, mas isso não é recomendado, porque pode introduzir conflitos de caminho de classe com outras 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, o ideal é usar uma chave diferente da padrão, portanto, esse atributo precisa ser omitido. AVISO: não use suas chaves de produção. Elas precisam ser estritamente protegidas e não mantidas 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, não é recomendável usar chaves diferentes da chave padrão, portanto, esse atributo precisa ser omitido. AVISO: não use suas chaves de produção. Elas precisam ser estritamente protegidas e não mantidas 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, não é recomendável usar chaves diferentes da chave padrão, portanto, esse atributo precisa ser omitido. AVISO: não use suas chaves de produção. Elas precisam ser estritamente protegidas e não mantidas na árvore de origem.
`densities`	Lista de strings. O padrão é `[]`. Densidades a serem filtradas ao criar o APK. Isso remove 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 seção correspondente de telas compatíveis também será adicionada ao manifesto se ainda não tiver uma listagem de superconjuntos.
`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. Quanto maior o binário, mais fragmentos precisam ser usados. 25 é um bom valor para começar a fazer experimentos. Observe que cada fragmento resultará em pelo menos um dex no app final. Por esse motivo, não é recomendável definir esse valor como mais de 1 para binários de lançamento.
`dexopts`	Lista de strings. O padrão é `[]`. Sinalizadores de linha de comando adicionais para a ferramenta dx ao gerar classes.dex. Sujeito à substituição de "Make variables" e à tokenização de shell Bourne.
`enable_data_binding`	Booleano. O padrão é `False`. Se for verdadeira, essa regra processará expressões de vinculação de dados em recursos de layout incluídos por meio do atributo resource_files. Sem essa configuração, as expressões de vinculação de dados produzem falhas de 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 dependentes herdam as expressões de vinculação de dados da regra pela mesclagem de recursos. Portanto, eles também precisam criar com vinculação de dados para analisar essas expressões. Adicione uma entrada `deps =` para a biblioteca de execução de 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; não configurável; o padrão é `-1` Força a compilação do destino com ou sem dexação incremental, substituindo os padrões e a sinalização --incremental_dexing.
`instruments`	Rótulo; o padrão é `None` O destino `android_binary` para instrumentar. Se esse atributo for definido, esse `android_binary` será tratado como um aplicativo de teste de instrumentação. Um destino `android_instrumentation_test` pode especificar esse destino no atributo test_app.
`javacopts`	Lista de strings. O padrão é `[]`. Opções extras do compilador para esse destino. Sujeito à substituição de "Make variables" e à tokenização de shell Bourne. 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 de API) em que a chave de assinatura alternada de um APK precisa ser usada para produzir a assinatura do APK. A chave de assinatura original do APK será usada em 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 colocadas em classes primárias.dex. Por exemplo: 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 no dex principal. Permitido apenas se o atributo `multidex` estiver definido como `legacy`.
`manifest`	Label, 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`, `versionName`, `minSdkVersion`, `targetSdkVersion` e `maxSdkVersion` também vão substituir os atributos correspondentes no manifesto e nas tags `uses-sdk`. `packageName` será ignorado e definido usando `applicationId`, se especificado, ou do pacote no manifesto. Quando `manifest_merger` for definido como `legacy`, apenas `applicationId`, `versionCode` e `versionName` terão algum efeito.
`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 de índice de 64 K é 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 de índice de 64 K é excedido. Pressupõe que as classes multidex são carregadas pelo código do app (ou seja, não são compatíveis com a plataforma nativa). `manual_main_dex`: divide o código em vários arquivos dex quando o limite do índice de 64 K é excedido. O conteúdo do arquivo dex principal precisa ser especificado fornecendo uma lista de classes em um arquivo de texto usando o atributo main_dex_list. `off`: compila todo o código em um único arquivo dex, mesmo que ele exceda o limite do í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 precisa) ser deixado sem definição, resultando 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. Cada `java_plugin` especificado no atributo de plug-ins será executado sempre que esse destino for criado. Os recursos gerados pelo plug-in serão incluídos no jar de resultados do destino.
`proguard_apply_dictionary`	Rótulo; o padrão é `None` Arquivo a ser usado como mapeamento para o Proguard. Um arquivo separado por linhas de "palavras" que será extraída ao renomear classes e membros durante a 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 por `proguard_generate_mapping` a ser reutilizado para aplicar o mesmo mapeamento a um novo build.
`proguard_generate_mapping`	Booleano; não configurável; 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 lista o mapeamento entre os nomes originais e ofuscados das classes, dos métodos e dos campos. AVISO: se esse atributo for usado, a especificação do Proguard não poderá 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 no apk apenas àqueles na configuração "en". Para ativar a pseudolocalização, inclua as 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 no diretório `res`. Os arquivos gerados (das regras gerais) também podem ser referenciados pelo Label aqui. A única restrição é que as saídas geradas precisam estar no mesmo diretório "`res`" que qualquer outro arquivo de recursos incluído.
`shrink_resources`	Número inteiro. O padrão é `-1`. Define se a redução de recursos será executada. Recursos que não são usados pelo binário serão removidos do APK. Isso só é compatível com regras que usam recursos locais (ou seja, os atributos `manifest` e `resource_files`) e exige o ProGuard. Ele funciona praticamente da mesma maneira que o redutor de recursos do Gradle (https://developer.android.com/studio/build/Pesquisa-code.html#reduce-resources). Diferenças significativas: Os recursos em `values/` serão removidos, assim como os recursos baseados em arquivos 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á gerado, 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 pela sinalização --android_resource_ Acessar.

Atributos
`name`	Nome, obrigatório Um nome exclusivo para o destino.
`aar`	Label, 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.

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`	Label, 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`	Label, obrigatório O destino android_binary que contém as classes de teste. O destino `android_binary` precisa especificar o destino que está sendo testado por meio do atributo `instruments`.

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 se pareça mais como um dispositivo real, em especial, controlando as strings do user agent e outros comportamentos que podem fazer com que um aplicativo ou servidor se comporte de maneira diferente de um dispositivo específico. As propriedades nesse arquivo substituirão as propriedades somente leitura 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 valor mínimo é de 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`	Label, 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 as imagens Esses arquivos fazem parte do SDK do Android ou são fornecidos por terceiros (por exemplo, a 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.

Atributos
`name`	Nome, obrigatório Um nome exclusivo para o destino.
`api_level`	Número inteiro; não configurável; o padrão é `0` O nível da API do Android em que o build será usado. Se não for especificado, será usado o nível mais alto da API instalado.
`path`	String; não configurável; o padrão é `""` Um caminho absoluto ou relativo para um Android NDK. É preciso definir esse atributo ou a variável de ambiente `$ANDROID_NDK_HOME`. É possível fazer o download do Android NDK no 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 sobre a resolução de dependências do espaço de trabalho para dependências deste repositório. Por exemplo, uma entrada `"@foo": "@bar"` declara que, sempre que esse repositório depender de `"@foo"` (como uma dependência de `"@foo//some:target"`), ele precisará resolver essa dependência no `"@bar"` declarado globalmente (`"@bar//some:target"`).