Regras do Android

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.7

Regras

android_binary

Ver 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 aplicativos Android (.apk).

Metas de saída implícitas

  • name.apk: um arquivo de pacote de aplicativo Android assinado com chaves de depuração e zipaligned, que pode ser usado para desenvolver e depurar seu aplicativo. Não é possível lançar o aplicativo quando ele está assinado com as chaves de depuração.
  • name_unsigned.apk: uma versão não assinada do arquivo acima que pode ser assinada com as chaves de lançamento antes da disponibilização ao público.
  • name_deploy.jar: um arquivo Java que contém o fechamento transitivo desse destino.

    O jar de implantação contém todas as classes que seriam encontradas por um carregador de classes que pesquisou o classpath de tempo de execução desse destino do início ao fim.

  • name_proguard.jar: um arquivo Java que contém o resultado da execução do ProGuard no name_deploy.jar. Essa saída só é gerada se o atributo proguard_specs for especificado.
  • name_proguard.map: um resultado de arquivo de mapeamento da execução do ProGuard no name_deploy.jar. Essa saída só é 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 essa segmentação.
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 encapsulamento ou produção cc_library de bibliotecas nativas .so para a plataforma de destino Android.
srcs

Lista de rótulos. O padrão é [].

A lista de arquivos de origem processados para criar o destino.

Os arquivos srcs do tipo .java são compilados. Para facilitar a leitura, não é recomendável 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.

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

assets

Lista de rótulos. O padrão é [].

A lista de recursos a serem empacotados. Normalmente, é um glob de todos os arquivos no diretório assets. Você também pode referenciar outras regras (qualquer regra que produza arquivos) ou arquivos exportados nos 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 dá o caminho para os arquivos em assets. O par assets e assets_dir descreve recursos empacotados. É necessário fornecer os dois atributos ou nenhum deles.
crunch_png

Booleano; o padrão é True

Faça o processamento de PNG (ou não). Isso é independente do processamento de nove patches, que é sempre feito. Essa é 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 o arquivo BUILD que contém a regra está. É possível especificar um pacote diferente, mas isso é altamente desencorajado, já que pode introduzir conflitos de classpath com outras bibliotecas que só serão detectados no tempo de execução.
debug_key

Rótulo; o padrão é "@bazel_tools//tools/android:debug_keystore"

Arquivo que contém o keystore de depuração a ser usado para assinar o APK de depuração. Normalmente, não é necessário usar uma chave diferente da padrão. Portanto, esse atributo deve ser omitido.

AVISO: não use as chaves de produção. Elas precisam ser protegidas e não podem ser 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 padrão. Portanto, esse atributo deve ser omitido.

AVISO: não use as chaves de produção. Elas precisam ser protegidas e não podem ser mantidas na árvore de origem.
debug_signing_lineage_file

Rótulo; o padrão é None

Arquivo que contém a linhagem de assinatura para debug_signing_keys. Normalmente, não é recomendável usar chaves diferentes da padrão. Portanto, esse atributo deve ser omitido.

AVISO: não use as chaves de produção. Elas precisam ser protegidas e não podem ser mantidas na árvore de origem.
densities

Lista de strings. O padrão é [].

Densidades para filtrar ao criar o APK. Isso remove os recursos de drawable rasterizados que não seriam carregados por um dispositivo com as densidades de tela especificadas, reduzindo o tamanho do APK. Uma seção "compatible-screens" correspondente também será adicionada ao manifesto se ele ainda não tiver uma lista de superconjuntos.
dex_shards

Número inteiro. O padrão é 1.

Número de fragmentos em que a indexação DEX precisa ser decomposta. Isso torna o dexing muito mais rápido, mas aumenta o tempo de instalação e inicialização do app. Quanto maior o binário, mais fragmentos devem ser usados. 25 é um bom valor para começar a testar.

Cada fragmento resulta em pelo menos um dex no app final. Por isso, não é recomendável definir esse valor como mais de 1 para binários de lançamento.

dexopts

Lista de strings. O padrão é [].

