Para conferir a documentação da versão estável, use o menu suspenso "Documentos com controle de versão". A visualização padrão reflete a versão mais recente em HEAD.

Esta página foi traduzida pela API Cloud Translation.

Regras do Android

Informar um problema Ver código-fonte

Regras

android_binary
aar_import
android_library
android_instrumentation_test
android_local_test
android_device
android_ndk_repository
android_sdk_repository

binário_android

Ver origem da 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 apps Android (.apk).

Destinos de saída implícita

name.apk: um arquivo de pacote de app Android assinado com chaves de depuração e zipaligned, que pode ser usado para desenvolver e depurar seu app. Não é possível liberar o aplicativo quando ele está assinado com as chaves de depuração.
name_unsigned.apk: uma versão não assinada do arquivo acima que pode ser assinada com as chaves de lançamento antes do lançamento ao público.
name_deploy.jar: um arquivo Java que contém o fechamento transitivo desse destino.
O jar de implantação contém todas as classes que seriam encontradas por um carregador de classe que pesquisou o caminho de classe de tempo de execução desse destino do início ao fim.
name_proguard.jar: um arquivo Java que contém o resultado da execução do ProGuard no name_deploy.jar. Essa saída só será produzida se o atributo proguard_specs for especificado.
name_proguard.map: um resultado de arquivo de mapeamento de execução do ProGuard no name_deploy.jar. Essa saída só vai ser produzida se o atributo proguard_specs for especificado e proguard_generate_mapping ou shrink_resources estiverem definidos.

