Android.mk

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

Descripción general

El archivo Android.mk reside en un subdirectorio del directorio jni/ de tu proyecto, y describe tus fuentes 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 vez o más. El archivo Android.mk es útil para definir configuraciones en 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 del proyecto para módulos específicos.

La sintaxis Android.mk te permite agrupar tus fuentes en módulos. Un módulo es una biblioteca estática, una biblioteca compartida o un ejecutable independiente. Puedes definir uno o más módulos en cada archivo Android.mk y usar el mismo archivo de origen en varios módulos. El sistema de compilación solo dispone bibliotecas compartidas en el paquete de tu aplicación. Asimismo, las bibliotecas estáticas pueden generar bibliotecas compartidas.

Además de empaquetar bibliotecas, el sistema de compilación se encarga de otros detalles varios por ti. Por ejemplo, no necesitas indicar archivos de encabezados o dependencias específicas entre los archivos generados en tu archivo Android.mk. El sistema de compilación del NDK computa estas relaciones automáticamente por ti. En consecuencia, podrás beneficiarte con la nueva compatibilidad del conjunto de herramientas y de la plataforma en futuras versiones del NDK sin tener que tocar tu archivo Android.mk.

La sintaxis de este archivo es muy parecida a la que se usa en los archivos Android.mk distribuidos 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 se encuentra en una decisión de diseño intencional orientada a hacer que los programadores de aplicaciones 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 aspectos básicos de lo que contiene un archivo Android.mk. En esta sección, se usa el archivo Android.mk del ejemplo Hello-JNI para ese fin y se explica la función de cada línea en el archivo.

El punto de partida para un archivo Android.mk debe ser definir 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, muestra la ruta de acceso del directorio actual (el directorio que contiene el archivo Android.mk ).

En la siguiente línea, se declara la variable CLEAR_VARS, cuyo valor es proporcionado por el sistema de compilación.

include $(CLEAR_VARS)

La variable CLEAR_VARS está orientada a un archivo GNU Make especial que borra muchas variables LOCAL_XXX, como LOCAL_MODULE, LOCAL_SRC_FILES y LOCAL_STATIC_LIBRARIES. Ten en cuenta que no borra LOCAL_PATH. Esta variable debe retener su valor porque el sistema analiza todos los archivos de control de la compilación en un solo contexto de ejecución GNU Make en el cual 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 deseas 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, con 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 que delimitan varios archivos:

LOCAL_SRC_FILES := hello-jni.c

La variable LOCAL_SRC_FILES debe contener una lista de archivos de origen C o 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 GNU Make 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 ejemplos, con archivos Android.mk comentados que puedes consultar. Además, en la sección Ejemplo: native-activity , se proporciona una explicación detallada del archivo Android.mk de ese ejemplo. Por último, en Variables y macros se proporciona más información 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, recuerda que el sistema de compilación del NDK se 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 usa esos nombres internamente.
  • Nombres en minúscula, como my-dir El sistema de compilación también usa esos nombres internamente.

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

Variables de inclusión definidas por NDK

En esta sección, se abordan las variables GNU Make que el sistema de compilación define antes de analizar tu archivo Android.mk. En ciertas circunstancias, el NDK podría analizar tu archivo Android.mk varias veces usando una definición diferente para algunas de estas variables cada vez.

CLEAR_VARS

Esta variable apunta a una secuencia de comandos de compilación que anula la definición de prácticamente todas las variables LOCAL_XXX que se indican en la sección "Variables definidas por el programador" a continuación. Usa esta variable para incluir esta secuencia de comandos antes de describir un módulo nuevo. La sintaxis para usarla es la siguiente:

include $(CLEAR_VARS)

BUILD_SHARED_LIBRARY

