Application.mk

En este documento, se explica el archivo de compilación Application.mk que usa ndk-build.

Te recomendamos que primero leas la página Conceptos.

Descripción general

En el archivo Application.mk, se especifica la configuración de ndk-build para todo el proyecto. De forma predeterminada, está en jni/Application.mk, en el directorio del proyecto de la aplicación.

Variables

APP_ABI

De forma predeterminada, el sistema de compilación del NDK genera código para todas las ABI que no están obsoletas. Puedes usar la configuración APP_ABI a fin de generar código para ABI específicas. En la tabla 1, se muestra la configuración de APP_ABI para diferentes conjuntos de instrucciones.

Tabla 1. Configuración de APP_ABI para diferentes conjuntos de instrucciones

Conjunto de instrucciones 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 las ABI admitidas (de forma predeterminada) APP_ABI := all

También puedes ubicar varios valores en la misma línea, delimitados por espacios, para especificarlos. Por ejemplo:

APP_ABI := armeabi-v7a arm64-v8a x86

Para ver una lista de todas las ABI compatibles y detalles sobre su uso y sus limitaciones, consulta ABI de Android.

APP_ASFLAGS

Estas marcas se transmitirán al ensamblador para cada archivo fuente de ensamblado (archivos .s y .S) del proyecto.

APP_ASMFLAGS

Estas marcas se pasarán a YASM para cada archivo fuente de YASM (solo archivos .asm, x86/x86_64).

APP_BUILD_SCRIPT

De forma predeterminada, ndk-build asume que el archivo Android.mk está ubicado en el jni/Android.mk correspondiente a la raíz del proyecto.

Para cargar un archivo Android.mk desde una ubicación diferente, configura APP_BUILD_SCRIPT en la ruta de acceso absoluta del archivo Android.mk.

APP_CFLAGS

Son las marcas que se transmitirán para todas las compilaciones de C/C++ en el proyecto.

Consulta también: APP_CONLYFLAGS, APP_CPPFLAGS.

APP_CLANG_TIDY

Se establece como verdadero a fin de habilitar clang-tidy en todos los módulos del proyecto. Está inhabilitado de forma predeterminada.

APP_CLANG_TIDY_FLAGS

Las marcas para transmitir todas las ejecuciones de clang-tidy en el proyecto.

APP_CONLYFLAGS

Las marcas que se pasarán para todas las compilaciones de C del proyecto. No se usarán para el código de C++.

Consulta también: APP_CFLAGS, APP_CPPFLAGS.

APP_CPPFLAGS

Estas marcas se pasarán para todas las compilaciones de C++ del proyecto. No se usarán para el código de C.

Consulta también: APP_CFLAGS, APP_CONLYFLAGS.

APP_CXXFLAGS

Es idéntico a APP_CPPFLAGS, pero aparecerá luego de APP_CPPFLAGS en el comando de compilación. Por ejemplo:

APP_CPPFLAGS := -DFOO
APP_CXXFLAGS := -DBAR

La configuración anterior generará un comando de compilación similar a clang++ -DFOO -DBAR en lugar de clang++ -DBAR -DFOO.

APP_DEBUG

Se establece en true para compilar una app que se pueda depurar.

APP_LDFLAGS

Son las marcas que se transmitirán cuando se vinculen bibliotecas compartidas y ejecutables.

APP_MANIFEST

Es una ruta de acceso absoluta a un archivo AndroidManifest.xml.

De forma predeterminada, se usará $(APP_PROJECT_PATH)/AndroidManifest.xml) si existe.

APP_MODULES

Es una lista explícita de los módulos para compilar. Los elementos de esta lista son los nombres de los módulos como aparecen en LOCAL_MODULE dentro del archivo Android.mk.

De forma predeterminada, ndk-build compilará todas las bibliotecas compartidas, los ejecutables y sus dependencias. Las bibliotecas estáticas se compilarán solo si el proyecto las usa, si el proyecto solo contiene bibliotecas estáticas o si se enumeran en APP_MODULES.

APP_OPTIM

Define esta variable opcional como release o debug. Los objetos binarios de actualización se compilan de forma predeterminada.