Flags de linha de comando adicionais para a ferramenta dx ao gerar classes.dex. Sujeito à substituição de "Criar variável" e tokenização do shell Bourne.
enable_data_binding

Booleano; o padrão é False

Se for "true", essa regra processará expressões de vinculação de dados em recursos de layout incluídos pelo 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, você também precisa fazer o seguinte:

  1. Defina esse atributo para todas as regras do Android que dependem transitivamente dele. Isso acontece porque os dependentes herdam as expressões de vinculação de dados da regra por meio da fusão de recursos. Por isso, eles também precisam criar com vinculação de dados para analisar essas expressões.
  2. Adicione uma entrada deps = para a biblioteca de tempo de execução de vinculação de dados a todas as metas que definem esse atributo. A localização dessa biblioteca depende da configuração do seu depósito.
incremental_dexing

Número inteiro; não configurável; o padrão é -1

Força a criação da meta com ou sem dexing incremental, substituindo os padrões e a flag --incremental_dexing.
instruments

Rótulo; o padrão é None

O destino android_binary a ser instrumentado.

Se esse atributo for definido, o android_binary será tratado como um aplicativo de teste para testes 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 essa meta. Sujeito à substituição de "Criar variável" e tokenização do shell Bourne.

Essas opções são transmitidas para o javac depois das opções globais.
key_rotation_min_sdk

String; o padrão é ""

Define a versão mínima da plataforma Android (nível da API) para que a chave de assinatura alternada de um APK seja usada para produzir a assinatura dele. 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 arquivos de classe. As classes definidas por esses arquivos de classe são colocadas no primary classes.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 criador da lista de dex principal. 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. Só é permitido 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, versionName, minSdkVersion, targetSdkVersion e maxSdkVersion também vão substituir os atributos correspondentes nas tags do manifesto e uses-sdk.

packageName será ignorado e definido com base em applicationId, se especificado, ou no pacote do manifesto.

Quando manifest_merger está definido como legacy, apenas applicationId, versionCode e versionName têm efeito.

multidex

String; o padrão é "native"

Se o código deve 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 do DEX é excedido. Supõe suporte nativo da plataforma para carregar classes multidex durante a execução. Isso 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 do DEX é excedido. Supõe que as classes multidex sejam carregadas pelo código do aplicativo (ou seja, sem suporte nativo da plataforma).
  • manual_main_dex: divide o código em vários arquivos DEX quando o limite de índice de 64K do DEX é 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 que não serão compactadas 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 mais informações. Normalmente, isso pode (e deve) 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 serem executados no tempo de compilação. Cada java_plugin especificado no atributo "plugins" será executado sempre que esse destino for criado. Os recursos gerados pelo plug-in serão incluídos no jar de resultado do destino.
proguard_apply_dictionary

Rótulo; o padrão é None

Arquivo a ser usado como um mapeamento para o ProGuard. Um arquivo separado por linhas de "palavras" para extrair ao renomear classes e membros durante a ofuscação.
proguard_apply_mapping

Rótulo; o padrão é None

Arquivo a ser usado como um mapeamento para o ProGuard. Um arquivo de mapeamento gerado pelo proguard_generate_mapping para ser reutilizado e aplicar o mesmo mapeamento a um novo build.
proguard_generate_mapping

Booleano; não configurável; o padrão é False

Se um arquivo de mapeamento do Proguard deve ser gerado. O arquivo de mapeamento só será gerado se proguard_specs for especificado. Esse arquivo vai listar o mapeamento entre os nomes originais e ofuscados de classes, métodos e 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. Normalmente, é um glob de todos os arquivos no diretório res.
Os arquivos gerados (de genrules) também podem ser referenciados por Rótulo aqui. A única restrição é que as saídas geradas precisam estar no mesmo diretório "res" que qualquer outro arquivo de recurso incluído.
shrink_resources

Número inteiro. O padrão é -1.