Exemplos

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

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para esse destino.
`deps`	`List of labels; optional` A lista de outras bibliotecas que serão vinculadas ao destino binário. Os tipos de biblioteca permitidos são: `android_library`, `java_library` com restrição de `android` e `cc_library` envolvendo ou produzindo bibliotecas nativas de `.so` para a plataforma de destino do Android.
`srcs`	`List of labels; optional` 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 é bom colocar o nome de um arquivo de origem `.java` gerado em `srcs`. Em vez disso, coloque o nome da regra dependente no `srcs`, conforme descrito abaixo. Arquivos `srcs` do tipo `.srcjar` são descompactados e compilados. Isso é útil se você precisa gerar um conjunto de arquivos .java com uma regra geral ou de extensão.
`assets`	`List of labels; optional` A lista de recursos a serem empacotados. Geralmente, ele é 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 nos outros pacotes, desde que todos estejam no diretório `assets_dir` no pacote correspondente.
`assets_dir`	`String; optional` A string que dá o caminho para os arquivos em `assets`. O par `assets` e `assets_dir` descrevem os recursos empacotados, e ambos os atributos precisam ser fornecidos ou nenhum deles.
`crunch_png`	`Boolean; optional; default is True` Faça o processamento de PNG (ou não). Isso é independente do processamento de nove patches, que é sempre feito. Esta é uma solução obsoleta para um bug do aapt que foi corrigido no aapt2.
`custom_package`	`String; optional` Pacote Java para o qual as origens 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 ele pode introduzir conflitos de caminho de classe com outras bibliotecas que só serão detectadas durante a execução.
`debug_key`	`Label; optional; default is @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 convém usar uma chave diferente da chave padrão, portanto, esse atributo deve ser omitido. AVISO: não use suas chaves de produção. Elas precisam ser totalmente protegidas e não podem ser mantidas na árvore de origem.
`debug_signing_keys`	`List of labels; optional` Lista de arquivos, keystores de depuração a serem usados para assinar o APK de depuração. Normalmente, não convém usar chaves diferentes da chave padrão, portanto, esse atributo deve ser omitido. AVISO: não use suas chaves de produção. Elas precisam ser totalmente protegidas e não podem ser mantidas na árvore de origem.
`debug_signing_lineage_file`	`Label; optional` Arquivo que contém a linhagem de assinatura de debug_signing_keys. Normalmente, não convém usar chaves diferentes da chave padrão, portanto, esse atributo deve ser omitido. AVISO: não use suas chaves de produção. Elas precisam ser totalmente protegidas e não podem ser mantidas na árvore de origem.
`densities`	`List of strings; optional` Densidades para filtrar ao criar o APK. Isso vai eliminar os recursos drawable de varredura que não seriam carregados por um dispositivo com as densidades de tela especificadas para reduzir o tamanho do APK. Uma seção de telas compatíveis correspondente também será adicionada ao manifesto se ainda não contiver uma listagem de superconjunto.
`dex_shards`	`Integer; optional; default is 1` Número de fragmentos dexados devem ser decompostos. Isso torna a dexação muito mais rápida em detrimento da instalação e do tempo de inicialização do app. Quanto maior for o binário, mais fragmentos serão usados. 25 é um bom valor para começar a experimentar. Observe que cada fragmento resulta em pelo menos um dex no app final. Por esse motivo, não é recomendável definir esse fragmento como mais de um para os binários de lançamento.
`dexopts`	`List of strings; optional` Sinalizações de linha de comando adicionais para a ferramenta dx ao gerar classes.dex. Sujeito à substituição "Criar variável" e à tokenização do shell do Bourne.
`enable_data_binding`	`Boolean; optional; default is False` Se for verdadeiro, 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: Defina esse atributo para todas as regras do Android que dependem transitivamente dele. Isso ocorre porque os delimitadores herdam as expressões de vinculação de dados da regra por meio da 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. A localização desta biblioteca depende da configuração do depósito.
`incremental_dexing`	`Integer; optional; nonconfigurable; default is -1` Força o destino a ser criado com ou sem dexação incremental, modificando padrões e a sinalização --incremental_dexing.
`instruments`	`Label; optional` O destino `android_binary` do instrumento. Se esse atributo for definido, a `android_binary` será tratada como um aplicativo de teste para testes de instrumentação. Um destino `android_instrumentation_test` pode especificar esse destino no atributo test_app dele.
`javacopts`	`List of strings; optional` Opções extras do compilador para este destino. Sujeito à substituição "Criar variável" e à tokenização do shell do Bourne. Essas opções do compilador são transmitidas para javac após as opções globais do compilador.
`key_rotation_min_sdk`	`String; optional` Define a versão mínima da Plataforma Android (nível da API) em que uma chave de assinatura alternada de um APK precisa ser usada para produzir a assinatura dele. A chave de assinatura original do APK vai ser usada para todas as versões anteriores da plataforma.
`main_dex_list`	`Label; optional` Um arquivo de texto contém uma lista de nomes de arquivos de classe. As classes definidas por esses arquivos são colocadas no classes.dex principal. 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`	`List of strings; optional` Opções de linha de comando a serem transmitidas para o criador de lista de dex principal. Use essa opção para afetar as classes incluídas na lista de dex principal.
`main_dex_proguard_specs`	`List of labels; optional` Arquivos que serão 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; required` Nome do arquivo de manifesto do Android, normalmente `AndroidManifest.xml`. Precisa ser definido se resource_files ou assets forem definidos.
`manifest_values`	`Dictionary: String -> String; optional` 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. O applicationId, versionCode, versionName, minSdkVersion, targetSdkVersion e maxSdkVersion também substituem os atributos correspondentes do manifesto e as tags uses-sdk. O packageName será ignorado e definido usando o applicationId, se especificado, ou o pacote no manifesto. Quando manifest_merger estiver definido como legado, somente o applicationId, versionCode e versionName terão efeito.
`multidex`	`String; optional; default is "native"` Define se o código será dividido em vários arquivos dex. Possíveis valores: `native`: divide o código em vários arquivos dex quando o limite de índice 64K é excedido. Considera o suporte da plataforma nativa para carregar classes multidex no ambiente de 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 64K é excedido. Considera que as classes multidex são carregadas pelo código do aplicativo, ou seja, sem suporte a plataformas nativas. `manual_main_dex`: divide o código em vários arquivos dex quando o limite do índice 64K é 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`	`List of strings; optional` Uma lista de extensões de arquivo para deixar descompactado no APK.
`package_id`	`Integer; optional; default is 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 deve) permanecer indefinido, resultando no valor padrão de 127 (`0x7F`).
`plugins`	`List of labels; optional` Plug-ins do compilador Java para serem executados no momento da compilação. Cada `java_plugin` especificado no atributo de plug-ins será executado sempre que o destino for criado. Os recursos gerados pelo plug-in serão incluídos no jar de resultado do destino.
`proguard_apply_dictionary`	`Label; optional` Arquivo a ser usado como um mapeamento para o ProGuard. Um arquivo separado por linhas de "palavras" que pode ser extraído ao renomear classes e membros durante a ofuscação.
`proguard_apply_mapping`	`Label; optional` Arquivo a ser usado como um mapeamento para o ProGuard. Um arquivo de mapeamento gerado por `proguard_generate_mapping` para ser reutilizado para aplicar o mesmo mapeamento a um novo build.
`proguard_generate_mapping`	`Boolean; optional; nonconfigurable; default is False` Define se o arquivo de mapeamento Proguard será gerado. O arquivo de mapeamento só será gerado se `proguard_specs` for especificado. Esse arquivo lista o mapeamento entre a classe, o método e os nomes de campo originais e ofuscados. AVISO: se esse atributo for usado, a especificação do ProGuard não poderá conter `-dontobfuscate` nem `-printmapping`.
`proguard_specs`	`List of labels; optional` Arquivos a serem usados como especificação do Proguard. Esse arquivo descreve o conjunto de especificações que serão usadas pelo Proguard.
`resource_configuration_filters`	`List of strings; optional` Uma lista de filtros de configuração de recursos, como "en", que limitará os recursos do APK apenas àqueles da configuração "en". Para ativar a pseudolocalidade, inclua as pseudolocalidades `en_XA` e/ou `ar_XB`.
`resource_files`	`List of labels; optional` A lista de recursos a serem empacotados. Geralmente, ele é um `glob` de todos os arquivos no diretório `res`. Aqui, os arquivos gerados (de regras gerais) também podem ser referenciados por Rótulo. A única restrição é que as saídas geradas precisam estar no mesmo diretório "`res`" de qualquer outro arquivo de recursos incluído.
`shrink_resources`	`Integer; optional; default is -1` Define se a redução de recursos será feita. Os recursos que não forem 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 quase da mesma forma que o redutor de recursos do Gradle (https://developer.android.com/studio/build/shrink-code.html#shrink-resources). Diferenças significativas: os recursos de `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 vai 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_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 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`	`Name; required` Um nome exclusivo para esse destino.
`aar`	`Label; required` O arquivo `.aar` a ser fornecido aos destinos do Android que dependem desse destino.
`exports`	`List of labels; optional` Destinos para exportar para regras que dependem dessa regra. Consulte java_library.exports.
`srcjar`	`Label; optional` Um arquivo JAR que contém o código-fonte para os arquivos JAR compilados no AAR.

biblioteca android

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

Destinos de saída implícita

libname.jar: um arquivo Java.
libname-src.jar: um arquivo que contém as origens ("jar de origem").
name.aar: um pacote "aar" do Android que contém o arquivo Java e os recursos desse destino. Não contém o fechamento transitivo.

Exemplos

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

O exemplo a seguir mostra como definir idl_import_root. Permitir que //java/bazel/helloandroid/BUILD contenha:

android_library(
    name = "parcelable",
    srcs = ["MyParcelable.java"], # bazel.helloandroid.MyParcelable

    # MyParcelable.aidl will be used as import for other .aidl
    # files that depend on it, but will not be compiled.
    idl_parcelables = ["MyParcelable.aidl"] # bazel.helloandroid.MyParcelable

    # We don't need to specify idl_import_root since the aidl file
    # which declares bazel.helloandroid.MyParcelable
    # is present at java/bazel/helloandroid/MyParcelable.aidl
    # underneath a java root (java/).
)

android_library(
    name = "foreign_parcelable",
    srcs = ["src/android/helloandroid/OtherParcelable.java"], # android.helloandroid.OtherParcelable
    idl_parcelables = [
        "src/android/helloandroid/OtherParcelable.aidl" # android.helloandroid.OtherParcelable
    ],

    # We need to specify idl_import_root because the aidl file which
    # declares android.helloandroid.OtherParcelable is not positioned
    # at android/helloandroid/OtherParcelable.aidl under a normal java root.
    # Setting idl_import_root to "src" in //java/bazel/helloandroid
    # adds java/bazel/helloandroid/src to the list of roots
    # the aidl compiler will search for imported types.
    idl_import_root = "src",
)

# Here, OtherInterface.aidl has an "import android.helloandroid.CallbackInterface;" statement.
android_library(
    name = "foreign_interface",
    idl_srcs = [
        "src/android/helloandroid/OtherInterface.aidl" # android.helloandroid.OtherInterface
        "src/android/helloandroid/CallbackInterface.aidl" # android.helloandroid.CallbackInterface
    ],

    # As above, idl_srcs which are not correctly positioned under a java root
    # must have idl_import_root set. Otherwise, OtherInterface (or any other
    # interface in a library which depends on this one) will not be able
    # to find CallbackInterface when it is imported.
    idl_import_root = "src",
)

# MyParcelable.aidl is imported by MyInterface.aidl, so the generated
# MyInterface.java requires MyParcelable.class at compile time.
# Depending on :parcelable ensures that aidl compilation of MyInterface.aidl
# specifies the correct import roots and can access MyParcelable.aidl, and
# makes MyParcelable.class available to Java compilation of MyInterface.java
# as usual.
android_library(
    name = "idl",
    idl_srcs = ["MyInterface.aidl"],
    deps = [":parcelable"],
)

# Here, ServiceParcelable uses and thus depends on ParcelableService,
# when it's compiled, but ParcelableService also uses ServiceParcelable,
# which creates a circular dependency.
# As a result, these files must be compiled together, in the same android_library.
android_library(
    name = "circular_dependencies",
    srcs = ["ServiceParcelable.java"],
    idl_srcs = ["ParcelableService.aidl"],
    idl_parcelables = ["ServiceParcelable.aidl"],
)

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para esse destino.
`deps`	`List of labels; optional` A lista de outras bibliotecas para vincular. Os tipos de biblioteca permitidos são: `android_library`, `java_library` com restrição de `android` e `cc_library` envolvendo ou produzindo bibliotecas nativas de `.so` para a plataforma de destino Android.
`srcs`	`List of labels; optional` 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 é bom colocar o nome de um arquivo de origem `.java` gerado em `srcs`. Em vez disso, coloque o nome da regra dependente no `srcs`, conforme descrito abaixo. Arquivos `srcs` do tipo `.srcjar` são descompactados e compilados. Isso é útil se você precisa gerar um conjunto de arquivos .java com uma regra geral ou de extensão. Se `srcs` for omitido, qualquer dependência especificada em `deps` será exportada desta 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`	`List of labels; optional` A lista de recursos a serem empacotados. Geralmente, ele é 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 nos outros pacotes, desde que todos estejam no diretório `assets_dir` no pacote correspondente.
`assets_dir`	`String; optional` A string que dá o caminho para os arquivos em `assets`. O par `assets` e `assets_dir` descrevem os recursos empacotados, e ambos os atributos precisam ser fornecidos ou nenhum deles.
`custom_package`	`String; optional` Pacote Java para o qual as origens 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 ele pode introduzir conflitos de caminho de classe com outras bibliotecas que só serão detectadas durante a execução.
`enable_data_binding`	`Boolean; optional; default is False` Se for verdadeiro, 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: Defina esse atributo para todas as regras do Android que dependem transitivamente dele. Isso ocorre porque os delimitadores herdam as expressões de vinculação de dados da regra por meio da 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. A localização desta biblioteca depende da configuração do depósito.
`exported_plugins`	`List of labels; optional` A lista de `java_plugin`s (por exemplo, processadores de anotações) a serem exportados para bibliotecas que dependem diretamente dessa biblioteca. A lista especificada de `java_plugin`s vai ser aplicada a qualquer biblioteca que dependa diretamente dessa biblioteca, como se essa biblioteca tivesse declarado explicitamente esses rótulos em `plugins`.
`exports`	`List of labels; optional` O fechamento de todas as regras alcançadas pelos 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`	`Integer; optional; default is 1` Define se é necessário exportar entradas de manifesto para `android_binary` destinos que dependem desse destino. Os atributos `uses-permissions` nunca são exportados.
`idl_import_root`	`String; optional` Caminho relativo ao pacote para a raiz da árvore de pacotes Java, contendo fontes idl incluídas nesta biblioteca. Esse caminho será usado como a raiz de importação ao processar origens de ID 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. Veja exemplos.
`idl_parcelables`	`List of labels; optional` Lista de definições de IDL do Android a serem fornecidas como importações. Esses arquivos vão ser disponibilizados como importações para qualquer destino `android_library` que dependa dessa biblioteca, diretamente ou pelo fechamento transitivo dela, mas não vão ser convertidos em Java ou compilados. Somente os arquivos `.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 precisam ser colocados de forma adequada para que o compilador Aidl os encontre. Consulte a descrição de idl_import_root para informações sobre o que isso significa.
`idl_preprocessed`	`List of labels; optional` Lista de definições de IDL do Android pré-processadas para fornecer como importações. Esses arquivos vão ser disponibilizados como importações para qualquer destino `android_library` que dependa dessa biblioteca, diretamente ou pelo fechamento transitivo dela, mas não vão ser convertidos em Java ou compilados. Somente arquivos `.aidl` pré-processados que correspondam diretamente a fontes `.java` nessa biblioteca precisam ser incluídos (por exemplo, implementações personalizadas de Parcelable). Caso contrário, use `idl_srcs` para definições do IDL do Android que precisam ser traduzidas para interfaces Java e `idl_parcelable` para arquivos AIDL não pré-processados.
`idl_srcs`	`List of labels; optional` 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 vão ser disponibilizados como importações para qualquer destino `android_library` que dependa dessa biblioteca, diretamente ou pelo fechamento transitivo. Esses arquivos precisam ser colocados de forma adequada para que o compilador Aidl os encontre. Consulte a descrição de idl_import_root para informações sobre o que isso significa.
`javacopts`	`List of strings; optional` Opções extras do compilador para este destino. Sujeito à substituição "Criar variável" e à tokenização do shell do Bourne. Essas opções do compilador são transmitidas para javac após as opções globais do compilador.
`manifest`	`Label; optional` Nome do arquivo de manifesto do Android, normalmente `AndroidManifest.xml`. Precisa ser definido se resource_files ou assets forem definidos.
`neverlink`	`Boolean; optional; default is 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`	`List of labels; optional` Plug-ins do compilador Java para serem executados no momento da compilação. Cada `java_plugin` especificado no atributo de plug-ins será executado sempre que o destino for criado. Os recursos gerados pelo plug-in serão incluídos no jar de resultado do destino.
`proguard_specs`	`List of labels; optional` Arquivos a serem usados como especificação do Proguard. Eles vão descrever o conjunto de especificações que serão usadas pelo Proguard. Se especificado, ele será adicionado a qualquer destino `android_binary`, dependendo desta biblioteca. Os arquivos incluídos aqui precisam ter apenas regras idempotentes, como -dontnote, -dontwarn, pressnosideeffects e regras que começam com -keep. Outras opções só podem aparecer no proguard_specs de `android_binary` para garantir mesclagens não tautológicas.
`resource_files`	`List of labels; optional` A lista de recursos a serem empacotados. Geralmente, ele é um `glob` de todos os arquivos no diretório `res`. Aqui, os arquivos gerados (de regras gerais) também podem ser referenciados por Rótulo. A única restrição é que as saídas geradas precisam estar no mesmo diretório "`res`" de qualquer outro arquivo de recursos incluído.

