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.

Nota: Muchos de estos parámetros también tienen un equivalente por módulo. Por ejemplo, APP_CFLAGS se corresponde con LOCAL_CFLAGS. En cada caso, la opción específica del módulo prevalecerá sobre las opciones de la aplicación. En el caso de las marcas, se usan ambas, pero las que son específicas del módulo aparecerán más adelante en la línea de comandos, por lo que pueden anular las configuraciones que se aplican a todo el proyecto.

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

Nota: externalNativeBuild de Gradle ignora a APP_ABI. En su lugar, usa un Bloquea abiFilters o (si utilizas "Varios APK") un bloqueo de abi dentro de un Bloque splits.

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.

Nota: Las ASFLAGS son distintas a ASMFLAGS. Las últimas se aplican específicamente a los archivos de origen de YASM (consulta la sección sobre APP_ASMFLAGS).

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.

Nota: externalNativeBuild de Gradle lo configurará automáticamente en función de la variable externalNativeBuild.ndkBuild.path.

APP_CFLAGS

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

Nota: Las rutas de inclusión deben usar LOCAL_C_INCLUDES en lugar de marcas -I explícitas.

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

Nota: Se debería preferir APP_CPPFLAGS antes que 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.

Nota: Estas marcas no afectan a las bibliotecas estáticas, ya que ellas no están vinculadas.

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.

Nota: Cuando se use externalNativeBuild, Gradle no establecerá el valor.

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.

Nota: Los módulos importados (aquellos definidos en las secuencias de comandos de compilación con $(call import-module)) no se compilarán, a menos que un módulo que deba compilarse dependa de ellos o se enumeren 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.

Nota: Cuando compiles con externalNativeBuild, Android Studio establecerá la marca de manera adecuada en función de tu variante de compilación.

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 apuntará 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.

Advertencia: Si APP_PLATFORM se configura con un valor mayor que la minSdkVersion de la aplicación, es probable que la aplicación no funcione en dispositivos más antiguos. En la mayoría de los casos, no se cargarán las bibliotecas porque hacen referencia a símbolos que no están disponibles en dispositivos más antiguos.

Por ejemplo, un valor de android-16 especifica que tu biblioteca usa APIs 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

Es 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 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 para 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

Nota: No se puede combinar APP_WRAP_SH_<abi> con APP_WRAP_SH. Si alguna ABI usa un wrap.sh específico de la ABI, todas las ABI deben usarlo.