Se a redução de recursos será realizada. Os 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 requer o ProGuard. Ele funciona da mesma forma que o encolhedor de recursos do Gradle (https://developer.android.com/studio/build/shrink-code.html#shrink-resources).

Diferenças significativas:

  • Os recursos em values/ e os recursos baseados em arquivos serão removidos.
  • 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 flag --android_resource_shrinking.

aar_import

Ver 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 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 essa segmentação.
aar

Rótulo; obrigatório

O arquivo .aar a ser fornecido aos destinos do Android que dependem desse destino.
exports

Lista de rótulos. O padrão é [].

Destinos para exportar 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 dos arquivos JAR compilados no AAR.

android_library

Ver 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 fontes em um arquivo .jar. A biblioteca de ambiente de execução do Android android.jar é colocada implicitamente no caminho de classe de compilação.

Metas de saída implícitas

  • libname.jar: um arquivo Java.
  • libname-src.jar: um arquivo que contém as fontes ("source jar").
  • name.aar: um pacote "aar" do Android que contém o arquivo Java e os recursos desse destino. Ela não contém o fechamento transitivo.

Exemplos

Exemplos de regras do Android podem ser encontrados no diretório examples/android da árvore de origem do Bazel.

O exemplo a seguir mostra como definir idl_import_root. Faça com 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 essa segmentação.
deps

Lista de rótulos. O padrão é [].

A lista de outras bibliotecas a serem vinculadas. Os tipos de biblioteca permitidos são: android_library, java_library com restrição android e encapsulamento ou produção de cc_library bibliotecas nativas .so 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.

Os arquivos srcs do tipo .java são compilados. Para facilitar a leitura, não é recomendável 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.

Os arquivos srcs do tipo .srcjar são descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos .java com uma genrule ou extensão 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á descontinuado em breve. Tente não depender dele.

assets

Lista de rótulos. O padrão é [].

A lista de recursos a serem empacotados. Normalmente, é um glob de todos os arquivos no diretório assets. Você também pode referenciar outras regras (qualquer regra que produza arquivos) ou arquivos exportados nos 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 dá o caminho para os arquivos em assets. O par assets e assets_dir descreve recursos empacotados. É necessário fornecer os dois atributos 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 está. É possível especificar um pacote diferente, mas isso é altamente desencorajado, já que pode introduzir conflitos de classpath com outras bibliotecas que só serão detectados no tempo de execução.
enable_data_binding

Booleano; o padrão é False

Se for "true", essa regra processará expressões de vinculação de dados em recursos de layout incluídos pelo 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, você também precisa fazer o seguinte:

  1. Defina esse atributo para todas as regras do Android que dependem transitivamente dele. Isso acontece porque os dependentes herdam as expressões de vinculação de dados da regra por meio da fusão de recursos. Por isso, eles também precisam criar com vinculação de dados para analisar essas expressões.
  2. Adicione uma entrada deps = para a biblioteca de tempo de execução de vinculação de dados a todas as metas que definem esse atributo. A localização dessa biblioteca depende da configuração do seu depósito.
exported_plugins

Lista de rótulos. O padrão é [].

A lista de java_plugins (por exemplo, processadores de anotações) a serem exportados para bibliotecas que dependem diretamente desta biblioteca.

A lista especificada de java_plugins será aplicada a qualquer biblioteca que dependa diretamente dela, como se ela tivesse declarado explicitamente esses rótulos em plugins.

exports

Lista de rótulos. O padrão é [].

O fechamento de todas as regras alcançadas por atributos exports é considerado uma dependência direta de qualquer regra que dependa 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.

Se as entradas de manifesto devem ser 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 até a raiz da árvore de pacotes Java que contém fontes idl incluídas nesta biblioteca.

Esse caminho será usado como a raiz de importação ao processar fontes idl 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 a serem fornecidas como importações. Esses arquivos serão disponibilizados como importações para qualquer destino android_library que dependa dessa biblioteca, direta ou via fechamento transitivo, mas não serão traduzidos para Java nem compilados.

Somente arquivos .aidl que correspondem diretamente a fontes .java nessa biblioteca devem ser incluídos (por exemplo, implementações personalizadas de Parcelable). Caso contrário, use idl_srcs.

Esses arquivos precisam ser colocados corretamente para que o compilador aidl os encontre. Consulte 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 IDL do Android pré-processadas para fornecer como importações. Esses arquivos serão disponibilizados como importações para qualquer destino android_library que dependa dessa biblioteca, direta ou via fechamento transitivo, mas não serão traduzidos para Java nem compilados.

Inclua apenas arquivos .aidl pré-processados que correspondam diretamente às fontes .java nesta biblioteca (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 em 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, direta ou indiretamente.

Esses arquivos precisam ser colocados corretamente para que o compilador aidl os encontre. Consulte 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 essa meta. Sujeito à substituição de "Criar variável" e tokenização do shell Bourne.

Essas opções são transmitidas para o javac depois das opções globais.
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.

Booleano; o padrão é False

Use essa biblioteca apenas para compilação, não no ambiente de execução. As saídas de uma regra marcada como neverlink não serão usadas na criação de .apk. Isso é ú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 serem executados no tempo de compilação. Cada java_plugin especificado no atributo "plugins" será executado sempre que esse destino for criado. Os recursos gerados pelo plug-in serão incluídos no jar de resultado do destino.
proguard_specs

Lista de rótulos. O padrão é [].

Arquivos a serem usados como especificação do Proguard. Eles descrevem o conjunto de especificações a serem usadas pelo ProGuard. Se especificados, eles serão adicionados a qualquer destino android_binary que dependa dessa biblioteca. Os arquivos incluídos aqui precisam ter apenas regras idempotentes, ou seja, -dontnote, -dontwarn, assumenosideeffects e regras que começam com -keep. Outras opções só podem aparecer em proguard_specs de android_binary para garantir fusões não tautológicas.
resource_files

Lista de rótulos. O padrão é [].

A lista de recursos a serem empacotados. Normalmente, é um glob de todos os arquivos no diretório res.
Os arquivos gerados (de genrules) também podem ser referenciados por Rótulo aqui. A única restrição é que as saídas geradas precisam estar no mesmo diretório "res" que qualquer outro arquivo de recurso incluído.

android_instrumentation_test

Ver 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 em teste, o aplicativo de teste e qualquer outro aplicativo necessário, além de 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 pelo atributo instruments.

Exemplo

# java/com/samples/hello_world/BUILD

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

# The app under test
android_binary(
    name = "hello_world_app",
    manifest = "AndroidManifest.xml",
    deps = [":hello_world_lib"],
)

# javatests/com/samples/hello_world/BUILD

android_library(
    name = "hello_world_test_lib",
    srcs = ["Tests.java"],
    deps = [
      "//java/com/samples/hello_world:hello_world_lib",
      ...  # test dependencies such as Espresso and Mockito
    ],
)

# The test app
android_binary(
    name = "hello_world_test_app",
    instruments = "//java/com/samples/hello_world:hello_world_app",
    manifest = "AndroidManifest.xml",
    deps = [":hello_world_test_lib"],
)

android_instrumentation_test(
    name = "hello_world_uiinstrumentation_tests",
    target_device = ":some_target_device",
    test_app = ":hello_world_test_app",
)

Argumentos

Atributos
name

Nome: obrigatório

Um nome exclusivo para essa segmentação.
support_apks

Lista de rótulos. O padrão é [].

Outros APKs a serem instalados 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 já 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á testando usando o atributo instruments.

android_local_test

Ver 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)

Essa regra é para testes de unidade de regras android_library localmente (em vez de em um dispositivo). Ele funciona com o framework de testes Robolectric do Android. Consulte o site Android Robolectric para saber mais sobre como escrever testes do Robolectric.

Metas de saída implícitas

  • name.jar: um arquivo Java do teste.
  • name-src.jar: um arquivo que contém as fontes ("source jar").
  • name_deploy.jar: um arquivo de implantação Java adequado para implantação (criado somente se solicitado explicitamente).

Exemplos

Para usar o Robolectric com android_local_test, adicione o repositório do Robolectric ao arquivo WORKSPACE: 

http_archive(
    name = "robolectric",
    urls = ["https://github.com/robolectric/robolectric-bazel/archive/<COMMIT>.tar.gz"],
    strip_prefix = "robolectric-bazel-<COMMIT>",
    sha256 = "<HASH>",
)
load("@robolectric//bazel:robolectric.bzl", "robolectric_repositories")
robolectric_repositories()
Isso extrai as regras maven_jar necessárias para o Robolectric. Então, cada regra android_local_test precisa depender de @robolectric//bazel:robolectric. Confira um 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 essa segmentação.
deps

Lista de rótulos. O padrão é [].

A lista de bibliotecas a serem testadas, bem como 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.

Os arquivos srcs do tipo .java são compilados. Para facilitar a leitura, não é recomendável 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.

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

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

O atributo srcs é obrigatório e não pode estar vazio, a menos que runtime_deps seja especificado.

custom_package

String; o padrão é ""

Pacote Java em que a classe R será gerada. Por padrão, o pacote é inferido do diretório em que o arquivo BUILD que contém a regra está. Se você usar esse atributo, provavelmente também precisará usar test_class.
densities

Lista de strings. O padrão é [].

Densidades para filtrar ao criar o APK. Uma seção compatible-screens correspondente também será adicionada ao manifesto se ele ainda não tiver um superconjunto StarlarkListing.
enable_data_binding

Booleano; o padrão é False

Se for "true", essa regra processará referências de vinculação de dados usadas em dependências ativadas por vinculação de dados usadas por esse teste. Sem essa configuração, as dependências de vinculação de dados não terão a geração de código necessária no nível binário e poderão produzir falhas de build.
javacopts

Lista de strings. O padrão é [].

Opções extras do compilador para esta biblioteca. Sujeito à substituição de "Criar variável" e tokenização do shell Bourne.

Essas opções são transmitidas para o javac depois das opções globais.
jvm_flags

Lista de strings. O padrão é [].

Uma lista de flags a serem incorporadas no script de wrapper gerado para executar este binário. Sujeito à substituição de $(location) e "Make variable" e à tokenização do shell Bourne.

O script wrapper de um binário Java inclui uma definição de CLASSPATH (para encontrar todos os jars dependentes) e invoca o interpretador Java correto. A linha de comando gerada pelo script 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 wrapper antes da listagem do nome da classe.

Esse atributo não tem efeito nas saídas de *_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 estiverem 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 a "name" neste dicionário. applicationId, versionCode, versionName, minSdkVersion, targetSdkVersion e maxSdkVersion também vão substituir os atributos correspondentes do manifesto e das tags uses-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 que não serão compactadas no APK de recursos.
plugins

Lista de rótulos. O padrão é [].

Plug-ins do compilador Java para serem executados no tempo de 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 àqueles na configuração "en".
resource_jars

Lista de rótulos. O padrão é [].

Descontinuado: 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 recursos não estiver nesse diretório. Se não for especificado (o padrão), o caminho do arquivo de recurso será determinado de acordo com a mesma lógica do pacote Java dos arquivos de origem. Por exemplo, um arquivo de origem em stuff/java/foo/bar/a.txt será localizado em foo/bar/a.txt.

runtime_deps

Lista de rótulos. O padrão é [].

Bibliotecas a serem disponibilizadas apenas para o binário final ou para teste no momento da execução. Assim como os deps comuns, eles aparecem no caminho de classe de execução, mas não no caminho de classe de tempo de compilação. As dependências necessárias apenas no tempo de execução devem ser listadas aqui. As ferramentas de análise de dependências precisam ignorar os destinos que aparecem em runtime_deps e deps.
stamp

Número inteiro. O padrão é 0.

Determina se as informações de build serão codificadas no binário. Valores possíveis:
  • stamp = 1: sempre adicione as informações de build ao binário, mesmo em builds --nostamp. Evite essa configuração, já que ela pode encerrar o armazenamento em cache remoto para o binário e qualquer ação downstream que dependa dele.
  • stamp = 0: sempre substitua as informações de build por valores constantes. Isso oferece um bom cache de resultados de build.
  • stamp = -1: o embedding de informações de build é controlado pela flag --[no]stamp.

Os binários carimbados não são recriados, a menos que as dependências 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, a classe Java cujo nome corresponde ao name desta regra android_local_test será usada. A classe de teste precisa receber a anotação org.junit.runner.RunWith.

use_launcher

Booleano; o padrão é True

Indica se o binário deve usar um iniciador personalizado.

Se esse atributo for definido como "false", o atributo launcher e a flag --java_launcher relacionada serão ignorados para essa meta.

android_device

Ver 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)