Esta variable apunta a una secuencia de comandos de compilación que recopila toda la información sobre el módulo que proporcionaste en tus variables LOCAL_XXX y determina la manera de compilar una biblioteca compartida de destino a partir de las fuentes que indicaste. Ten en cuenta que para usar esta secuencia de comandos será necesario hayas asignado valores 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ódulo).

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

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 a continuación). 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 la 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. Sino que debe ser una ruta de acceso única 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 usando la variable LOCAL_PREBUILTS. Para obtener más información acerca del uso de compilaciones previas, consulta Uso de bibliotecas compiladas previamente.

PREBUILT_STATIC_LIBRARY

Lo mismo que PREBUILT_SHARED_LIBRARY, pero para una biblioteca estática compilada previamente. Para obtener más información acerca del uso de compilaciones previas, consulta Uso de bibliotecas compiladas previamente.

Variables de información objetivo

El sistema de compilación analiza Android.mk una vez por cada ABI especificada por la variable APP_ABI, que generalmente se encuentra definida en el 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 del sistema de compilación que el sistema define cada vez que analiza Android.mk.

TARGET_ARCH

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

TARGET_PLATFORM

El número de nivel de Android API al que apunta el sistema de compilación cuando analiza este archivo Android.mk. Por ejemplo, las imágenes del sistema Android 5.1 corresponden al nivel 22 de Android API: android-22. Para obtener una lista completa de los nombres de las plataformas y las imágenes del sistema Android correspondientes, consulta Android NDK Native API. En el ejemplo siguiente, se muestra la sintaxis para utilizar esta variable:

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

TARGET_ARCH_ABI

La ABI a la que apunta el sistema de compilación cuando analiza el 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 la 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 la manera de 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 detalles sobre las ABI de la arquitectura y los problemas de compatibilidad asociados, 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 Android API de destino. Resulta particularmente útil cuando deseas 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 este flujo básico:

  1. Inicializa o anula la definición de variables asociadas con el módulo usando la variable CLEAR_VARS.
  2. Asigna valores a las variables empleadas para describir el módulo.
  3. Configura el sistema de compilación del NDK para usar la secuencia de comandos de compilación correcta para el módulo usando 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. El siguiente ejemplo muestra cómo hacerlo:

LOCAL_PATH := $(call my-dir)

La secuencia de comandos a la cual apunta CLEAR_VARS no borra esta variable. Por lo tanto, solo necesitas definirla una vez, aunque tu archivo Android.mk describa 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; 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 deseas que el módulo generado tenga un nombre diferente de lib + el valor de LOCAL_MODULE, puedes usar la variable LOCAL_MODULE_FILENAME para asignar el nombre que desees 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 hacer que el sistema asigne por la fuerza 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 el sistema de compilación usa para generar el módulo. Indica solo los archivos que el sistema de compilación le pasa al compilador, ya que el sistema de compilación computa automáticamente las dependencias asociadas. Ten en cuenta que puedes usar las rutas de acceso al archivo relativa (para LOCAL_PATH) y absoluta.

