Como usar o kit de desenvolvimento nativo do Android com o Bazel

Informar um problema Ver código-fonte

Nightly · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

Se você é novo no Bazel, comece com o tutorial Como criar apps Android com o Bazel.

Visão geral

O Bazel pode ser executado em muitas configurações de build diferentes, incluindo várias que usam o conjunto de ferramentas do Android Native Development Kit (NDK). Isso significa que as regras normais cc_library e cc_binary podem ser compiladas para Android diretamente no Bazel. O Bazel faz isso usando a regra de repositório android_ndk_repository.

Pré-requisitos

Verifique se você instalou o SDK e o NDK do Android.

Para configurar o SDK e o NDK, adicione o snippet a seguir ao seu WORKSPACE:

android_sdk_repository(
    name = "androidsdk", # Required. Name *must* be "androidsdk".
    path = "/path/to/sdk", # Optional. Can be omitted if `ANDROID_HOME` environment variable is set.
)

android_ndk_repository(
    name = "androidndk", # Required. Name *must* be "androidndk".
    path = "/path/to/ndk", # Optional. Can be omitted if `ANDROID_NDK_HOME` environment variable is set.
)

Para mais informações sobre a regra android_ndk_repository, consulte a entrada da Enciclopédia de build.

Início rápido

Para criar C++ para Android, basta adicionar cc_library dependências às regras android_binary ou android_library.

Por exemplo, considerando o seguinte arquivo BUILD para um app Android:

# In <project>/app/src/main/BUILD.bazel

cc_library(
    name = "jni_lib",
    srcs = ["cpp/native-lib.cpp"],
)

android_library(
    name = "lib",
    srcs = ["java/com/example/android/bazel/MainActivity.java"],
    resource_files = glob(["res/**/*"]),
    custom_package = "com.example.android.bazel",
    manifest = "LibraryManifest.xml",
    deps = [":jni_lib"],
)

android_binary(
    name = "app",
    deps = [":lib"],
    manifest = "AndroidManifest.xml",
)

Esse arquivo BUILD resulta no seguinte gráfico de destino:

Figura 1. Gráfico de build do projeto Android com dependências cc_library.

Para criar o app, basta executar:

bazel build //app/src/main:app

O comando bazel build compila os arquivos Java, os arquivos de recursos do Android e as regras cc_library além de empacotar tudo em um APK:

$ zipinfo -1 bazel-bin/app/src/main/app.apk
nativedeps
lib/armeabi-v7a/libapp.so
classes.dex
AndroidManifest.xml
...
res/...
...
META-INF/CERT.SF
META-INF/CERT.RSA
META-INF/MANIFEST.MF

O Bazel compila todas as cc_libraries em um único arquivo de objeto compartilhado (.so), direcionado para a armeabi-v7a ABI por padrão. Para mudar isso ou criar para várias ABIs ao mesmo tempo, consulte a seção sobre como configurar a ABI de destino.

Exemplo de configuração

Esse exemplo está disponível no repositório de exemplos do Bazel.

No arquivo BUILD.bazel, três destinos são definidos com as regras android_binary, android_library e cc_library.

O destino de nível superior android_binary cria o APK.

O destino cc_library contém um único arquivo de origem C++ com uma implementação de função JNI:

#include <jni.h>
#include <string>

extern "C"
JNIEXPORT jstring

JNICALL
Java_com_example_android_bazel_MainActivity_stringFromJNI(
        JNIEnv *env,
        jobject /* this */) {
    std::string hello = "Hello from C++";
    return env->NewStringUTF(hello.c_str());
}

O destino android_library especifica as origens Java, os arquivos de recursos e a dependência de um destino cc_library. Para este exemplo, MainActivity.java carrega o arquivo de objeto compartilhado libapp.so, e define a assinatura do método para a função JNI função:

public class MainActivity extends AppCompatActivity {

    static {
        System.loadLibrary("app");
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
       // ...
    }

    public native String stringFromJNI();

}

Observação: o nome da biblioteca nativa é derivado do nome do destino de nível superior android_binary. Neste exemplo, é app.

Como configurar a STL

Para configurar a STL do C++, use a flag --android_crosstool_top.

bazel build //:app --android_crosstool_top=target label

As STLs disponíveis em @androidndk são:

STL	Rótulo de destino
STLport	@androidndk//:toolchain-stlport
libc++	@androidndk//:toolchain-libcpp
gnustl	@androidndk//:toolchain-gnu-libstdcpp

Para r16 e versões anteriores, a STL padrão é gnustl. Para r17 e versões mais recentes, é libc++. Para sua conveniência, o destino @androidndk//:default_crosstool tem um alias para as STLs padrão respectivas.

