Android.mk

En esta página, se describe la sintaxis del archivo de compilación Android.mk que usa ndk-build.

Descripción general

El archivo Android.mk reside en un subdirectorio dentro del directorio jni/ de tu proyecto, y describe tus archivos de origen y bibliotecas compartidas al sistema de compilación. Se trata de un fragmento muy pequeño de un archivo GNU Make que el sistema de compilación analiza una o varias veces. El archivo Android.mk resulta útil para definir la configuración de todo el proyecto que Application.mk, el sistema de compilación y las variables de tu entorno dejan sin definir. También puede anular la configuración de todo el proyecto para módulos específicos.

La sintaxis de Android.mk te permite agrupar tus archivos de origen en módulos. Un módulo puede ser una biblioteca estática, una biblioteca compartida o un elemento ejecutable independiente. Puedes definir uno o varios módulos en cada archivo Android.mk y también puedes usar el mismo archivo de origen en múltiples módulos. El sistema de compilación solo coloca bibliotecas compartidas en el paquete de tu app. Asimismo, las bibliotecas estáticas pueden generar bibliotecas compartidas.

Además de empaquetar bibliotecas, el sistema de compilación se encarga de varios otros detalles por ti. Por ejemplo, no necesitas enumerar los archivos de encabezados o dependencias explícitas entre los archivos generados en tu archivo Android.mk. El sistema de compilación del NDK calcula estas relaciones de manera automática por ti. Como resultado, deberías poder beneficiarte de la nueva compatibilidad de la cadena de herramientas y de la plataforma en futuras versiones del NDK sin realizar ninguna acción en el archivo Android.mk.

La sintaxis de este archivo es muy similar a la que se usa en los archivos Android.mk, que se distribuyen con el Proyecto de código abierto de Android completo. Si bien la implementación del sistema de compilación que los usa es diferente, la similitud está en una decisión de diseño intencional que intenta hacer que los programadores de apps puedan reutilizar, de manera más sencilla, el código fuente para bibliotecas externas.

Conceptos básicos

Antes de explorar la sintaxis en detalle, resultará útil comenzar por comprender los conceptos básicos de lo que contiene un archivo Android.mk. En esta sección, se usa el archivo Android.mk de la muestra Hello-JNI para ese fin y se explica la función de cada línea en el archivo.

Un archivo Android.mk debe comenzar con la definición de la variable LOCAL_PATH:

LOCAL_PATH := $(call my-dir)
    

Esta variable indica la ubicación de los archivos de origen en el árbol de desarrollo. Aquí, la función macro my-dir, proporcionada por el sistema de compilación, devuelve la ruta de acceso al directorio actual (aquel que contiene el archivo Android.mk).

En la siguiente línea, se declara la variable CLEAR_VARS, un valor que proporciona la compilación del sistema.

include $(CLEAR_VARS)
    

La variable CLEAR_VARS apunta a un archivo Make de GNU que borra varias variables LOCAL_XXX por ti, como LOCAL_MODULE, LOCAL_SRC_FILES y LOCAL_STATIC_LIBRARIES. Ten en cuenta que no borra LOCAL_PATH. Esta variable debe mantener su valor porque el sistema analiza todos los archivos de control de la compilación en un solo contexto de ejecución Make de GNU en donde todas las variables son globales. Debes (volver a) declarar esta variable antes de describir cada módulo.

Luego, la variable LOCAL_MODULE almacena el nombre del módulo que quieres compilar. Usa esta variable una vez por módulo en tu aplicación.

LOCAL_MODULE := hello-jni
    

Los nombres de los módulos deben ser únicos y no contener espacios. El sistema de compilación, cuando genera el archivo final de biblioteca compartida, agrega automáticamente el prefijo y el sufijo adecuados al nombre que le asignaste a LOCAL_MODULE. Por ejemplo, en el ejemplo anterior, se genera una biblioteca llamada libhello-jni.so.

En la próxima línea, se enumeran los archivos de origen, con espacios para delimitar varios archivos:

LOCAL_SRC_FILES := hello-jni.c
    

La variable LOCAL_SRC_FILES debe contener una lista de archivos de origen C y C++ para compilar en un módulo.

La última línea ayuda al sistema a unificar todo:

include $(BUILD_SHARED_LIBRARY)
    

La variable BUILD_SHARED_LIBRARY apunta a una secuencia de comandos de un archivo Make de GNU que recopila toda la información que definiste en las variables LOCAL_XXX desde el include más reciente. Esta secuencia de comandos determina lo que se compilará y la manera de hacerlo.

Hay ejemplos más complejos en los directorios de muestra, con archivos Android.mk que incluyen comentarios que puedes consultar. Además, en la sección Muestra: native-activity, se brinda una explicación detallada del archivo Android.mk de esa muestra. Por último, en la sección Variables y macros, se proporciona información adicional sobre las variables de esta sección.

Variables y macros

El sistema de compilación proporciona muchas variables posibles para usar en el archivo Android.mk. Una gran cantidad de esas variables poseen valores previamente asignados. En el caso de las demás, debes encargarte de asignarlos.

Además de esas variables, también puedes definir tus propias variables arbitrarias. Si lo haces, ten en cuenta que el sistema de compilación del NDK reserva los siguientes nombres de variables:

  • Nombres que comienzan con LOCAL_, como LOCAL_MODULE.
  • Nombres que comienzan con PRIVATE_, NDK_ o APP. El sistema de compilación los usa internamente.
  • Nombres en minúscula, como my-dir. El sistema de compilación también usa estos nombres internamente.

Si necesitas definir tus propias variables de conveniencia en un archivo Android.mk, te recomendamos que anexes MY_ a sus nombres.

Variables de inclusión definidas por NDK

En esta sección, se abordan las variables de GNU Make que el sistema de compilación define antes de analizar tu archivo Android.mk. En determinadas circunstancias, es posible que el NDK analice tu archivo Android.mk varias veces, con una definición diferente para algunas de estas variables en cada vez.

CLEAR_VARS

Esta variable apunta a una secuencia de comandos que anula la definición de casi todas las variables LOCAL_XXX que se enumeran en la sección "Variables definidas por el desarrollador" que se muestra debajo. Usa esta variable para incluir esta secuencia de comandos antes de describir un nuevo módulo. La sintaxis para usarla es la siguiente:

include $(CLEAR_VARS)
    

BUILD_EXECUTABLE

Esta variable apunta a una secuencia de comandos que recopila toda la información sobre el módulo que proporcionaste en tus variables LOCAL_XXX y determina cómo compilar un destino ejecutable a partir de los archivos de origen que enumeraste. Ten en cuenta que el uso de esta secuencia de comandos requiere que ya tengas valores asignados a LOCAL_MODULE y LOCAL_SRC_FILES, como mínimo (para obtener más información sobre estas variables, consulta Variables de descripción de módulos).

La sintaxis para usar esta variable es la siguiente:

include $(BUILD_EXECUTABLE)
    

BUILD_SHARED_LIBRARY

Esta variable apunta a una secuencia de comandos que recopila toda la información sobre el módulo que proporcionaste en tus variables LOCAL_XXX y determina cómo compilar una biblioteca compartida de destino a partir de los archivos de origen que enumeraste. Ten en cuenta que el uso de esta secuencia de comandos requiere que ya tengas valores asignados a LOCAL_MODULE y LOCAL_SRC_FILES, como mínimo (para obtener más información sobre estas variables, consulta Variables de descripción de módulos).

La sintaxis para usar esta variable es la siguiente:

include $(BUILD_SHARED_LIBRARY)
    

Una variable de biblioteca compartida hace que el sistema de compilación genere un archivo de biblioteca con la extensión .so.

BUILD_STATIC_LIBRARY

Una variante de BUILD_SHARED_LIBRARY que se usa para compilar una biblioteca estática. El sistema de compilación no copia bibliotecas estáticas en tu proyecto ni tus paquetes, pero puede usarlas para compilar bibliotecas compartidas (consulta LOCAL_STATIC_LIBRARIES y LOCAL_WHOLE_STATIC_LIBRARIES debajo). La sintaxis para usar esta variable es la siguiente:

include $(BUILD_STATIC_LIBRARY)
    

Una variable de biblioteca estática hace que el sistema de compilación genere una biblioteca con una extensión .a.

PREBUILT_SHARED_LIBRARY

