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 de Conceptos.

Resumen

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

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 para 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 especificar varios valores al ubicarlos en la misma línea, delimitados por espacios. por ejemplo:

APP_ABI := armeabi-v7a arm64-v8a x86
    

Para ver una lista de todas las ABI admitidas y detalles sobre su uso y sus limitaciones, consulta Administración de ABI.

APP_ASFLAGS

Los indicadores que se transmiten al ensamblador para cada archivo de origen de ensamblaje (archivos .s y .S) en el proyecto.

APP_ASMFLAGS

Los indicadores que se transmiten a YASM para cada archivo de origen 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 archivo jni/Android.mk correspondiente a la raíz del proyecto.

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

APP_CFLAGS

Los indicadores 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 en true para habilitar clang-tidy para todos los módulos del proyecto. Está inhabilitado de forma predeterminada.

APP_CLANG_TIDY_FLAGS

Los indicadores para transmitir todas las ejecuciones de clang-tidy en el proyecto.

APP_CONLYFLAGS

Los indicadores que se transmitirán para todas las compilaciones de C del proyecto. Estos no se usarán para el código de C++.

Consulta también: APP_CFLAGS, APP_CPPFLAGS.

APP_CPPFLAGS

Los indicadores que se transmitirán para todas las compilaciones de C++ del proyecto. Estos no se usarán para el código 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 que se muestra más arriba tendrá como resultado 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

Los indicadores que se transmitirán cuando se vinculen bibliotecas compartidas y ejecutables.

APP_MANIFEST

Ruta de acceso absoluta a un archivo AndroidManifest.xml.

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

APP_MODULES

Una lista explícita de los módulos para compilar. Los elementos de esta lista son los nombres de los módulos a medida que 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 lanzamiento se compilan de forma predeterminada.

El modo de lanzamiento 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 ejecutables de depuración o lanzamiento. Sin embargo, los objetos binarios de lanzamiento 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 app provocarás que la variable predeterminada sea debug en lugar de release. Puedes anular este valor por defecto si estableces APP_OPTIM a release.

APP_PLATFORM

APP_PLATFORM declara el nivel de la API de Android en el que se creó esta compilación y se corresponde con la minSdkVersion de la app.

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

Por ejemplo, un valor de android-16 especifica que tu biblioteca usa las 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 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. De este modo, 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 nuevas API nativas 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, android-19 se usará cuando la APP_PLATFORM sea android-20, dado que no hay API nativas nuevas en android-20.
  3. El nivel mínimo de API 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 para LOCAL_SHORT_COMMANDS en Android.mk.

APP_STL

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

La STL de system se usa de forma predeterminada. Otras opciones son c++_shared, c++_static y none. Consulta Tiempos de ejecución y funciones del NDK.

APP_STRIP_MODE

El argumento que se transmitirá a strip para módulos en esta app. Su valor predeterminado es --strip-unneeded. Para evitar la eliminación de todos los objetos binarios en el módulo, establécelo en none. Para conocer otros modos de eliminación, consulta la documentación sobre eliminación.

APP_THIN_ARCHIVE

Se establece en true para usar archivos estrechos para todas las bibliotecas estáticas del proyecto. Para obtener más información, consulta la documentación de 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