A partir da versão r18, o STLport e o gnustl serão removidos, tornando libc++ a única STL no NDK.

Consulte a documentação do NDK para mais informações sobre essas STLs.

Como configurar a ABI de destino

Para configurar a ABI de destino, use a flag --fat_apk_cpu da seguinte maneira:

bazel build //:app --fat_apk_cpu=comma-separated list of ABIs

Por padrão, o Bazel cria código nativo do Android para armeabi-v7a. Para criar para x86 (como para emuladores), transmita --fat_apk_cpu=x86. Para criar um APK fat para várias arquiteturas, especifique várias CPUs: --fat_apk_cpu=armeabi-v7a,x86.

Se mais de uma ABI for especificada, o Bazel vai criar um APK contendo um objeto compartilhado para cada ABI.

Dependendo da revisão do NDK e do nível da API Android, as seguintes ABIs estão disponíveis:

Revisão do NDK	Interfaces binárias de aplicativo (ABIs, na sigla em inglês)
16 e versões anteriores	armeabi, armeabi-v7a, arm64-v8a, mips, mips64, x86, x86_64
17 e versões mais recentes	armeabi-v7a, arm64-v8a, x86, x86_64

Consulte os documentos do NDK para mais informações sobre essas ABIs.

Os APKs fat de várias ABIs não são recomendados para builds de lançamento, porque aumentam o tamanho do APK, mas podem ser úteis para builds de desenvolvimento e QA.

Como selecionar um padrão C++

Use as flags a seguir para criar de acordo com um padrão C++:

Padrão C++	Sinalização
C++98	Padrão, nenhuma flag necessária
C++11	--cxxopt=-std=c++11
C++14	--cxxopt=-std=c++14

Exemplo:

bazel build //:app --cxxopt=-std=c++11

Leia mais sobre como transmitir flags de compilador e vinculador com --cxxopt, --copt, e --linkopt no Manual do usuário.

As flags do compilador e do vinculador também podem ser especificadas como atributos em cc_library usando copts e linkopts. Exemplo:

cc_library(
    name = "jni_lib",
    srcs = ["cpp/native-lib.cpp"],
    copts = ["-std=c++11"],
    linkopts = ["-ldl"], # link against libdl
)

Integração com plataformas e conjuntos de ferramentas

O modelo de configuração do Bazel está migrando para plataformas e conjuntos de ferramentas. Se o build usar a flag --platforms para selecionar a arquitetura ou o sistema operacional para criar, será necessário transmitir a flag --extra_toolchains para o Bazel em ordem de usar o NDK.

Por exemplo, para integrar com o conjunto de ferramentas android_arm64_cgo fornecido por as regras do Go, transmita --extra_toolchains=@androidndk//:all além da --platforms flag.

bazel build //my/cc:lib \
  --platforms=@io_bazel_rules_go//go/toolchain:android_arm64_cgo \
  --extra_toolchains=@androidndk//:all

Também é possível registrá-los diretamente no arquivo WORKSPACE:

android_ndk_repository(name = "androidndk")
register_toolchains("@androidndk//:all")

O registro desses conjuntos de ferramentas informa ao Bazel para procurá-los no BUILD arquivo do NDK (para o NDK 20) ao resolver restrições de arquitetura e sistema operacional:

toolchain(
  name = "x86-clang8.0.7-libcpp_toolchain",
  toolchain_type = "@bazel_tools//tools/cpp:toolchain_type",
  target_compatible_with = [
      "@platforms//os:android",
      "@platforms//cpu:x86_32",
  ],
  toolchain = "@androidndk//:x86-clang8.0.7-libcpp",
)

toolchain(
  name = "x86_64-clang8.0.7-libcpp_toolchain",
  toolchain_type = "@bazel_tools//tools/cpp:toolchain_type",
  target_compatible_with = [
      "@platforms//os:android",
      "@platforms//cpu:x86_64",
  ],
  toolchain = "@androidndk//:x86_64-clang8.0.7-libcpp",
)

toolchain(
  name = "arm-linux-androideabi-clang8.0.7-v7a-libcpp_toolchain",
  toolchain_type = "@bazel_tools//tools/cpp:toolchain_type",
  target_compatible_with = [
      "@platforms//os:android",
      "@platforms//cpu:arm",
  ],
  toolchain = "@androidndk//:arm-linux-androideabi-clang8.0.7-v7a-libcpp",
)

toolchain(
  name = "aarch64-linux-android-clang8.0.7-libcpp_toolchain",
  toolchain_type = "@bazel_tools//tools/cpp:toolchain_type",
  target_compatible_with = [
      "@platforms//os:android",
      "@platforms//cpu:aarch64",
  ],
  toolchain = "@androidndk//:aarch64-linux-android-clang8.0.7-libcpp",
)