Apunta a una secuencia de comandos de compilación empleada para especificar la biblioteca compartida compilada previamente. A diferencia de BUILD_SHARED_LIBRARY y BUILD_STATIC_LIBRARY, aquí, el valor de LOCAL_SRC_FILES no puede ser un archivo de origen. En su lugar, debe ser una sola ruta de acceso a una biblioteca compartida compilada previamente, como foo/libfoo.so. La sintaxis para usar esta variable es la siguiente:

include $(PREBUILT_SHARED_LIBRARY)
    

También puedes hacer referencia a una biblioteca compilada previamente en otro módulo si usas la variable LOCAL_PREBUILTS. Para obtener más información sobre cómo usar compilaciones previas, consulta Cómo usar bibliotecas compiladas previamente.

PREBUILT_STATIC_LIBRARY

La misma que PREBUILT_SHARED_LIBRARY, pero para una biblioteca estática compilada previamente. Para obtener más información sobre cómo usar compilaciones previas, consulta Cómo usar bibliotecas compiladas previamente.

Variables de información de destino

El sistema de compilación analiza Android.mk una vez por cada ABI especificada por la variable APP_ABI que por lo general se define en tu archivo Application.mk. Si APP_ABI es all, entonces el sistema de compilación analiza Android.mk una vez por cada ABI compatible con el NDK. En esta sección, se describen las variables que define el sistema de compilación cada vez que analiza Android.mk.

TARGET_ARCH

La familia de CPU a la que se orienta el sistema de compilación cuando analiza este archivo Android.mk. Esta variable será una de las siguientes: arm, arm64, x86 o x86_64.

TARGET_PLATFORM

El número de nivel de API de Android al que se orienta el sistema de compilación cuando analiza el archivo Android.mk. Por ejemplo, las imágenes del sistema Android 5.1 corresponden al nivel de API 22 de Android: android-22. 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. En el siguiente ejemplo, se muestra la sintaxis para usar esta variable:

ifeq ($(TARGET_PLATFORM),android-22)
        # ... do something ...
    endif
    

TARGET_ARCH_ABI

La ABI a la que se orienta el sistema de compilación cuando analiza este archivo Android.mk. En la tabla 1, se muestra la configuración de la ABI que se usa para cada CPU y arquitectura admitidos.

Tabla 1. Configuración de ABI para diferentes CPU y arquitecturas.

CPU y arquitectura Configuración
ARMv7 armeabi-v7a
ARMv8 AArch64 arm64-v8a
i686 x86
x86-64 x86_64

En el siguiente ejemplo, se muestra cómo comprobar ARMv8 AArch64 como la combinación de CPU y ABI de destino:

ifeq ($(TARGET_ARCH_ABI),arm64-v8a)
      # ... do something ...
    endif
    

Para obtener más información sobre la arquitectura de las ABI y los problemas de compatibilidad relacionados, consulta Administración de ABI.

En el futuro, las nuevas ABI de destino tendrán valores diferentes.

TARGET_ABI

Una concatenación de ABI y nivel de API de Android de destino. Resulta particularmente útil cuando quieres realizar pruebas en una imagen específica del sistema de destino para un dispositivo real. Por ejemplo, para comprobar un dispositivo ARM de 64 bits con nivel 22 de Android API:

ifeq ($(TARGET_ABI),android-22-arm64-v8a)
      # ... do something ...
    endif
    

Variables de descripción de módulo

Las variables en esta sección describen tu módulo al sistema de compilación. La descripción de cada módulo debe seguir el siguiente flujo básico:

  1. Inicializa o anula la definición de las variables asociadas con el módulo, por medio de la variable CLEAR_VARS.
  2. Asigna valores a las variables empleadas para describir el módulo.
  3. Establece el sistema de compilación del NDK para que use la secuencia de comandos de compilación apropiada para el módulo, por medio de la variable BUILD_XXX.

LOCAL_PATH

Esta variable se usa para proporcionar la ruta de acceso del archivo actual. Debes definirla al comienzo de tu archivo Android.mk. En el siguiente ejemplo, se muestra cómo hacerlo:

LOCAL_PATH := $(call my-dir)
    