Essa regra cria um emulador do Android configurado com as especificações fornecidas. Ele pode ser iniciado com um comando bazel run ou executando o script gerado diretamente. É recomendável depender de regras android_device atuais em vez de definir as suas próprias.

Essa regra é um destino adequado para a flag --run_under para bazel test e blaze run. Ele inicia um emulador, copia o destino que está sendo testado/executado para o emulador e o testa ou executa conforme apropriado.

O android_device permite criar imagens KVM se a system_image subjacente for baseada em X86 e otimizada para, no máximo, a arquitetura de CPU I686. Para usar KVM, adicione tags = ['requires-kvm'] à regra android_device.

Metas de saída implícitas

  • name_images/userdata.dat: contém arquivos de imagem e snapshots para iniciar o emulador.
  • name_images/emulator-meta-data.pb: contém informações serializadas necessárias para transmitir ao emulador e reiniciá-lo.

Exemplos

O exemplo a seguir mostra como usar android_device. //java/android/helloandroid/BUILD contém

android_device(
    name = "nexus_s",
    cache = 32,
    default_properties = "nexus_s.properties",
    horizontal_resolution = 480,
    ram = 512,
    screen_density = 233,
    system_image = ":emulator_images_android_16_x86",
    vertical_resolution = 800,
    vm_heap = 32,
)