teste_de_instrumentação_android

Ver origem da 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 quaisquer outros aplicativos necessários e executará os testes definidos no pacote de teste.

O atributo test_app especifica a android_binary que contém o teste. Esse android_binary especifica o aplicativo android_binary em teste pelo atributo instruments.

Exemplo

# java/com/samples/hello_world/BUILD

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

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

# javatests/com/samples/hello_world/BUILD

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

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

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

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para esse destino.
`support_apks`	`List of labels; optional` Outros APKs para instalar no dispositivo antes de iniciar o teste de instrumentação.
`target_device`	`Label; required` O android_device em que o teste precisa ser executado. Para executar o teste em um emulador que já esteja em execução ou em um dispositivo físico, use estes argumentos: `--test_output=streamed --test_arg=--device_broker_type=LOCAL_ADB_SERVER --test_arg=--device_serial_number=$device_identifier`
`test_app`	`Label; required` O destino android_binary que contém as classes de teste. O destino `android_binary` precisa especificar qual destino está sendo testado usando o atributo `instruments`.

teste_local_android

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

Destinos de saída implícita

name.jar: um arquivo Java do teste.
name-src.jar: um arquivo que contém as origens ("jar de origem").
name_deploy.jar: um arquivo de implantação em Java adequado para implantação (criado apenas se solicitado explicitamente).

