Se você não conhece o Bazel, comece com o tutorial Como criar o Android com o Bazel.
Visão geral
O Bazel pode ser executado em várias configurações de build diferentes, incluindo várias que usam
o kit de ferramentas de desenvolvimento nativo do Android (NDK, na sigla em inglês). Isso significa que as regras cc_library
e cc_binary
normais podem ser compiladas para Android diretamente no
Bazel. O Bazel faz isso usando a regra do repositório
android_ndk_repository
.
Pré-requisitos
Confira se você instalou o SDK do Android e o NDK.
Para configurar o SDK e o NDK, adicione o seguinte snippet ao 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 do Build
Encyclopedia.
Início rápido
Para criar o C++ para Android, basta adicionar dependências cc_library
à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. Criar gráfico do projeto Android com dependências de 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
e empacota 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
),
segmentado para a ABI armeabi-v7a
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
Este 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 em um destino cc_library
. Neste exemplo, MainActivity.java
carrega
o arquivo de objeto compartilhado libapp.so
e define a assinatura do método para a função
JNI:
public class MainActivity extends AppCompatActivity {
static {
System.loadLibrary("app");
}
@Override
protected void onCreate(Bundle savedInstanceState) {
// ...
}
public native String stringFromJNI();
}
Como configurar a STL
Para configurar a STL C++, use a flag --android_crosstool_top
.
bazel build //:app --android_crosstool_top=target label
Os 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 facilitar, o @androidndk//:default_crosstool
de destino é
criado como alias para os STLs padrão.
A partir da r18, STLport e 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 grande 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 do Android, as seguintes ABIs estão disponíveis:
Revisão do NDK | Interfaces binárias de aplicativo (ABIs, na sigla em inglês) |
---|---|
16 anos ou menos | armeabi, armeabi-v7a, arm64-v8a, mips, mips64, x86, x86_64 |
17 anos ou mais | armeabi-v7a, arm64-v8a, x86, x86_64 |
Consulte as documentações do NDK para mais informações sobre essas ABIs.
APKs multiarquiteturas 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 controle de qualidade.
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, sem 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 do compilador e do 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á se movendo para
plataformas e
toolchains. Se o
build usar a flag --platforms
para selecionar a arquitetura ou o sistema operacional
para o build, será necessário transmitir a flag --extra_toolchains
para o Bazel
para usar o NDK.
Por exemplo, para integrar com a cadeia de ferramentas android_arm64_cgo
fornecida pelas
regras do Go, transmita --extra_toolchains=@androidndk//:all
além da
flag --platforms
.
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 dessas cadeias de ferramentas instrui o Bazel a procurar por elas no arquivo BUILD
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: introdução às transições de configuração do Android
A regra android_binary
pode pedir explicitamente ao Bazel para criar as dependências em
uma configuração compatível com o Android para que o build do Bazel apenas funcione sem
nenhuma flag especial, 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.
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
subárvores específicas do Android do build são afetadas. Outras partes do gráfico
de build são processadas usando a configuração de destino de nível superior. Ele pode até
processar um único destino nas duas configurações, se houver caminhos pelo
gráfico de build para oferecer suporte a isso.
Quando o Bazel está 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 modificam mais a configuração.
O único local integrado que aciona a transição para a configuração
do Android é o atributo deps
de android_binary
.
Por exemplo, se você tentar criar um destino android_library
com uma dependência cc_library
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 o Bazel fazer 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 C++ testando um cc_library
específico, será necessário usar um --crosstool_top
personalizado.
Como criar um cc_library
para Android sem usar android_binary
Para criar um cc_binary
ou cc_library
autônomo para Android sem usar um
android_binary
, use as flags
--crosstool_top
, --cpu
e --host_crosstool_top
.
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 a cadeia de ferramentas do NDK. No entanto, isso faz com que as ferramentas do host do Bazel sejam criadas
com o conjunto de ferramentas do NDK (e, portanto, para o 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 a cadeia de ferramentas C++ do host.
Com essa abordagem, toda a árvore de build é afetada.
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ê sabe 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.