Esta página foi traduzida pela API Cloud Translation.

Application.mk

Este documento explica o arquivo de compilação Application.mk usado por ndk-build.

Recomendamos que você leia a página Conceitos antes desta.

Visão geral

O Application.mk especifica as configurações para todo o projeto do ndk-build. Por padrão, ele está localizado em jni/Application.mk, no diretório do projeto do seu app.

Variáveis

APP_ABI

Por padrão, o sistema de compilação NDK gera um código para todas as ABIs que não estão obsoletas. É possível usar a configuração APP_ABI para gerar código para ABIs específicas. A Tabela 1 mostra as configurações APP_ABI para diferentes conjuntos de instruções.

Tabela 1. Configurações APP_ABI para diferentes conjuntos de instruções.

Conjunto de instruções	Valor
ARMv7 de 32 bits	`APP_ABI := armeabi-v7a`
ARMv8 de 64 bits (AArch64)	`APP_ABI := arm64-v8a`
x86	`APP_ABI := x86`
x86-64	`APP_ABI := x86_64`
Todas as ABIs compatíveis (padrão)	`APP_ABI := all`

Você também pode especificar diversos valores colocando-os na mesma linha, delimitados por espaços. Exemplo:

APP_ABI := armeabi-v7a arm64-v8a x86

Para ver uma lista de todas as ABIs compatíveis, além de detalhes sobre uso e limitações, consulte ABIs do Android.

APP_ASFLAGS

Sinalizações a serem passadas para o assembler para cada arquivo de origem do assembly (arquivos .s e .S) no projeto.

APP_ASMFLAGS

Sinalizações a serem passadas para YASM, para todos os arquivos de origem YASM (apenas .asm, x86/x86_64).

APP_BUILD_SCRIPT

Por padrão, o ndk-build considera que o Android.mk está localizado em jni/Android.mk em relação à raiz do projeto.

Para carregar um arquivo Android.mk de um local diferente, defina APP_BUILD_SCRIPT como caminho absoluto do arquivo Android.mk.

APP_CFLAGS

Sinalizações que serão passadas para todas as compilações C/C++ no projeto.

Consulte também: APP_CONLYFLAGS, APP_CPPFLAGS.

APP_CLANG_TIDY

Defina como "true" para ativar o clang-tidy para todos os módulos no projeto. Desativada por padrão.

APP_CLANG_TIDY_FLAGS

Sinalizações que serão passadas para todas as execuções clang-tidy no projeto.

APP_CONLYFLAGS

Sinalizações que serão passadas para todas as compilações C no projeto. Essas sinalizações não serão usadas para códigos C++.

Consulte também: APP_CFLAGS, APP_CPPFLAGS.

APP_CPPFLAGS

Sinalizações que serão passadas para todas as compilações C++ no projeto. Essas sinalizações não serão usadas para códigos C.

Consulte também: APP_CFLAGS, APP_CONLYFLAGS.

APP_CXXFLAGS

Idêntico ao APP_CPPFLAGS, mas aparecerá depois de APP_CPPFLAGS no comando de compilação. Exemplo:

APP_CPPFLAGS := -DFOO
APP_CXXFLAGS := -DBAR

A configuração acima resultará em um comando de compilação semelhante a clang++ -DFOO -DBAR em vez de clang++ -DBAR -DFOO.

APP_DEBUG

Defina como "true" para compilar um app depurável.

APP_LDFLAGS

Sinalizações que serão passadas ao vincular executáveis e bibliotecas compartilhadas.

APP_MANIFEST

Caminho absoluto para um arquivo AndroidManifest.xml.

Por padrão, $(APP_PROJECT_PATH)/AndroidManifest.xml) será usado, se ele existir.

APP_MODULES

Uma lista explícita de módulos a serem criados. Os elementos dessa lista são os nomes dos módulos conforme exibido em LOCAL_MODULE, no arquivo Android.mk.