Exemplos

Para usar o Robolectric com android_local_test, adicione o repositório do Robolectric (link em inglês) ao arquivo WORKSPACE:

http_archive(
    name = "robolectric",
    urls = ["https://github.com/robolectric/robolectric-bazel/archive/<COMMIT>.tar.gz"],
    strip_prefix = "robolectric-bazel-<COMMIT>",
    sha256 = "<HASH>",
)
load("@robolectric//bazel:robolectric.bzl", "robolectric_repositories")
robolectric_repositories()

Isso extrai as regras maven_jar necessárias para o Robolectric. Em seguida, cada regra android_local_test depende de @robolectric//bazel:robolectric. Veja o exemplo abaixo.

android_local_test(
    name = "SampleTest",
    srcs = [
        "SampleTest.java",
    ],
    manifest = "LibManifest.xml",
    deps = [
        ":sample_test_lib",
        "@robolectric//bazel:android-all",
    ],
)

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

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para esse destino.
`deps`	`List of labels; optional` A lista de bibliotecas a serem testadas, bem como bibliotecas adicionais a serem vinculadas ao destino. Todos os recursos, bem como os arquivos de manifesto declarados nas regras do Android no encerramento transitório 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`	`List of labels; optional` 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 é bom colocar o nome de um arquivo de origem `.java` gerado em `srcs`. Em vez disso, coloque o nome da regra dependente no `srcs`, conforme descrito abaixo. Arquivos `srcs` do tipo `.srcjar` são descompactados e compilados. Isso é útil se você precisa gerar um conjunto de arquivos .java com uma regra geral ou de extensão. Todos os outros arquivos são ignorados, desde que haja pelo menos um arquivo do tipo descrito acima. Caso contrário, um erro será gerado. O atributo `srcs` é obrigatório e não pode ficar vazio, a menos que `runtime_deps` seja especificado.
`custom_package`	`String; optional` Pacote Java em que a classe R será gerada. Por padrão, o pacote é inferido do diretório onde está o arquivo BUILD que contém a regra. Se você usar esse atributo, provavelmente também precisará usar `test_class`.
`densities`	`List of strings; optional` Densidades para filtrar ao criar o APK. Uma seção correspondente de telas compatíveis também será adicionada ao manifesto se ainda não tiver uma StarlarkListing de superconjunto.
`enable_data_binding`	`Boolean; optional; default is False` Se for verdadeiro, esta regra processará referências de vinculação de dados usadas em dependências ativadas por vinculação de dados usadas pelo 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 binário e poderão gerar falhas de build.
`javacopts`	`List of strings; optional` Opções extras do compilador para esta biblioteca. Sujeito à substituição "Criar variável" e à tokenização do shell do Bourne. Essas opções do compilador são transmitidas para javac após as opções globais do compilador.
`jvm_flags`	`List of strings; optional` Uma lista de sinalizações a serem incorporadas no script de wrapper gerado para executar o binário. Sujeito à substituição de $(location) e "Tornar variável", e tokenização do shell do Bourne. O script de wrapper de um binário Java inclui uma definição de CLASSPATH (para encontrar todos os jars dependentes) e invoca o interpretador Java correto. A linha de comando gerada pelo script de wrapper inclui o nome da classe principal seguida de um `"$@"`, para que você possa transmitir outros argumentos após o nome da classe. No entanto, argumentos destinados à análise pela JVM precisam ser especificados antes do nome de classe na linha de comando. O conteúdo de `jvm_flags` é adicionado ao script do wrapper antes que o nome de classe seja listado. Esse atributo não tem efeito nas saídas `*_deploy.jar`.
`manifest`	`Label; optional` Nome do arquivo de manifesto do Android, normalmente `AndroidManifest.xml`. Precisa ser definido se resource_files ou assets forem definidos ou se um dos manifestos das bibliotecas em teste tiver uma tag `minSdkVersion`.
`manifest_values`	`Dictionary: String -> String; optional` 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 em `applicationId`, se especificado, ou no pacote no manifesto. Não é necessário ter um manifesto na regra para usar manifest_values.
`nocompress_extensions`	`List of strings; optional` Uma lista de extensões de arquivo para deixar descompactados no APK de recursos.
`plugins`	`List of labels; optional` Plug-ins do compilador Java para serem executados 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`	`List of strings; optional` Uma lista de filtros de configuração de recursos, como "en", que limitará os recursos do APK apenas àqueles da configuração "en".
`resource_jars`	`List of labels; optional` Descontinuado: use java_import e deps ou runtime_deps.
`resource_strip_prefix`	`String; optional` O prefixo do caminho a ser removido dos recursos Java. Se especificado, esse prefixo de caminho é removido de todos os arquivos no atributo `resources`. É um erro um arquivo de recursos não estar 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` estará localizado em `foo/bar/a.txt`.
`runtime_deps`	`List of labels; optional` Bibliotecas a serem disponibilizadas para o binário final ou teste apenas no tempo de execução. Assim como o `deps` comum, eles vão aparecer no caminho de classe de tempo de execução, mas ao contrário deles, não no caminho de classe de tempo de compilação. As dependências necessárias apenas no momento da execução precisam ser listadas aqui. As ferramentas de análise de dependência precisam ignorar destinos que aparecem em `runtime_deps` e `deps`.
`stamp`	`Integer; optional; default is 0` Define se as informações de compilação serão codificadas no binário. Valores possíveis: `stamp = 1`: sempre cole as informações do build no binário, mesmo em builds do `--nostamp`. Essa configuração precisa ser evitada, já que ela pode eliminar o armazenamento em cache remoto para o binário e todas as ações downstream que dependem dele. `stamp = 0`: sempre substitua informações de build por valores constantes. Isso oferece um bom armazenamento em cache dos resultados da versão. `stamp = -1`: a incorporação de informações de build é controlada pela sinalização `--[no]stamp`. Os binários carimbados não são recriados, a menos que as dependências deles sejam alteradas.
`test_class`	`String; optional` A classe Java a ser carregada pelo executor de teste. Esse atributo especifica o nome de uma classe Java a ser executada pelo teste. É raro precisar ser configurado. Se esse argumento for omitido, a classe Java com o nome correspondente ao `name` desta regra `android_local_test` será usada. A classe de teste precisa ser anotada com `org.junit.runner.RunWith`.
`use_launcher`	`Boolean; optional; default is True` Indica se o binário deve usar uma tela de início personalizada. Se ele for definido como falso, o atributo launcher e a sinalização `--java_launcher` relacionada serão ignorados para esse destino.

Dispositivo Android

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 Android Emulator configurado com as especificações fornecidas. Esse emulador pode ser iniciado por um comando de execução do bazel ou executando diretamente o script gerado. É recomendável depender das regras android_device já existentes em vez de definir as suas.

Essa regra é adequada para a sinalização --run_under no teste bazel e na execução blaze. Ele inicia um emulador, copia o destino que está sendo testado/executado no emulador e o testa ou o executa conforme apropriado.

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

Destinos de saída implícita

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

Exemplos

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

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

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

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

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

Essa regra gerará imagens e um script de início. Você pode iniciar o emulador localmente executando bazel run :nexus_s -- --action=start. O script expõe as seguintes sinalizações:

--adb_port: a porta em que o adb será exposto. Se você quiser emitir comandos do adb para o emulador, essa será a porta em que você vai emitir a conexão do adb.
--emulator_port: a porta em que o console de gerenciamento de telnet do emulador será exposto.
--enable_display: inicia o emulador com uma tela se for verdadeiro (o padrão é "false").
--action: iniciar ou encerrar.
--apks_to_install: uma lista de apks a serem instalados no emulador.

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para esse destino.
`cache`	`Integer; required` O tamanho em megabytes da partição de cache do emulador. O valor mínimo é 16 megabytes.
`default_properties`	`Label; optional` 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 se parecer mais com um dispositivo real (especialmente com o controle das strings UserAgent e outros comportamentos que podem fazer com que um aplicativo ou um servidor se comporte de maneira diferente em um dispositivo específico). As propriedades nesse arquivo modificarão as propriedades somente leitura normalmente definidas pelo emulador, como ro.product.model.
`horizontal_resolution`	`Integer; required` A resolução horizontal da tela em pixels. O valor mínimo é 240.
`platform_apks`	`List of labels; optional` Uma lista de APKs a serem instalados no dispositivo no momento da inicialização.
`ram`	`Integer; required` Quantidade de ram em megabytes para emular o dispositivo. Isso vale para todo o dispositivo, não apenas para um app específico instalado no dispositivo. O valor mínimo é 64 megabytes.
`screen_density`	`Integer; required` A densidade da tela emulada em pixels por polegada. O valor mínimo é 30 ppi.
`system_image`	`Label; required` Um grupo com os seguintes arquivos: system.img: a partição do sistema kernel-qemu: o kernel do Linux que o emulador carregará ramdisk.img: a imagem inicial a ser usada no momento da inicialização userdata.img: a partição inicial de dados do usuário source.properties: um arquivo de propriedade que contém informações sobre as imagens Esses arquivos fazem parte do SDK do Android ou são fornecidos por terceiros, como o Intel, que fornece imagens x86.
`vertical_resolution`	`Integer; required` A resolução vertical da tela em pixels para emular. O valor mínimo é 240.
`vm_heap`	`Integer; required` O tamanho em megabytes da heap de máquina virtual do Android será usado em 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 Android NDK com suporte à criação de destinos do Android com código nativo.

Essa implementação de android_ndk_repository está sendo substituída por uma implementação no Starlark. A compatibilidade com futuras versões do NDK, incluindo a versão 25 e mais recentes, vai ser implementada na versão Starlark do android_ndk_repository. Consulte rules_android_ndk para saber a versão do Starlark.

Observe que a criação para Android também exige uma regra android_sdk_repository no arquivo WORKSPACE.

Para saber mais, leia a documentação completa sobre como usar o Android NDK com o Bazel.

Exemplos

android_ndk_repository(
    name = "androidndk",
)

O exemplo acima localizará o Android NDK no $ANDROID_NDK_HOME e detectará o nível mais alto da API com suporte.

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

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

recursos da CPU

O Android NDK contém a biblioteca cpufeatures, que pode ser usada para detectar a CPU de um dispositivo no momento da execução. No exemplo a seguir, demonstramos como usar cpufeatures com Bazel.

# jni.cc
#include "ndk/sources/android/cpufeatures/cpu-features.h"
...

# BUILD
cc_library(
    name = "jni",
    srcs = ["jni.cc"],
    deps = ["@androidndk//:cpufeatures"],
)

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para esse destino.
`api_level`	`Integer; optional; nonconfigurable; default is 0` O nível da API do Android em que o build será criado. Se não for especificado, o nível de API mais alto instalado será usado.
`path`	`String; optional; nonconfigurable` 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 para desenvolvedores Android .
`repo_mapping`	`Dictionary: String -> String; optional` 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, a qualquer momento, esse repositório depende de `"@foo"` (como uma dependência em `"@foo//some:target"`), mas na verdade ele precisa resolver essa dependência dentro de `"@bar"` declarado `"@bar//some:target"` 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 o Bazel é colocar uma regra android_sdk_repository chamada "androidsdk" no seu arquivo WORKSPACE e definir a variável de ambiente $ANDROID_HOME como o caminho do SDK do Android. O Bazel usará o nível mais alto da API do Android e a versão das ferramentas de compilação instaladas no SDK do Android por padrão.

android_sdk_repository(
    name = "androidsdk",
)

Para garantir a criação de versões, os atributos path, api_level e build_tools_version podem ser definidos com valores específicos. O build falhará se o SDK do Android não tiver o nível de API especificado ou a versão das ferramentas de build instaladas.

android_sdk_repository(
    name = "androidsdk",
    path = "./sdk",
    api_level = 19,
    build_tools_version = "25.0.0",
)

O exemplo acima também usa um caminho relativo ao espaço de trabalho para o SDK do Android. Isso é útil se o SDK do Android faz parte do seu espaço de trabalho do Bazel (por exemplo, se for verificado no controle de versões).

Bibliotecas de Suporte

As Bibliotecas de Suporte estão disponíveis no Android SDK Manager como "Repositório de Suporte do Android". Esse é um conjunto de versões das bibliotecas comuns do Android, como as bibliotecas Support e AppCompat, que são empacotados como um repositório Maven local. android_sdk_repository gera destinos do Bazel para cada uma dessas bibliotecas que podem ser usadas nas dependências dos destinos android_binary e android_library.

Os nomes dos destinos gerados são derivados das coordenadas Maven das bibliotecas no Repositório de Suporte do Android, formatados como @androidsdk//${group}:${artifact}-${version}. O exemplo a seguir mostra como uma android_library pode depender da versão 25.0.0 da biblioteca appcompat v7.

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

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para esse destino.
`api_level`	`Integer; optional; nonconfigurable; default is 0` O nível da API do Android que será usado como padrão. Se não for especificado, o nível de API mais alto instalado será usado. O nível da API usado para um build específico 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}`, independentemente de esse atributo ser especificado ou não. Por exemplo, para compilar em um nível de API não padrão: `bazel build --android_sdk=@androidsdk//:sdk-19 //java/com/example:app`. Para ver todos os `android_sdk` destinos gerados por `android_sdk_repository`, execute `bazel query "kind(android_sdk, @androidsdk//...)"`.
`build_tools_version`	`String; optional; nonconfigurable` A versão das ferramentas de compilação do Android a serem usadas 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 compilação versão 30.0.0 ou posterior.
`path`	`String; optional; nonconfigurable` Um caminho absoluto ou relativo para um SDK do Android. É preciso definir esse atributo ou a variável de ambiente `$ANDROID_HOME`. É possível fazer o download do SDK Android no site para desenvolvedores Android.
`repo_mapping`	`Dictionary: String -> String; optional` 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, a qualquer momento, esse repositório depende de `"@foo"` (como uma dependência em `"@foo//some:target"`), mas na verdade ele precisa resolver essa dependência dentro de `"@bar"` declarado `"@bar//some:target"` globalmente.