La secuencia de comandos a la que se apunta CLEAR_VARS no borra esta variable. Por lo tanto, solo necesitas definirla una sola vez, incluso si tu archivo Android.mk describe varios módulos.

LOCAL_MODULE

Esta variable almacena el nombre de tu módulo. Debe ser única entre todos los nombres de módulos, y no debe contener espacios. Debes definirla antes de incluir secuencias de comandos (que no sean la que definiste para CLEAR_VARS). No es necesario que agregues el prefijo lib ni las extensiones de archivo .so o .a, ya que el sistema de compilación realiza estas modificaciones automáticamente. En tus archivos Android.mk y Application.mk, haz referencia a tu módulo por su nombre sin modificar. Por ejemplo, la siguiente línea genera un módulo de biblioteca compartida llamado libfoo.so:

LOCAL_MODULE := "foo"
    

Si quieres que el módulo generado tenga un nombre diferente a lib + el valor de LOCAL_MODULE, puedes usar la variable LOCAL_MODULE_FILENAME para asignar el nombre que quieras al módulo generado.

LOCAL_MODULE_FILENAME

Esta variable opcional te permite anular los nombres que el sistema de compilación usa de forma predeterminada para los archivos que genera. Por ejemplo, si el nombre de tu LOCAL_MODULE es foo, puedes forzar al sistema para que asigne el nombre libnewfoo al archivo que genera. En el siguiente ejemplo, se muestra la manera de lograrlo:

LOCAL_MODULE := foo
    LOCAL_MODULE_FILENAME := libnewfoo
    

Para un módulo de biblioteca compartida, este ejemplo generaría un archivo llamado libnewfoo.so.

LOCAL_SRC_FILES

Esta variable contiene la lista de archivos de origen que usa el sistema de compilación para generar el módulo. Solo se deben enumerar los archivos que el sistema de compilación le transmite al compilador, ya que el sistema de compilación computa automáticamente todas las dependencias asociadas. Ten en cuenta que puedes usar tanto la ruta de acceso al archivo relativa (a LOCAL_PATH) como la absoluta.

Te recomendamos evitar las rutas de acceso a archivos absolutas, ya que las relativas hacen que tu archivo Android.mk sea más portátil.

LOCAL_CPP_EXTENSION

Puedes usar esta variable opcional para indicar una extensión de archivo diferente a .cpp para tus archivos de origen C++. Por ejemplo, la siguiente línea cambia la extensión a .cxx. (Esta configuración debe incluir el punto).

LOCAL_CPP_EXTENSION := .cxx
    

Puedes usar esta variable para especificar varias extensiones. Por ejemplo:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc
    

LOCAL_CPP_FEATURES

Puedes usar esta variable opcional para indicar que tu código se basa en funciones específicas de C++. Habilita el compilador y los indicadores del vinculador correctos durante el proceso de compilación. En el caso de los objetos binarios compilados previamente, esta variable también declara las funciones en las que se basa el objeto binario. De esta manera, se garantiza que la vinculación final funcione correctamente. Te recomendamos usar esta variable en lugar de habilitar -frtti y -fexceptions directamente en la definición de LOCAL_CPPFLAGS.

El uso de esta variable permite que el sistema de compilación use los indicadores correctos para cada módulo. El uso de LOCAL_CPPFLAGS hace que el compilador use todos los indicadores especificados para todos los módulos, independientemente de la necesidad real.

Por ejemplo, para indicar que tu código usa RTTI (Información de tipo RunTime), escribe lo siguiente:

LOCAL_CPP_FEATURES := rtti
    

Para indicar que tu código usa excepciones C++, escribe lo siguiente:

LOCAL_CPP_FEATURES := exceptions
    

También puedes especificar diferentes valores para esta variable. por ejemplo:

LOCAL_CPP_FEATURES := rtti features
    

No importa el orden en el que describas los valores.

LOCAL_C_INCLUDES

Puedes usar esta variable opcional para especificar una lista de rutas de acceso, relacionadas con el directorio root del NDK, que agregarás a la ruta de acceso de inclusión de búsqueda al compilar todos los orígenes (C, C++ y Assembly). por ejemplo:

LOCAL_C_INCLUDES := sources/foo
    

O incluso:

LOCAL_C_INCLUDES := $(LOCAL_PATH)/<subdirectory>/foo
    

Puedes definir esta variable antes de configurar los indicadores de inclusión correspondientes por medio de LOCAL_CFLAGS o LOCAL_CPPFLAGS.

El sistema de compilación también usa rutas de acceso LOCAL_C_INCLUDES automáticamente al iniciar depuraciones nativas con ndk-gdb.

LOCAL_CFLAGS

Esta variable opcional establece indicadores del compilador para que el sistema de compilación los transmita al compilar archivos de origen C y C++, lo que resulta útil para especificar definiciones de macro adicionales, o bien, opciones de compilación. Usa LOCAL_CPPFLAGS a fin de especificar indicadores solo para C++.

Intenta no cambiar el nivel de optimización ni de depuración del archivo Android.mk. El sistema de compilación puede controlar esta configuración automáticamente por ti, mediante la información relevante en el archivo Application.mk. Al hacerlo de esta manera, el sistema de compilación puede generar archivos de datos útiles que se usan durante la depuración.

Se pueden especificar rutas de acceso de inclusión adicionales escribiendo lo siguiente:

LOCAL_CFLAGS += -I<path>,
    

Sin embargo, es mejor usar LOCAL_C_INCLUDES para este fin, ya que al hacerlo, también podrás usar las rutas disponibles para depuraciones nativas con ndk-gdb.

LOCAL_CPPFLAGS

Un conjunto opcional de indicadores de compilador que se transmitirán al compilar archivos de origen C++ únicamente. Aparecerán después de LOCAL_CFLAGS en la línea de comandos del compilador. Usa LOCAL_CFLAGS a fin de especificar indicadores para C y C++.

LOCAL_STATIC_LIBRARIES

Esta variable almacena la lista de módulos de bibliotecas estáticas de los cuales depende el módulo actual.

Si el módulo actual es una biblioteca compartida o un ejecutable, esta variable forzará la vinculación de esas bibliotecas en el objeto binario resultante.

Si el módulo actual es una biblioteca estática, esta variable simplemente indica que otros módulos basados en el actual también se basarán en las bibliotecas indicadas.

LOCAL_SHARED_LIBRARIES

Esta variable es la lista de módulo de bibliotecas compartidas en las cuales se basa este módulo durante el tiempo de ejecución. Esta información es necesaria en el momento de la vinculación y para incorporar la información correspondiente al archivo generado.

LOCAL_WHOLE_STATIC_LIBRARIES

Esta variable es una variante de LOCAL_STATIC_LIBRARIES y expresa que el vinculador debe tratar los módulos de bibliotecas asociados como archivos enteros. Para obtener más información sobre archivos enteros, consulta la documentación del ID de GNU para la marca --whole-archive.

Esta variable es útil cuando hay dependencias circulares entre varias bibliotecas estáticas. Cuando uses esta variable para compilar una biblioteca compartida, forzarás al sistema de compilación a agregar todos los archivos de objetos de tus bibliotecas estáticas al objeto binario final. No obstante, no ocurre lo mismo al generar ejecutables.

LOCAL_LDLIBS

Esta variable contiene la lista de indicadores adicionales del vinculador para usar en la compilación de tu biblioteca compartida o ejecutable. Te permite usar el prefijo -l para transmitir el nombre de bibliotecas específicas del sistema. Por ejemplo, en el siguiente ejemplo se indica al vinculador que genere un módulo que se vincule con /system/lib/libz.so al momento de carga:

LOCAL_LDLIBS := -lz
    

Para obtener la lista de las bibliotecas del sistema a las que te puedes vincular en esta versión del NDK, consulta API nativa del NDK de Android.

LOCAL_LDFLAGS

La lista de otros indicadores del vinculador para el sistema de compilación que deben usarse al compilar tu biblioteca compartida o ejecutable. Por ejemplo, para usar el vinculador ld.bfd en ARM/X86:

LOCAL_LDFLAGS += -fuse-ld=bfd
    

LOCAL_ALLOW_UNDEFINED_SYMBOLS

De forma predeterminada, cuando el sistema de compilación encuentra una referencia indefinida mientras intenta compilar una biblioteca compartida, generará un error de símbolo sin definir. Este error puede ayudarte a detectar otros errores en tu código fuente.