Por padrão, todas as bibliotecas compartilhadas, executáveis e as dependências correspondentes serão compiladas pelo ndk-build. Bibliotecas estáticas só serão compiladas se forem usadas pelo projeto, se ele tiver apenas bibliotecas estáticas ou se estiverem nomeadas no APP_MODULES.

APP_OPTIM

Defina essa variável opcional como release ou debug. Os binários de lançamento serão compilados por padrão.

O modo de lançamento permite que haja otimizações e pode produzir binários incompatíveis com um depurador. O modo de depuração desativa as otimizações, de modo que depuradores possam ser usados.

Observe que você pode depurar binários de lançamento ou de depuração. No entanto, os binários de lançamento fornecem menos informações durante a depuração. Por exemplo, as variáveis podem ser otimizadas, evitando inspeção. Além disso, a reorganização do código pode dificultar a análise dele. Os stack traces podem não ser confiáveis.

Declarar android:debuggable na tag <application> do manifesto do app fará com que essa variável seja definida como debug em vez de release. Substitua esse valor padrão definindo APP_OPTIM como release.

APP_PLATFORM

APP_PLATFORM declara o nível da API do Android em que este app é compilado e corresponde ao minSdkVersion.

Se não for especificado, o ndk-build será destinado ao nível mínimo de API compatível com o NDK. O nível mínimo de API compatível com o NDK mais recente sempre será baixo o suficiente para ser compatível com quase todos os dispositivos ativos.

Por exemplo, um valor de android-16 especifica que sua biblioteca usa APIs que não estão disponíveis em versões anteriores ao Android 4.1 (API de nível 16) e não pode ser usada em dispositivos com uma versão de plataforma anterior. Para ver a lista completa de nomes de plataformas e imagens de sistema Android correspondentes, consulte APIs nativas do Android NDK.

Ao usar o Gradle e externalNativeBuild, esse parâmetro não pode ser definido diretamente. Em vez disso, defina a propriedade minSdkVersion nos blocos defaultConfig ou productFlavors do seu arquivo de módulo build.gradle. Desse modo, sua biblioteca será usada somente por apps instalados em dispositivos com as versões adequadas do Android.

O NDK não contém bibliotecas para cada nível de API do Android. Versões que não incluíam novas APIs nativas são omitidas para economizar espaço no NDK. O ndk-build usa, em ordem decrescente de preferência:

A versão da plataforma correspondente a APP_PLATFORM
O próximo nível de API disponível anterior a APP_PLATFORM. Por exemplo, android-19 será usado quando APP_PLATFORM for android-20, já que não havia novas APIs nativas no android-20.
O nível mínimo de API compatível com o NDK

APP_PROJECT_PATH

O caminho absoluto do diretório raiz do projeto.

APP_SHORT_COMMANDS

O equivalente do projeto a LOCAL_SHORT_COMMANDS. Para mais informações, consulte a documentação de LOCAL_SHORT_COMMANDS em Android.mk.

APP_STL

A biblioteca padrão C++ que será usada para este app.

A STL system é usada por padrão. Outras opções são c++_shared, c++_static e none. Consulte Recursos e tempos de execução C++ do NDK.

APP_STRIP_MODE

O argumento a ser passado para strip para módulos neste app. O valor padrão é --strip-unneeded. Para evitar a remoção de todos os binários no módulo, defina como none. Para ver outros módulos desse tipo, veja a documentação de remoção (link em inglês).

APP_THIN_ARCHIVE

Defina como "true" para usar arquivos dinâmicos em todas as bibliotecas estáticas no projeto. Para mais informações, consulte a documentação de LOCAL_THIN_ARCHIVE em Android.mk.

APP_WRAP_SH

Caminho para o arquivo wrap.sh que será incluído neste app.

Existe uma variante dessa variável para cada ABI, assim como uma variante de ABI genérica:

APP_WRAP_SH
APP_WRAP_SH_armeabi-v7a
APP_WRAP_SH_arm64-v8a
APP_WRAP_SH_x86
APP_WRAP_SH_x86_64