filegroup(
    name = "emulator_images_android_16_x86",
    srcs = glob(["androidsdk/system-images/android-16/**"]),
)

//java/android/helloandroid/nexus_s.properties contém:

ro.product.brand=google
ro.product.device=crespo
ro.product.manufacturer=samsung
ro.product.model=Nexus S
ro.product.name=soju

Essa regra vai gerar imagens e um script de inicialização. É possível iniciar o emulador localmente executando bazel run :nexus_s -- --action=start. O script expõe as seguintes flags:

  • --adb_port: a porta em que o adb será exposto. Se você quiser emitir comandos adb para o emulador, esta é a porta em que você vai emitir adb connect.
  • --emulator_port: a porta em que o console de gerenciamento telnet do emulador será exposto.
  • --enable_display: inicia o emulador com uma tela se for verdadeiro (o padrão é falso).
  • --action: start ou kill.
  • --apks_to_install: uma lista de APKs para instalar no emulador.

Argumentos

Atributos
name

Nome: obrigatório

Um nome exclusivo para essa segmentação.
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 pareça mais um dispositivo real, controlando principalmente as strings UserAgent e outros comportamentos que podem fazer com que um aplicativo ou servidor se comporte de maneira diferente em um dispositivo específico. As propriedades nesse arquivo vão substituir 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 ser emulada. O valor mínimo é 240.
platform_apks