Para inhabilitar esta comprobación, establece esta variable en true. Ten en cuenta que esta configuración puede hacer que la biblioteca compartida se cargue en el tiempo de ejecución.

LOCAL_ARM_MODE

De forma predeterminada, el sistema de compilación genera objetos binarios de destino ARM en el modo thumb, donde cada instrucción tiene 16 bits de ancho y está vinculada a bibliotecas STL en el directorio thumb/. Definir esta variable como arm fuerza al sistema de compilación a generar los archivos de objeto del módulo en el modo arm de 32 bits. En el siguiente ejemplo, se muestra cómo hacerlo:

LOCAL_ARM_MODE := arm
    

También puedes indicar al sistema de compilación que solo compile archivos de origen específicos en el modo arm al anexar el sufijo .arm a los nombres de los archivos de origen. Por ejemplo, en el siguiente ejemplo se indica al sistema de compilación que siempre compile bar.c en el modo ARM, pero que compile foo.c en función al valor de LOCAL_ARM_MODE.

LOCAL_SRC_FILES := foo.c bar.c.arm
    

LOCAL_ARM_NEON

Esta variable solo es importante cuando se orienta a la ABI armeabi-v7a. Permite el uso de elementos intrínsecos del compilador de SIMD avanzado de ARM (NEON) en tus archivos de origen C y C++, así como también instrucciones NEON en archivos Assembly.

Ten en cuenta que no todas las CPU basadas en ARMv7 admiten extensiones para el conjunto de instrucciones NEON. Por este motivo, debes realizar una detección del tiempo de ejecución para poder usar este código de forma segura durante el tiempo de ejecución. Para obtener más información, consulta Compatibilidad con NEON y la biblioteca cpufeatures.

De manera alternativa, puedes usar el sufijo .neon para especificar que el sistema de compilación solo compile archivos de origen específicos compatibles con NEON. En el siguiente ejemplo, el sistema de compilación compila foo.c con compatibilidad para Thumb y NEON, bar.c con compatibilidad para Thumb y zoo.c con compatibilidad para ARM y NEON:

LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon
    

Si usas ambos sufijos, .arm debe ir antes que .neon.

LOCAL_DISABLE_FORMAT_STRING_CHECKS

De forma predeterminada, el sistema de compilación compila código con protección de strings de formato. En consecuencia, se genera un error de compilador si se usa una string de formato que no es constante en una función de estilo printf. Esta protección está activada de forma predeterminada, pero puedes inhabilitarla si estableces el valor de esta variable en true. No recomendamos hacer esto sin un motivo específico.

LOCAL_EXPORT_CFLAGS

Esta variable registra un conjunto de indicadores C/C++ del compilador para agregar a la definición LOCAL_CFLAGS de cualquier otro módulo que la use a través de las variables LOCAL_STATIC_LIBRARIES o LOCAL_SHARED_LIBRARIES.

Por ejemplo, considera el siguiente par de módulos: foo y bar, que se basan en foo:

include $(CLEAR_VARS)
    LOCAL_MODULE := foo
    LOCAL_SRC_FILES := foo/foo.c
    LOCAL_EXPORT_CFLAGS := -DFOO=1
    include $(BUILD_STATIC_LIBRARY)

    include $(CLEAR_VARS)
    LOCAL_MODULE := bar
    LOCAL_SRC_FILES := bar.c
    LOCAL_CFLAGS := -DBAR=2
    LOCAL_STATIC_LIBRARIES := foo
    include $(BUILD_SHARED_LIBRARY)
    

Aquí, el sistema de compilación transmite los indicadores -DFOO=1 y -DBAR=2 al compilador durante la compilación de bar.c. También anexa prefijos a los indicadores exportados al LOCAL_CFLAGS de tu módulo para que puedas anularlos fácilmente.

Asimismo la relación entre los módulos es transitiva: Si zoo se basa en bar, que, a su vez, se basa en foo, entonces zoo también hereda todos los indicadores exportados de foo.

Por último, el sistema de compilación no usa indicadores exportados cuando realiza compilaciones a nivel local (es decir, cuando compila el módulo cuyos indicadores exporta). Por lo tanto, en el ejemplo anterior, no transmite -DFOO=1 al compilador mientras compila foo/foo.c. Para realizar compilaciones localmente, usa LOCAL_CFLAGS.