Como funciona: apresentando as transições de configuração do Android

A regra android_binary pode pedir explicitamente ao Bazel para criar dependências em uma configuração compatível com o Android para que o build do Bazel funcione sem flags especiais, exceto --fat_apk_cpu e --android_crosstool_top para configuração de ABI e STL.

Nos bastidores, essa configuração automática usa transições de configuração do Android configuration transitions.

Uma regra compatível, como android_binary, muda automaticamente a configuração das dependências para uma configuração do Android, de modo que apenas as subárvores específicas do Android do build sejam afetadas. Outras partes do gráfico de build são processadas usando a configuração de destino de nível superior. Ele pode até mesmo processar um único destino nas duas configurações, se houver caminhos no gráfico de build para oferecer suporte a isso.

Depois que o Bazel estiver em uma configuração compatível com o Android, especificada no nível superior ou devido a um ponto de transição de nível superior, outros pontos de transição encontrados não modificarão ainda mais a configuração.

O único local integrado que aciona a transição para a configuração do Android é o atributo android_binary's deps.

Observação: O atributo data de android_binary intencionalmente não aciona a transição. Além disso, android_local_test e android_library intencionalmente não acionam a transição.

Por exemplo, se você tentar criar um destino android_library com uma cc_library dependência sem flags, poderá encontrar um erro sobre um cabeçalho JNI ausente:

ERROR: project/app/src/main/BUILD.bazel:16:1: C++ compilation of rule '//app/src/main:jni_lib' failed (Exit 1)
app/src/main/cpp/native-lib.cpp:1:10: fatal error: 'jni.h' file not found
#include <jni.h>
         ^~~~~~~
1 error generated.
Target //app/src/main:lib failed to build
Use --verbose_failures to see the command lines of failed build steps.

O ideal é que essas transições automáticas façam com que o Bazel faça a coisa certa na maioria dos casos. No entanto, se o destino na linha de comando do Bazel já estiver abaixo de qualquer uma dessas regras de transição, como desenvolvedores de C++ que testam um cc_library, um --crosstool_top personalizado precisará ser usado.

Como criar uma cc_library para Android sem usar android_binary

Para criar um cc_binary ou cc_library independente para Android sem usar um android_binary, use as --crosstool_top, --cpu e --host_crosstool_top flags.

Exemplo:

bazel build //my/cc/jni:target \
      --crosstool_top=@androidndk//:default_crosstool \
      --cpu=<abi> \
      --host_crosstool_top=@bazel_tools//tools/cpp:toolchain

Neste exemplo, os destinos cc_library e cc_binary de nível superior são criados usando o conjunto de ferramentas do NDK. No entanto, isso faz com que as próprias ferramentas de host do Bazel sejam criadas com o conjunto de ferramentas do NDK (e, portanto, para Android), porque o conjunto de ferramentas do host é copiado do conjunto de ferramentas de destino. Para contornar esse problema, especifique o valor de --host_crosstool_top como @bazel_tools//tools/cpp:toolchain para definir explicitamente o conjunto de ferramentas C++ do host.

Com essa abordagem, toda a árvore de build é afetada.

Observação: todos os destinos na linha de comando precisam ser compatíveis com a criação para Android ao especificar estas flags, o que pode dificultar o uso de caracteres curinga do Bazel como /... e :all.

Essas flags podem ser colocadas em uma configuração bazelrc (uma para cada ABI), em project/.bazelrc:

common:android_x86 --crosstool_top=@androidndk//:default_crosstool
common:android_x86 --cpu=x86
common:android_x86 --host_crosstool_top=@bazel_tools//tools/cpp:toolchain

common:android_armeabi-v7a --crosstool_top=@androidndk//:default_crosstool
common:android_armeabi-v7a --cpu=armeabi-v7a
common:android_armeabi-v7a --host_crosstool_top=@bazel_tools//tools/cpp:toolchain

# In general
common:android_<abi> --crosstool_top=@androidndk//:default_crosstool
common:android_<abi> --cpu=<abi>
common:android_<abi> --host_crosstool_top=@bazel_tools//tools/cpp:toolchain

Em seguida, para criar um cc_library para x86, por exemplo, execute:

bazel build //my/cc/jni:target --config=android_x86

Em geral, use esse método para destinos de baixo nível (como cc_library) ou quando você souber exatamente o que está criando. Confie nas transições de configuração automática de android_binary para destinos de alto nível em que você espera criar muitos destinos que não controla.