Lista de rótulos. O padrão é [].

Uma lista de APKs a serem instalados no dispositivo na inicialização.
ram

Número inteiro; obrigatório

A quantidade de RAM em megabytes a ser emulada para o dispositivo. Isso é 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

Rótulo; obrigatório

Um grupo de arquivos que contém 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 de dados do usuário
  • 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 fornece imagens x86.
vertical_resolution

Número inteiro; obrigatório

A resolução vertical da tela em pixels a ser emulada. O valor mínimo é 240.
vm_heap

Número inteiro; obrigatório

O tamanho em megabytes do heap da máquina virtual que o Android vai usar para cada processo. O valor mínimo é 16 megabytes.

android_ndk_repository

Ver origem da regra 
android_ndk_repository(name, api_level, path, repo_mapping)

Configura o Bazel para usar um NDK do Android e oferecer suporte à criação de destinos do Android com código nativo.

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

Observe que a criação para Android também exige uma regra android_sdk_repository no 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 vai localizar o NDK do Android em $ANDROID_NDK_HOME e detectar o nível de API mais alto compatível. 

android_ndk_repository(
    name = "androidndk",
    path = "./android-ndk-r20",
    api_level = 24,
)

O exemplo acima vai usar o NDK do Android localizado no seu espaço de trabalho em ./android-ndk-r20. Ele vai usar as bibliotecas do nível 24 da API ao compilar seu código JNI.