LOCAL_EXPORT_CPPFLAGS

Esta variable es la misma que LOCAL_EXPORT_CFLAGS, pero para indicadores C++ únicamente.

LOCAL_EXPORT_C_INCLUDES

Esta variable es la misma que LOCAL_EXPORT_CFLAGS, pero para rutas de acceso de inclusión de C. Resulta útil en casos en los cuales, por ejemplo, bar.c debe incluir encabezados del módulo foo.

LOCAL_EXPORT_LDFLAGS

Esta variable es la misma que LOCAL_EXPORT_CFLAGS, pero para indicadores del vinculador.

LOCAL_EXPORT_LDLIBS

Esta variable es la misma que LOCAL_EXPORT_CFLAGS y, además, indica al sistema de compilación que transmita al compilador nombres de bibliotecas específicas del sistema. Anexa -l al nombre de cada biblioteca que especifiques.

Ten en cuenta que el sistema de compilación anexa indicadores de vinculador importados al valor de la variable LOCAL_LDLIBS de tu módulo. Lo hace como consecuencia del funcionamiento de los vinculadores de Unix.

Esta variable suele ser útil cuando el módulo foo es una biblioteca estática y tiene código que se basa en una biblioteca del sistema. Entonces puedes usar LOCAL_EXPORT_LDLIBS para exportar la dependencia. por ejemplo:

include $(CLEAR_VARS)
    LOCAL_MODULE := foo
    LOCAL_SRC_FILES := foo/foo.c
    LOCAL_EXPORT_LDLIBS := -llog
    include $(BUILD_STATIC_LIBRARY)

    include $(CLEAR_VARS)
    LOCAL_MODULE := bar
    LOCAL_SRC_FILES := bar.c
    LOCAL_STATIC_LIBRARIES := foo
    include $(BUILD_SHARED_LIBRARY)
    

En este ejemplo, el sistema de compilación agrega -llog al final del comando del vinculador cuando compila libbar.so. Al hacerlo, se indica al vinculador que, como libbar.so se basa en foo, también se basa en la biblioteca de registro del sistema.

LOCAL_SHORT_COMMANDS

Establece esta variable a true cuando tu módulo tenga una gran cantidad de archivos de origen y bibliotecas compartidas o estáticas dependientes. De esta manera, se fuerza al sistema de compilación a usar la sintaxis @ para los archivos que contengan bibliotecas vinculantes o archivos de objeto intermedios.

Esta función puede ser útil en Windows, donde la línea de comandos acepta una cantidad máxima de 8,191 caracteres, que pueden ser muy pocos para proyectos complejos. También afecta la compilación de archivos de origen individuales y coloca prácticamente todos los indicadores del compilador en archivos de lista.

Ten en cuenta que cualquier valor diferente de true restablecerá el comportamiento predeterminado. También puedes definir APP_SHORT_COMMANDS en tu archivo Application.mk para forzar este comportamiento en todos los módulos de tu proyecto.

No recomendamos habilitar esta función de forma predeterminada porque hace que la compilación sea más lenta.

LOCAL_THIN_ARCHIVE

Establece esta variable a true cuando compiles bibliotecas estáticas. Al hacerlo, se generará un archivo fino, un archivo de biblioteca que no contiene archivos de objeto, sino solo las rutas de acceso a archivos para los objetos reales que normalmente contendría.

Esto es útil para reducir el tamaño de la compilación final. La desventaja es que estas bibliotecas no se pueden mover a una ubicación diferente (todas las rutas de acceso dentro de ellas son relativas).

Los valores válidos son true, false o vacío. Puedes establecer un valor predeterminado en tu archivo Application.mk por medio de la variable APP_THIN_ARCHIVE.

LOCAL_FILTER_ASM