El modo de actualización habilita optimizaciones y puede crear objetos binarios que no se pueden usar con un depurador. El modo de depuración inhabilita la optimización de manera que se puedan usar los depuradores.

Ten en cuenta que puedes depurar objetos binarios de depuración o actualización. Sin embargo, los objetos binarios de actualización proporcionan menos información durante la depuración. Por ejemplo, las variables se pueden optimizar por fuera a fin de evitar la inspección. Asimismo, el reordenamiento de código puede dificultar aún más el recorrido del código; es posible que el seguimiento de pila no sea confiable.

Si declaras android:debuggable en la etiqueta <application> del manifiesto de tu aplicación, la variable predeterminada será debug en lugar de release. Puedes anular este valor predeterminado si configuras APP_OPTIM como release.

APP_PLATFORM

APP_PLATFORM declara el nivel de API de Android con el que se compiló esta aplicación y se corresponde con la minSdkVersion de la aplicación.

Si no se especifica, ndk-build se orientará al nivel mínimo de API admitido por el NDK. El nivel mínimo de API admitido por el NDK más reciente siempre será lo suficientemente bajo como para admitir casi todos los dispositivos activos.

Por ejemplo, un valor de android-16 especifica que tu biblioteca usa API que no están disponibles en versiones anteriores a Android 4.1 (nivel de API 16) y no se podrá usar en dispositivos que ejecuten una versión anterior de la plataforma. Para obtener una lista completa de los nombres de las plataformas y las imágenes del sistema de Android correspondientes, consulta API nativas del NDK de Android.

Cuando uses Gradle y externalNativeBuild, este parámetro no se debe establecer directamente. En su lugar, establece la propiedad minSdkVersion en los bloqueos defaultConfig o productFlavors del archivo build.gradle en el nivel del módulo. Así, te aseguras de que la biblioteca solo se use en las apps instaladas en los dispositivos que ejecutan una versión adecuada de Android.

Ten en cuenta que el NDK no contiene bibliotecas para cada nivel de API de Android. Las versiones que no incluyen las API nativas nuevas se omiten para ahorrar espacio en el NDK. A continuación, se muestran los usos del ndk-build en orden de preferencia descendente:

  1. La versión de la plataforma que coincida con APP_PLATFORM.
  2. El siguiente nivel de API disponible anterior a APP_PLATFORM. Por ejemplo, se usará android-19 cuando APP_PLATFORM sea android-20, dado que no hay API nativas nuevas en android-20.
  3. El nivel de API mínimo admitido por el NDK.

APP_PROJECT_PATH

La ruta de acceso absoluta del directorio raíz del proyecto.

APP_SHORT_COMMANDS

El equivalente de LOCAL_SHORT_COMMANDS en todo el proyecto. Para obtener más información, consulta la documentación de LOCAL_SHORT_COMMANDS en el archivo Android.mk.

APP_STL

Es la biblioteca estándar C++ para usar en esta app.

De forma predeterminada, se usa la STL de system. Otras opciones son c++_shared, c++_static y none. Consulta Funciones y tiempos de ejecución del NDK de C++.

APP_STRIP_MODE

Es el argumento que se transferirá a strip para los módulos de esta aplicación. La configuración predeterminada es --strip-unneeded. Para evitar la eliminación de todos los objetos binarios del módulo, configúralo como none. Para conocer otros modos de eliminación, consulta la documentación sobre eliminación.

APP_THIN_ARCHIVE

Se establece en verdadero a fin de usar archivos estrechos para todas las bibliotecas estáticas del proyecto. Para obtener más información, consulta la documentación sobre LOCAL_THIN_ARCHIVE en el archivo Android.mk.

APP_WRAP_SH

La ruta de acceso al archivo wrap.sh que se incluirá con esta app.

Existe una variante de esta variable para cada ABI, y también una variante genérica de ABI:

  • APP_WRAP_SH
  • APP_WRAP_SH_armeabi-v7a
  • APP_WRAP_SH_arm64-v8a
  • APP_WRAP_SH_x86
  • APP_WRAP_SH_x86_64