cpufeatures

O Android NDK contém a biblioteca cpufeatures que pode ser usada para detectar a CPU de um dispositivo no tempo de 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 essa segmentação.
api_level

Número inteiro; não configurável; o padrão é 0

O nível da API do Android para compilação. Se não for especificado, o nível de API mais alto instalado será usado.
path

String; não configurável; o padrão é ""

Um caminho absoluto ou relativo para um Android NDK. É preciso definir este atributo ou a variável de ambiente $ANDROID_NDK_HOME.

O Android NDK pode ser baixado no 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 sobre a resolução de dependências do espaço de trabalho para dependências desse repositório.

Por exemplo, uma entrada "@foo": "@bar" declara que, sempre que este repositório depender de "@foo" (como uma dependência de "@foo//some:target"), ele vai resolver essa dependência em "@bar" ("@bar//some:target") declarado globalmente.

android_sdk_repository

Ver origem da regra 
android_sdk_repository(name, api_level, build_tools_version, path, repo_mapping)

Configura o Bazel para usar um SDK do Android local e oferecer suporte à criação de destinos do Android.

Exemplos

O mínimo para configurar um SDK do Android para 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 usa o nível de API do Android mais alto 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 com valores específicos. O build vai falhar se o SDK do Android não tiver o nível da API ou a versão das ferramentas de build especificados instalados. 

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 ele estiver verificado no controle de versão).

Bibliotecas de suporte

As bibliotecas de suporte estão disponíveis no Android SDK Manager como "Android Support Repository". É um conjunto versionado de bibliotecas comuns do Android, como as bibliotecas de suporte e AppCompat, que é empacotado como um repositório Maven local. O 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 appcompat v7. 

android_library(
    name = "lib",
    srcs = glob(["*.java"]),
    manifest = "AndroidManifest.xml",
    resource_files = glob(["res/**"]),
    deps = ["@androidsdk//com.android.support:appcompat-v7-25.0.0"],
)

Argumentos

Atributos
name

Nome: obrigatório

Um nome exclusivo para essa segmentação.
api_level

Número inteiro; não configurável; o padrão é 0

O nível da API do Android para criar por padrão. Se não for especificado, o nível de API mais alto instalado será usado.

O nível da API usado em um build específico pode ser substituído pela flag android_sdk. android_sdk_repository cria um destino android_sdk para cada nível da API instalado no SDK com o nome @androidsdk//:sdk-${level}, especificado ou não. Por exemplo, para criar em relação a um nível de API não padrão: bazel build --android_sdk=@androidsdk//:sdk-19 //java/com/example:app.

Para conferir todas as metas de android_sdk geradas 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 build do Android a ser usada no SDK do Android. Se não for especificado, a versão mais recente das ferramentas de build instaladas será usada.

O Bazel requer ferramentas de build na versão 30.0.0 ou mais recente.

path

String; não configurável; o padrão é ""

Um caminho absoluto ou relativo para um SDK do Android. É preciso definir este atributo ou a variável de ambiente $ANDROID_HOME.

O SDK do Android pode ser baixado no 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 sobre a resolução de dependências do espaço de trabalho para dependências desse repositório.

Por exemplo, uma entrada "@foo": "@bar" declara que, sempre que este repositório depender de "@foo" (como uma dependência de "@foo//some:target"), ele vai resolver essa dependência em "@bar" ("@bar//some:target") declarado globalmente.