Define esta variable como un comando shell que el sistema de compilación usará para filtrar los archivos de ensamblado extraídos o generados a partir de los archivos que especificaste para LOCAL_SRC_FILES. Si la defines, ocurrirá lo siguiente:

  1. El sistema de compilación genera un archivo de ensamblado temporal a partir de cualquier archivo de origen C o C++, en lugar de compilarlos en un archivo de objeto.
  2. El sistema de compilación ejecuta el comando shell en LOCAL_FILTER_ASM en cualquier archivo de ensamblado temporal y cualquier archivo de ensamblado enumerado en LOCAL_SRC_FILES, con lo cual se genera otro archivo de ensamblado temporal.
  3. El sistema de compilación compila estos archivos de ensamblado filtrados en un archivo de objeto.

por ejemplo:

LOCAL_SRC_FILES  := foo.c bar.S
    LOCAL_FILTER_ASM :=

    foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.o
    bar.S                                 --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o
    

En este caso, "1" corresponde al compilador, "2" al filtro y "3" al ensamblador. El filtro debe ser un comando shell independiente que tome el nombre del archivo de entrada como su primer argumento, y el nombre del archivo de salida como el segundo. por ejemplo:

myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
    myasmfilter bar.S $OBJS_DIR/bar.S
    

Macros de función proporcionados por el NDK

En esta sección, se explican las macros de la función GNU Make que el NDK proporciona. Usa $(call <function>) para evaluarlas. Estas macros devuelven información textual.

my-dir

Esta macro devuelve la ruta del último archivo Make que se incluyó, que suele ser el directorio de Android.mk actual. my-dir resulta útil para definir LOCAL_PATH al comienzo del archivo Android.mk. por ejemplo:

LOCAL_PATH := $(call my-dir)
    

Debido a la manera en que funciona GNU Make, lo que esta macro realmente devuelve es la ruta de acceso del último archivo Make que el sistema de compilación incluyó al analizar las secuencias de comando de compilación. Por este motivo, no debes llamar a my-dir después de incluir otro archivo.

Por ejemplo, considera el siguiente ejemplo:

LOCAL_PATH := $(call my-dir)

    # ... declare one module

    include $(LOCAL_PATH)/foo/`Android.mk`

    LOCAL_PATH := $(call my-dir)

    # ... declare another module
    

El problema aquí es que la segunda llamada a my-dir define LOCAL_PATH como $PATH/foo en lugar de $PATH, ya que allí es a donde apuntaba su inclusión más reciente.

Puedes evitar este problema si colocas inclusiones adicionales después de todo lo demás en el archivo Android.mk. por ejemplo:

LOCAL_PATH := $(call my-dir)

    # ... declare one module

    LOCAL_PATH := $(call my-dir)

    # ... declare another module

    # extra includes at the end of the Android.mk file
    include $(LOCAL_PATH)/foo/Android.mk
    

Si no es posible estructurar el archivo de esta manera, guarda el valor de la primera llamada a my-dir en otra variable. por ejemplo:

MY_LOCAL_PATH := $(call my-dir)

    LOCAL_PATH := $(MY_LOCAL_PATH)

    # ... declare one module

    include $(LOCAL_PATH)/foo/`Android.mk`

    LOCAL_PATH := $(MY_LOCAL_PATH)

    # ... declare another module
    

all-subdir-makefiles

Devuelve la lista de archivos Android.mk ubicados en todos los subdirectorios de la ruta de acceso my-dir actual.

Puedes usar esta función para proporcionar jerarquías de directorios de origen profundamente anidados al sistema de compilación. De manera predeterminada, el NDK solo busca archivos en el directorio que contiene el archivo Android.mk.

this-makefile

Devuelve la ruta de acceso del archivo Make actual (desde el cual el sistema de compilación llamó a la función).

parent-makefile

Devuelve la ruta de acceso del archivo Make superior en el árbol de inclusión (la ruta de acceso del archivo Make que incluyó al actual).

grand-parent-makefile

Devuelve la ruta de acceso del archivo Make primario en el árbol de inclusión (la ruta de acceso del archivo Make que incluyó el actual).

import-module

Una función que te permite buscar y también incluir el archivo Android.mk de un módulo por el nombre del módulo. Un ejemplo típico es el siguiente:

$(call import-module,<name>)
    

En este ejemplo, el sistema de compilación busca el módulo con la etiqueta <name> en la lista de directorios a los cuales la variable NDK_MODULE_PATH de tu entorno hace referencia, y también incluye su archivo Android.mk de manera automática por ti.