Te recomendamos evitar las rutas de acceso a archivos absolutas; las rutas de acceso a archivos relativas permiten 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 de .cpp para tus archivos de origen C++. Por ejemplo, la siguiente línea cambia la extensión por .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 C++ específicas. Habilita el compilador y los indicadores del vinculador correctos durante el proceso de compilación. Para ejecutables compilados previamente, esta variable también declara las funciones en las que se basa el ejecutable. Esto ayuda a garantizar 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 correcto 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 todas las fuentes (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 a través 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 pase al compilar archivos de origen C y C++. Esto puede ser útil para especificar definiciones de macro adicionales u opciones de compilación. Usa LOCAL_CPPFLAGS a fin de especificar indicadores solo para C++.

Intenta no cambiar el nivel de optimización/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 [pplication.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>,

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

LOCAL_CPPFLAGS

Conjunto opcional de indicadores de compilador que se pasará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 ejecutable 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ódulos 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 los archivos enteros, consulta la documentación del Id. de GNU para el indicador --whole-archive.

Esta variable es útil cuando hay dependencias circulares entre varias bibliotecas estáticas. Cuando uses esta variable para compilar una biblioteca compartida, hará que el sistema de compilación agregue por la fuerza todos los archivos de objetos de tus bibliotecas estáticas al ejecutable 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 pasar 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 expuestas frente a lo que puedes vincular en esta versión del NDK, consulta Android NDK Native API.

LOCAL_LDFLAGS

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 compartida, generará un error de símbolo indefinido. 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 ejecutables 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 hace que el sistema de compilación genere por la fuerza los archivos de objeto del módulo en el modo arm de 32 bits. En el siguiente ejemplo, se muestra la manera de hacerlo:

LOCAL_ARM_MODE := arm

También puedes indicar al sistema de compilación que solo compile fuentes específicas en el modo arm anexando el sufijo .arm a los nombres de archivo de origen. Por ejemplo, en el siguiente ejemplo se indica al sistema de compilación que siempre compile bar.c en el modo ARM, salvo para compilar foo.c de acuerdo con el valor de LOCAL_ARM_MODE.

LOCAL_SRC_FILES := foo.c bar.c.arm

LOCAL_ARM_NEON

Esta variable solo es importante cuando apuntas a la ABI armeabi-v7a. Permite el uso de elementos intrínsecos del compilador de SIMD avanzados de ARM (NEON) en tus fuentes C y C++, 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 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.

Como 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 preceder a .neon.

LOCAL_DISABLE_FORMAT_STRING_CHECKS

De forma predeterminada, el sistema de compilación compila código con protección de strings de formato. Esto 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 configurando el valor de esta variable en true. No recomendamos hacer esto sin un motivo que lo justifique.

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 pasa los indicadores -DFOO=1 y -DBAR=2 al compilador durante la compilación de bar.c. También agrega prefijos a los indicadores exportados al LOCAL_CFLAGS de tu módulo para que puedas anularlos fácilmente.

Además, la relación entre 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 desde 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 pasa -DFOO=1 al compilador mientras compila foo/foo.c. Para compilar 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, e indica al sistema que pase al compilador nombres de bibliotecas específicas del sistema. Agrega el prefijo -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 generalmente es útil cuando el módulo foo es una biblioteca estática y tiene código que depende de 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, debido a que libbar.so se basa en foo, también se basa en la biblioteca de registro del sistema.

LOCAL_SHORT_COMMANDS

Configura esta variable en true cuando tu módulo tenga una gran cantidad de archivos de origen o bibliotecas compartidas o estáticas dependientes. Esto fuerza al sistema de compilación a usar 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 comando acepta una cantidad máxima de 8,191 caracteres, que pueden ser muy pocos para proyectos complejos. También tiene efecto en la compilación de archivos de origen individuales y dispone prácticamente todos los indicadores del compilador en archivos de listas.

Recuerda que cualquier valor diferente de true restablecerá el comportamiento predeterminado. También puedes definir APP_SHORT_COMMANDS en tu archivo Application.mk a fin de forzar este comportamiento para todos los módulos en 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 en true al compilar bibliotecas estáticas. Al hacerlo se generará un archivo dinámico, 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 a través 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. La definición de esta variable hace 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 indicado en LOCAL_SRC_FILES, con lo cual se generará 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

"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 proporcionadas 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 muestran información textual.

my-dir

Esta macro devuelve la ruta de acceso del último archivo make que se incluyó, que generalmente es el directorio Android.mk actual. my-dir es útil para definir LOCAL_PATH al comienzo de tu archivo Android.mk. Por ejemplo:

LOCAL_PATH := $(call my-dir)

Debido al modo en el cual 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 disponiendo 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 de todos los subdirectorios de la ruta de acceso my-dir actual.

Puedes usar esta función para proporcionar al sistema de compilación jerarquías de directorios de origen anidados profundamente. De forma 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

Función que te permite buscar e incluir el archivo Android.mk de un módulo por el nombre de ese 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, e incluye su archivo Android.mk automáticamente por ti.