As inscrições para a BazelCon 2024 já estão abertas.

Esta página foi traduzida pela API Cloud Translation.

Regras do Android

Report an issue View source Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Regras

android_binary
aar_import
android_library
android_instrumentation_test
android_local_test
android_device
android_ndk_repository
android_sdk_repository

android_binary

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

Alvos de saída implícitos

name.apk: um arquivo de pacote de app Android assinado com chaves de depuração e alinhado a ZIP. Ele pode ser usado para desenvolver e depurar seu aplicativo. Não é possível lançar o app quando ele é 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 do deploy contém todas as classes que seriam encontradas por um carregador de classes que pesquisou o caminho de classe do ambiente 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á 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ó é gerada 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 que serão vinculadas ao destino binário. Os tipos de biblioteca permitidos são: `android_library`, `java_library` com restrição `android` e `cc_library` que envolve ou produz bibliotecas nativas `.so` para a plataforma de destino do Android.
`srcs`	Lista de rótulos; o padrão é `[]` A lista de arquivos de origem 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 no `srcs`. Em vez disso, coloque o nome da regra em que se depende no `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 extensão de build ou genrule.
`assets`	Lista de rótulos; o padrão é `[]` 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 produz 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 fornece o caminho para os arquivos em `assets`. O par `assets` e `assets_dir` descreve os recursos empacotados, e ambos os atributos precisam ser fornecidos ou nenhum deles.
`crunch_png`	Booleano; o padrão é `True` Fazer o processamento de PNG (ou não). Isso é independente do processamento de nove retângulos, que é sempre feito. Esta é uma solução alternativa descontinuada para um bug do aapt que foi corrigido no aapt2.
`custom_package`	String; o padrão é `""` Pacote Java para o qual as fontes Java serão geradas. Por padrão, o pacote é inferido do diretório em que o arquivo BUILD contém a regra. É possível especificar um pacote diferente, mas isso é altamente desencorajado, já que pode causar conflitos de classpath com outras bibliotecas que só serão detectadas no momento 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, você não quer usar uma chave diferente da padrão. Portanto, esse atributo precisa ser omitido. AVISO: não use as chaves de produção. Elas precisam ser protegidas estritamente e não podem ser mantidas na árvore de origem.
`debug_signing_keys`	Lista de rótulos; o padrão é `[]` Lista de arquivos e keystores de depuração que serão usados para assinar o APK de depuração. Normalmente, você não quer usar chaves diferentes da chave padrão. Portanto, esse atributo precisa ser omitido. AVISO: não use as chaves de produção. Elas precisam ser protegidas estritamente 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, você não quer usar chaves diferentes da chave padrão. Portanto, esse atributo precisa ser omitido. AVISO: não use as chaves de produção. Elas precisam ser protegidas estritamente 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 vai remover os recursos drawable raster que não seriam carregados por um dispositivo com as densidades de tela especificadas para reduzir o tamanho do APK. Uma seção correspondente de telas compatíveis também será adicionada ao manifesto se ele ainda não tiver uma lista de superconjuntos.
`dex_shards`	Inteiro; padrão é `1` Número de fragmentos de decomposição. Isso torna a dexagem muito mais rápida em detrimento da instalação e do tempo de inicialização do app. Quanto maior o binário, mais fragmentos precisam ser usados. 25 é um bom valor para começar a fazer experimentos. Cada fragmento resulta em pelo menos uma 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 é `[]`. Outras flags de linha de comando para a ferramenta dx ao gerar classes.dex. Sujeito à substituição de "Make variable" e tokenização de shell Bourne.
`enable_data_binding`	Booleano; o padrão é `False` Se for verdadeiro, essa regra processa 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, também é necessário fazer o seguinte: Defina esse atributo para todas as regras do Android que dependem transitivamente dessa regra. Isso ocorre porque as dependências herdam as expressões de vinculação de dados da regra pela mesclagem de recursos. Portanto, eles também precisam criar com vinculação de dados para analisar essas expressões. Foi adicionada uma entrada `deps =` para a biblioteca de tempo de execução de vinculação de dados a todos os destinos que definem esse atributo. A localização dessa biblioteca depende da configuração do depósito.
`incremental_dexing`	Inteiro; não configurável; padrão é `-1` Forçar a criação do destino com ou sem dexagem incremental, substituindo os padrões e a flag --incremental_dexing.
`instruments`	Rótulo: o padrão é `None`. O alvo `android_binary` a ser implementado. 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 esse destino. Sujeito à substituição de "Make variable" e tokenização de 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) em que a chave de assinatura alternada de um APK precisa ser 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 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`	Lista de strings. O padrão é `[]`. Opções de linha de comando para transmitir ao criador de lista dex principal. Use essa opção para afetar as classes incluídas na lista 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 forem 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 a "name" 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 por `applicationId`, se especificado, ou pelo pacote no manifesto. Quando `manifest_merger` é definido como `legacy`, apenas `applicationId`, `versionCode` e `versionName` terão efeito.
`multidex`	String; o padrão é `"native"` Se o código será dividido em vários arquivos dex. Valores possíveis: `native`: divide o código em vários arquivos dex quando o limite de índice dex de 64K é excedido. Assume o suporte da plataforma nativa para carregar classes multidex no momento da 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 dex de 64K é excedido. Assume que as classes multidex são carregadas pelo código do aplicativo (ou seja, sem suporte à plataforma nativa). `manual_main_dex`: divide o código em vários arquivos dex quando o limite de índice dex 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 exceda o limite de índice.
`nocompress_extensions`	Lista de strings. O padrão é `[]`. Uma lista de extensões de arquivo para deixar descompactadas no APK.
`package_id`	Inteiro; 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. Isso pode (e precisa) ser deixado indefinido, resultando no valor padrão de 127 (`0x7F`).
`plugins`	Lista de rótulos; o padrão é `[]` Plug-ins de compilador Java para execução no tempo de compilação. Cada `java_plugin` especificado no atributo de plug-ins será executado sempre que esse destino for criado. Os recursos gerados pelo plug-in serão incluídos no jar do resultado da meta.
`proguard_apply_dictionary`	Rótulo: o padrão é `None`. Arquivo a ser usado como um mapeamento para o Proguard. Um arquivo separado por linha 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 por `proguard_generate_mapping` para ser reutilizado para aplicar o mesmo mapeamento a um novo build.
`proguard_generate_mapping`	Booleano; não configurável; o padrão é `False` Se o arquivo de mapeamento do Proguard 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 da classe, do método e do campo. 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 vai descrever o conjunto de especificações que serão 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 aos que estão na configuração "en". Para ativar a pseudolocalização, inclua as `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 Label. 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`	Inteiro; padrão é `-1` Se a redução de recursos será realizada. Os recursos que não são usados pelo binário são removidos do APK. Isso só é compatível com regras que usam recursos locais (por exemplo, os atributos `manifest` e `resource_files`) e exige o ProGuard. Ele opera da mesma maneira que o compressor de recursos do Gradle (https://developer.android.com/studio/build/shrink-code.html#shrink-resources). Diferenças significativas: Os recursos em `values/` serão removidos, assim como os recursos baseados em arquivos usa `strict mode` por padrão A remoção de recursos de ID não utilizados só é compatível com o aapt2. Se a redução de recursos estiver ativada, `name_files/resource_shrinker.log` também será gerado, detalhando a análise e as exclusões realizadas. Valores possíveis: `shrink_resources = 1`: ativa o recurso de redução de recursos do Android. `shrink_resources = 0`: desativa o encolhimento de recursos do Android `shrink_resources = -1`: a redução é controlada pela flag --android_resource_shrinking.

aar_import

Acessar a origem da regra

aar_import(name, deps, data, aar, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, licenses, restricted_to, srcjar, tags, target_compatible_with, testonly, visibility)

Essa regra permite o uso de arquivos .aar como bibliotecas para android_library e android_binary.

Exemplos

    aar_import(
        name = "google-vr-sdk",
        aar = "gvr-android-sdk/libraries/sdk-common-1.10.0.aar",
    )

    android_binary(
        name = "app",
        manifest = "AndroidManifest.xml",
        srcs = glob(["**.java"]),
        deps = [":google-vr-sdk"],
    )

Argumentos

Atributos
`name`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`aar`	Rótulo: obrigatório O arquivo `.aar` a ser fornecido às plataformas de destino do Android que dependem dessa plataforma.
`exports`	Lista de rótulos; o padrão é `[]` Destinos para exportar para regras que dependem dela. 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

Acessar a 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 ambiente de execução do Android android.jar é colocada implicitamente no caminho da classe de compilação.

Alvos de saída implícitos

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

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. Deixe //java/bazel/helloandroid/BUILD conter:

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 para vincular. Os tipos de biblioteca permitidos são: `android_library`, `java_library` com restrição `android` e `cc_library` que envolve ou produz bibliotecas nativas `.so` para a plataforma de destino do Android.
`srcs`	Lista de rótulos; o padrão é `[]` A lista de arquivos `.java` ou `.srcjar` que são processados para criar o destino. 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 no `srcs`. Em vez disso, coloque o nome da regra de dependência no `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 extensão de build ou genrule. 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 é `[]` 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 produz 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 fornece o caminho para os arquivos em `assets`. O par `assets` e `assets_dir` descreve os recursos empacotados, e ambos os atributos precisam ser fornecidos ou nenhum deles.
`custom_package`	String; o padrão é `""` Pacote Java para o qual as fontes Java serão geradas. Por padrão, o pacote é inferido do diretório em que o arquivo BUILD contém a regra. É possível especificar um pacote diferente, mas isso é altamente desencorajado, já que pode causar conflitos de classpath com outras bibliotecas que só serão detectadas no momento de execução.
`enable_data_binding`	Booleano; o padrão é `False` Se for verdadeiro, essa regra processa 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, também é necessário fazer o seguinte: Defina esse atributo para todas as regras do Android que dependem transitivamente dessa regra. Isso ocorre porque as dependências herdam as expressões de vinculação de dados da regra pela mesclagem de recursos. Portanto, eles também precisam criar com vinculação de dados para analisar essas expressões. Foi adicionada uma entrada `deps =` para a biblioteca de tempo de execução de vinculação de dados a todos os destinos que definem esse atributo. A localização dessa biblioteca depende da configuração do depósito.
`exported_plugins`	Lista de rótulos; o padrão é `[]` A lista de `java_plugin`s (por exemplo, processadores de anotações) a serem exportadas para bibliotecas que dependem diretamente dessa biblioteca. A lista especificada de `java_plugin`s 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 dependências diretas 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`	Inteiro; padrão é `1` Define se as entradas do manifesto serão exportadas para destinos `android_binary` que dependem desse destino. Os atributos `uses-permissions` nunca são exportados.
`idl_import_root`	String; o padrão é `""` Caminho relativo ao pacote da raiz da árvore de pacotes Java que contém origens idl incluídas nesta biblioteca. Esse caminho será usado como raiz de importação ao processar origens 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 eles 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 do IDL do Android a serem fornecidas como importações. Esses arquivos serão disponibilizados como importações para qualquer `android_library` que dependa dessa biblioteca, diretamente ou pelo fechamento transitivo, mas não serão traduzidos para Java e nem compilados. Somente arquivos `.aidl` que correspondem diretamente às fontes `.java` nesta biblioteca precisam ser incluídos (por exemplo, implementações personalizadas de Parcelable). Caso contrário, o `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 saber o que isso significa.
`idl_preprocessed`	Lista de rótulos; o padrão é `[]` Lista de definições de IDL do Android pré-processadas para fornecer como importações. Esses arquivos serão disponibilizados como importações para qualquer `android_library` que dependa dessa biblioteca, diretamente ou pelo fechamento transitivo, mas não serão traduzidos para Java e nem compilados. Somente arquivos `.aidl` pré-processados que correspondem diretamente às origens `.java` nesta 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 use `idl_parcelable` para arquivos AIDL não pré-processados.
`idl_srcs`	Lista de rótulos; o padrão é `[]` Lista de definições do IDL do Android a serem traduzidas para interfaces Java. Depois que as interfaces Java forem geradas, elas serão compiladas com o conteúdo de `srcs`. Esses arquivos serão disponibilizados como importações para qualquer destino `android_library` que dependa dessa biblioteca, diretamente ou 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 saber o que isso significa.
`javacopts`	Lista de strings. O padrão é `[]`. Opções extras do compilador para esse destino. Sujeito à substituição de "Make variable" e tokenização de 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 forem definidos.
`neverlink`	Booleano; o padrão é `False` Use essa biblioteca apenas para compilação, e não no momento da execução. As saídas de uma regra marcada como `neverlink` não serão usadas na criação de `.apk`. Útil se a biblioteca for fornecida pelo ambiente de execução durante a execução.
`plugins`	Lista de rótulos; o padrão é `[]` Plug-ins de compilador Java para execução no tempo de compilação. Cada `java_plugin` especificado no atributo de plug-ins será executado sempre que esse destino for criado. Os recursos gerados pelo plug-in serão incluídos no jar do resultado da meta.
`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 que serão usados pelo Proguard. Se especificado, 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 mesclagens 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 Label. 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

Acessar a origem da regra

android_instrumentation_test(name, data, args, compatible_with, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, licenses, local, restricted_to, shard_count, size, support_apks, tags, target_compatible_with, target_device, test_app, testonly, timeout, toolchains, visibility)

Uma regra android_instrumentation_test executa testes de instrumentação do Android. Ele vai iniciar um emulador, instalar o aplicativo que está sendo testado, o aplicativo de teste e todos os outros aplicativos necessários e executar os testes definidos no pacote de teste.

O atributo test_app especifica o android_binary que contém o teste. Esse android_binary, por sua vez, especifica o aplicativo android_binary em teste 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 será executado. Para executar o teste em um emulador que já está em execução ou em um dispositivo físico, use estes argumentos: `--test_output=streamed --test_arg=--device_broker_type=LOCAL_ADB_SERVER --test_arg=--device_serial_number=$device_identifier`
`test_app`	Rótulo: obrigatório O destino android_binary que contém as classes de teste. O destino `android_binary` precisa especificar qual destino está sendo testado pelo atributo `instruments`.

android_local_test

Acessar a origem da regra

android_local_test(name, deps, srcs, data, args, compatible_with, custom_package, densities, deprecation, enable_data_binding, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, licenses, local, manifest, manifest_values, nocompress_extensions, plugins, resource_configuration_filters, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, visibility)

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

Alvos de saída implícitos

name.jar: um arquivo Java do teste.
name-src.jar: um arquivo que contém as origens ("jar de origem").
name_deploy.jar: um arquivo de implantação Java adequado para implantação (somente criado 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. Em seguida, cada regra android_local_test precisa depender de @robolectric//bazel:robolectric. Confira o exemplo abaixo.

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

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

Argumentos

Atributos
`name`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`deps`	Lista de rótulos; o padrão é `[]` A lista de bibliotecas a serem testadas, bem como outras bibliotecas 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 que são 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 no `srcs`. Em vez disso, coloque o nome da regra de dependência no `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 extensão de build ou genrule. 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 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 está o arquivo BUILD que contém a regra. Se você usar esse atributo, provavelmente também precisará usar `test_class`.
`densities`	Lista de strings. O padrão é `[]`. Densidades para filtrar ao criar o APK. Uma seção correspondente de telas compatíveis também será adicionada ao manifesto se ele ainda não tiver um superconjunto de StarlarkListing.
`enable_data_binding`	Booleano; o padrão é `False` Se for verdadeiro, essa regra processa as referências de vinculação de dados usadas em dependências ativadas de 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 causar falhas de build.
`javacopts`	Lista de strings. O padrão é `[]`. Opções extras do compilador para esta biblioteca. Sujeito à substituição de "Make variable" e tokenização de 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 para incorporar no script de wrapper gerado para executar esse binário. Sujeito a $(location) e "Make variable" substituição e tokenização de shell Bourne. O script wrapper para um binário Java inclui uma definição de CLASSPATH (para encontrar todos os jars dependentes) e invoca o interpretador Java correto. A linha de comando gerada pelo script 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 que o nome da classe seja listado. 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 forem definidos ou se algum dos manifestos das bibliotecas em teste tiver uma tag `minSdkVersion`.
`manifest_values`	Dicionário: String -> String; o padrão é `{}` Um dicionário de valores a serem substituídos no manifesto. Qualquer instância de ${name} no manifesto será substituída pelo valor correspondente 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 por `applicationId`, se especificado, ou pelo pacote no manifesto. Não é necessário ter um manifesto na regra para usar manifest_values.
`nocompress_extensions`	Lista de strings. O padrão é `[]`. Uma lista de extensões de arquivo que não serão compactadas no APK de recursos.
`plugins`	Lista de rótulos; o padrão é `[]` Plug-ins de compilador Java para execução no tempo de compilação. Cada `java_plugin` especificado neste atributo será executado sempre que essa regra for criada. Uma biblioteca também pode herdar plug-ins de dependências que usam `exported_plugins`. Os recursos gerados pelo plug-in serão incluídos no jar resultante dessa regra.
`resource_configuration_filters`	Lista de strings. O padrão é `[]`. Uma lista de filtros de configuração de recursos, como "en", que limita os recursos no apk apenas aos que estão na configuração "en".
`resource_jars`	Lista de rótulos; o padrão é `[]` 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 é removido de todos os arquivos no atributo `resources`. É um erro um arquivo de recurso não estar nesse diretório. Se não for especificado (padrão), o caminho do arquivo de recurso será determinado de acordo com a mesma lógica do pacote Java de arquivos de origem. Por exemplo, um arquivo de origem em `stuff/java/foo/bar/a.txt` será localizado em `foo/bar/a.txt`.
`runtime_deps`	Lista de rótulos; o padrão é `[]` Bibliotecas para disponibilizar ao binário final ou testar apenas no momento da execução. Como o `deps` comum, elas vão aparecer no caminho de classe de execução, mas, ao contrário delas, não no caminho de classe de tempo de compilação. As dependências necessárias apenas no tempo de execução precisam ser listadas aqui. As ferramentas de análise de dependência precisam ignorar os destinos que aparecem em `runtime_deps` e `deps`.
`stamp`	Inteiro; padrão é `0` Define se as informações de build serão codificadas no binário. Valores possíveis: `stamp = 1`: sempre carimbe as informações do build no binário, mesmo em `--nostamp`. Evite essa configuração, porque ela pode interromper o armazenamento em cache remoto do binário e de qualquer ação downstream que dependa dele. `stamp = 0`: sempre substitua as informações de build por valores constantes. Isso gera um bom cache de resultados de build. `stamp = -1`: a incorporação de informações de build é controlada pela flag `--[no]stamp`. Os binários carimbados não são reconstruídos, a menos que as dependências mudem.
`test_class`	String; o padrão é `""` A classe Java que será carregada pelo executor de testes. Esse atributo especifica o nome de uma classe Java a ser executada por este 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 ser anotada com `org.junit.runner.RunWith`.
`use_launcher`	Booleano; o padrão é `True` Indica se o binário precisa usar um iniciador personalizado. Se esse atributo for definido como falso, o atributo launcher e a flag `--java_launcher` serão ignorados para esse destino.

android_device

Acessar a 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 Android configurado com as especificações especificadas. Esse emulador pode ser iniciado por um comando de execução do Bazel ou executando o script gerado diretamente. Recomendamos que você dependa das regras do android_device em vez de definir as suas.

Essa regra é um destino adequado para a flag --run_under para teste e execução do Bazel. 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 oferece suporte à criação de imagens KVM se a system_image subjacente for baseada em X86 e estiver otimizada para, no máximo, a arquitetura de CPU I686. Para usar a KVM, adicione tags = ['requires-kvm'] à regra android_device.

Alvos de saída implícitos

name_images/userdata.dat: contém arquivos de imagem e snapshots para iniciar o emulador
name_images/emulator-meta-data.pb: contém informações serializadas necessárias para transmitir ao emulador 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, essa é a porta que você vai usar para conectar o adb.
--emulator_port: a porta para expor o console de gerenciamento de telnet do emulador.
--enable_display: inicia o emulador com uma tela se for verdadeiro (padrão é falso).
--action: start ou kill.
--apks_to_install: uma lista de APKs a serem instalados no emulador.

Argumentos

Atributos
`name`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`cache`	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 melhor o emulador para que ele pareça mais um dispositivo real (controlando especificamente 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 neste arquivo vão substituir as propriedades somente leitura normalmente definidas pelo emulador, como ro.product.model.
`horizontal_resolution`	Inteiro; obrigatório A resolução da tela horizontal 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 no momento da inicialização.
`ram`	Inteiro; obrigatório A quantidade de RAM em megabytes a ser emulada para o dispositivo. Isso vale para todo o dispositivo, não apenas para um app específico instalado nele. O valor mínimo é de 64 megabytes.
`screen_density`	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 no momento da inicialização userdata.img: a partição userdata inicial source.properties: um arquivo de propriedades com 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`	Inteiro; obrigatório A resolução vertical da tela em pixels a ser emulada. O valor mínimo é 240.
`vm_heap`	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 MB.

android_ndk_repository

Acessar a 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 no Starlark. O suporte a versões futuras do NDK, incluindo a versão 25 e mais recentes, será implementado na versão do Starlark de android_ndk_repository. Consulte rules_android_ndk para conferir a versão do Starlark.

O build 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 localiza o NDK do Android a partir de $ANDROID_NDK_HOME e detecta o nível mais alto da API com suporte.

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

O exemplo acima vai usar o Android NDK localizado no espaço de trabalho em ./android-ndk-r20. Ele 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 momento da 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`	Inteiro; não configurável; padrão é `0` O nível da API do Android para o qual o build será criado. 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 NDK do Android. É necessário definir este atributo ou a variável de ambiente `$ANDROID_NDK_HOME`. O Android NDK pode ser baixado no site para desenvolvedores do Android .
`repo_mapping`	Dicionário: String -> String; o padrão é `{}` Um dicionário do nome do repositório local para o nome do repositório global. Isso permite o controle 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 esse repositório depende de `"@foo"` (como uma dependência de `"@foo//some:target"`), ele precisa resolver essa dependência no `"@bar"` declarado globalmente (`"@bar//some:target"`).

android_sdk_repository

Acessar a origem da regra

android_sdk_repository(name, api_level, build_tools_version, path, repo_mapping)

Configura o Bazel para usar um SDK local do Android 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 arquivo WORKSPACE e definir a variável de ambiente $ANDROID_HOME para o caminho do SDK do Android. O Bazel vai usar o nível de API mais alto do Android e a versão das ferramentas de build instalada no SDK do Android por padrão.

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 especificada instalada.

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

O exemplo acima também demonstra o uso de um caminho relativo ao espaço de trabalho para o SDK do Android. Isso é útil se o SDK do Android 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 Support 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 de destinos android_binary e android_library.

Os nomes dos destinos gerados são derivados das coordenadas do Maven das bibliotecas no Repositório de Suporte do Android, formatado como @androidsdk//${group}:${artifact}-${version}. O exemplo a seguir mostra como um android_library pode depender da versão 25.0.0 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`	Inteiro; não configurável; 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 para um determinado build 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}`, mesmo que esse atributo não seja especificado. Por exemplo, para criar com um nível de API que não seja padrão: `bazel build --android_sdk=@androidsdk//:sdk-19 //java/com/example:app`. Para conferir todos os destinos `android_sdk` gerados por `android_sdk_repository`, execute `bazel query "kind(android_sdk, @androidsdk//...)"`.
`build_tools_version`	String; não configurável; o padrão é `""` A versão das ferramentas de build do Android a serem usadas no SDK do Android. Se não for especificado, a versão mais recente das ferramentas de build instalada será usada. O Bazel requer a versão 30.0.0 ou mais recente das ferramentas de build.
`path`	String; não configurável; o padrão é `""` Um caminho absoluto ou relativo para um SDK do Android. É necessário definir este atributo ou a variável de ambiente `$ANDROID_HOME`. O SDK do Android pode ser baixado do site para desenvolvedores do Android.
`repo_mapping`	Dicionário: String -> String; o padrão é `{}` Um dicionário do nome do repositório local para o nome do repositório global. Isso permite o controle 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 esse repositório depende de `"@foo"` (como uma dependência de `"@foo//some:target"`), ele precisa resolver essa dependência no `"@bar"` declarado globalmente (`"@bar//some:target"`).