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.

Geral

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

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. Por exemplo:

APP_ABI := armeabi-v7a arm64-v8a x86
    

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

APP_ASFLAGS

Sinalizadores que serão passados para o assembler de cada arquivo de origem de montagem (arquivos .s e .S) no projeto.

APP_ASMFLAGS

Sinalizadores que serão passados para YASM para todos os arquivos de origem YASM (apenas .asm, x86/x86_64).

APP_BUILD_SCRIPT

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

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

APP_CFLAGS

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

Veja também: APP_CONLYFLAGS, APP_CPPFLAGS.

APP_CLANG_TIDY

Defina como "true" para ativar o clang-tidy para todos os módulos no projeto. Desativado 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++.

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

Veja também: APP_CFLAGS, APP_CONLYFLAGS.

APP_CXXFLAGS

Idêntico ao APP_CPPFLAGS, mas aparecerá depois de APP_CPPFLAGS no comando de compilação. Por 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 existir.

APP_MODULES

Uma lista explícita de módulos a serem compilados. 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 compilados pelo ndk-build. Bibliotecas estáticas só serão compiladas se forem usadas pelo projeto, se o projeto 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 rastreamentos de pilha podem não ser confiáveis).

A declaração de android:debuggable na tag <application> do manifesto do app fará com que essa variável seja padronizada 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 o app foi compilado e corresponde ao minSdkVersion do app.

Se não for especificado, o ndk-build segmentará o 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 à do Android 4.1 (API nível 16) e não podem ser usadas 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 build.gradle de módulo. 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:

  1. A versão da plataforma correspondente a APP_PLATFORM
  2. O próximo nível de API disponível abaixo de APP_PLATFORM. Por exemplo, android-19 será usado quando APP_PLATFORM for android-20, uma vez que não havia novas APIs nativas em android-20
  3. 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.

O STL system é usado por padrão. Outras opções são c++_shared, c++_static e none. Consulte Tempos de execução e recursos do NDK.

APP_STRIP_MODE

O argumento que será passado para strip para os módulos neste app. O 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.

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