Android.MK

Questa pagina descrive la sintassi del file di compilazione Android.mk utilizzato da ndk-build.

Panoramica

Il file Android.mk si trova in una sottodirectory della directory jni/ del progetto e descrive le origini e le librerie condivise al sistema di compilazione. Si tratta in realtà di un piccolo frammento di file make GNU che il sistema di compilazione analizza una o più volte. Il file Android.mk è utile per definire le impostazioni a livello di progetto che Application.mk, il sistema di compilazione e le variabili di ambiente lasciano predefinite. Può anche sostituire le impostazioni a livello di progetto per moduli specifici.

La sintassi di Android.mk ti consente di raggruppare le origini in moduli. Un modulo è una libreria statica, una libreria condivisa o un eseguibile autonomo. Puoi definire uno o più moduli in ogni file Android.mk e utilizzare lo stesso file di origine in più moduli. Il sistema di compilazione inserisce solo le librerie condivise nel pacchetto dell'applicazione. Inoltre, le librerie statiche possono generare librerie condivise.

Oltre alla pacchettizzazione delle librerie, il sistema di compilazione gestisce per te una serie di altri dettagli. Ad esempio, non è necessario elencare i file di intestazione o le dipendenze esplicite tra i file generati nel file Android.mk. Il sistema di build NDK calcola automaticamente queste relazioni per te. Di conseguenza, dovresti essere in grado di usufruire del nuovo supporto della piattaforma/toolchain nelle release NDK future senza dover modificare il file Android.mk.

La sintassi di questo file è molto simile a quella utilizzata nei file Android.mk distribuiti con l'intero Android Open Source Project. Sebbene l'implementazione del sistema di compilazione che le utilizza sia diversa, la loro somiglianza è una decisione di progettazione intenzionale volta a semplificare il riutilizzo del codice sorgente per le librerie esterne da parte degli sviluppatori di applicazioni.

Nozioni di base

Prima di esplorare la sintassi in dettaglio, è utile comprendere le nozioni di base sul contenuto di un file Android.mk. A questo scopo, questa sezione utilizza il file Android.mk nell'esempio Hello-JNI, spiegando il ruolo di ogni riga del file.

Un file Android.mk deve iniziare definendo la variabile LOCAL_PATH:

LOCAL_PATH := $(call my-dir)

Questa variabile indica la posizione dei file di origine nell'albero di sviluppo. Qui, la funzione macro my-dir, fornita dal sistema di compilazione, restituisce il percorso della directory corrente (la directory contenente il file Android.mk stesso).

La riga successiva dichiara la variabile CLEAR_VARS, il cui valore viene fornito dal sistema di compilazione.

include $(CLEAR_VARS)

La variabile CLEAR_VARS punta a uno speciale Makefile GNU che cancella per te molte variabili LOCAL_XXX, come LOCAL_MODULE, LOCAL_SRC_FILES e LOCAL_STATIC_LIBRARIES. Tieni presente che questa operazione non consente di cancellare LOCAL_PATH. Questa variabile deve mantenere il proprio valore perché il sistema analizza tutti i file di controllo della compilazione in un unico contesto di esecuzione di GNU Make in cui tutte le variabili sono globali. Devi (ri)dichiarare questa variabile prima di descrivere ogni modulo.

Successivamente, la variabile LOCAL_MODULE memorizza il nome del modulo da compilare. Utilizza questa variabile una volta per modulo nell'applicazione.

LOCAL_MODULE := hello-jni

Ogni nome del modulo deve essere univoco e non deve contenere spazi. Il sistema di compilazione, quando genera il file finale della libreria condivisa, aggiunge automaticamente il prefisso e il suffisso corretti al nome che assegni a LOCAL_MODULE. Ad esempio, l'esempio riportato sopra genera una libreria denominata libhello-jni.so.

La riga successiva enumera i file di origine, con gli spazi che delimitano più file:

LOCAL_SRC_FILES := hello-jni.c

La variabile LOCAL_SRC_FILES deve contenere un elenco di file di origine C e/o C++ da integrare in un modulo.

L'ultima riga aiuta il sistema a collegare tutto:

include $(BUILD_SHARED_LIBRARY)

La variabile BUILD_SHARED_LIBRARY punta a uno script GNU Makefile che raccoglie tutte le informazioni definite nelle variabili LOCAL_XXX a partire dall'ultimo include. Questo script determina cosa creare e come farlo.

Nelle directory dei Samples sono disponibili esempi più complessi, con file Android.mk commentati che puoi esaminare. Inoltre, Sample: native-activity fornisce una spiegazione dettagliata del file Android.mk del Sample. Infine, la sezione Variabili e macro fornisce ulteriori informazioni sulle variabili di questa sezione.

Variabili e macro

Il sistema di compilazione fornisce molte possibili variabili da utilizzare nel file Android.mk. Molte di queste variabili sono dotate di valori preassegnati. Le altre, invece, le assegni tu.

Oltre a queste variabili, puoi anche definirne di tue. In questo caso, tieni presente che il sistema di build NDK riserva i seguenti nomi di variabili:

• Nomi che iniziano con LOCAL_, ad esempio LOCAL_MODULE.
• Nomi che iniziano con PRIVATE_, NDK_ o APP. Il sistema di compilazione li utilizza internamente.
• Nomi in minuscolo, ad esempio my-dir. Il sistema di compilazione li utilizza anche internamente.

Se devi definire le tue variabili di utilità in un file Android.mk, consigliamo di anteporre MY_ ai relativi nomi.

Variabili di inclusione definite da NDK

Questa sezione illustra le variabili GNU Make definite dal sistema di compilazione prima di analizzare il file Android.mk. In determinate circostanze, l'NDK potrebbe analizzare il file Android.mk più volte, utilizzando ogni volta una definizione diversa per alcune di queste variabili.

CLEAR_VARS

Questa variabile punta a uno script di build che non definisce quasi tutte le variabili LOCAL_XXX elencate nella sezione "Variabili definite dallo sviluppatore" di seguito. Utilizza questa variabile per includere questo script prima di descrivere un nuovo modulo. La sintassi per utilizzarlo è:

include $(CLEAR_VARS)

BUILD_EXECUTABLE

Questa variabile rimanda a uno script di build che raccoglie tutte le informazioni sul modulo che hai fornito nelle variabili LOCAL_XXX e determina come creare un eseguibile di destinazione dalle origini elencate. Tieni presente che per utilizzare questo script è necessario che tu abbia già assegnato valori a LOCAL_MODULE e LOCAL_SRC_FILES almeno (per maggiori informazioni su queste variabili, consulta Variabili di descrizione del modulo).

La sintassi per l'utilizzo di questa variabile è:

include $(BUILD_EXECUTABLE)

CREA_LIBRERIA_CONDIVISA

Questa variabile rimanda a uno script di build che raccoglie tutte le informazioni sul modulo che hai fornito nelle variabili LOCAL_XXX e determina come creare una libreria condivisa di destinazione dalle origini elencate. Tieni presente che per utilizzare questo script è necessario che tu abbia già assegnato valori a LOCAL_MODULE e LOCAL_SRC_FILES almeno (per maggiori informazioni su queste variabili, consulta Variabili di descrizione del modulo).

La sintassi per l'utilizzo di questa variabile è:

include $(BUILD_SHARED_LIBRARY)

Una variabile della libreria condivisa fa sì che il sistema di compilazione generi un file della libreria con estensione .so.

LIBRERIA_STATIC_DI_CREAZIONE

Una variante di BUILD_SHARED_LIBRARY utilizzata per creare una libreria statica. Il sistema di compilazione non copia le librerie statiche nel progetto o nei pacchetti, ma può utilizzarle per creare librerie condivise (vedi LOCAL_STATIC_LIBRARIES e LOCAL_WHOLE_STATIC_LIBRARIES di seguito). La sintassi per l'utilizzo di questa variabile è:

include $(BUILD_STATIC_LIBRARY)

Una variabile static-library fa sì che il sistema di compilazione generi una libreria con un'estensione.a.

PREBUILT_SHARED_LIBRARY

Punta a uno script di build utilizzato per specificare una libreria condivisa predefinita. A differenza del caso di BUILD_SHARED_LIBRARY e BUILD_STATIC_LIBRARY, qui il valore di LOCAL_SRC_FILES non può essere un file di origine. Deve invece essere un unico percorso a una libreria condivisa predefinita, come foo/libfoo.so. La sintassi per l'utilizzo di questa variabile è:

include $(PREBUILT_SHARED_LIBRARY)

Puoi anche fare riferimento a una libreria predefinita in un altro modulo utilizzando la variabile LOCAL_PREBUILTS. Per ulteriori informazioni sull'utilizzo dei precompilati, consulta Utilizzare le librerie precompilate.

LIBRERIA_STATIC_PREBUILT

Lo stesso di PREBUILT_SHARED_LIBRARY, ma per una libreria statica precompilata. Per scoprire di più sull'utilizzo delle librerie predefinite, consulta Utilizzare le librerie predefinite.

Variabili di informazioni target

Il sistema di compilazione analizza Android.mk una volta per ogni ABI specificata dalla variabile APP_ABI, che in genere viene definita nel file Application.mk. Se APP_ABI è all, il sistema di compilazione analizza Android.mk una volta per ogni ABI supportato dall'NDK. Questa sezione descrive le variabili che il sistema di compilazione definisce ogni volta che analizza Android.mk.

TARGET_ARCH

La famiglia di CPU a cui è destinato il sistema di compilazione durante l'analisi di questo Android.mk file. Questa variabile può essere una delle seguenti: arm, arm64, x86 o x86_64.

TARGET_PLATFORM

Il numero del livello API Android di destinazione del sistema di compilazione durante l'analisi del fileAndroid.mk. Ad esempio, le immagini di sistema di Android 5.1 corrispondono al livello API Android 22: android-22. Per un elenco completo dei nomi delle piattaforme e delle immagini di sistema Android corrispondenti, consulta API native. L'esempio seguente mostra la sintassi per l'utilizzo di questa variabile:

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

TARGET_ARCH_ABI

L'ABI a cui il sistema di compilazione esegue il targeting durante l'analisi del file Android.mk. La tabella 1 mostra l'impostazione ABI utilizzata per ciascuna CPU e architettura supportate.

Tabella 1. Impostazioni ABI per CPU e architetture diverse.

CPU e architettura	Impostazione
ARMv7	armeabi-v7a
ARMv8 AArch64	arm64-v8a
i686	x86
x86-64	x86_64

L'esempio seguente mostra come verificare la presenza di ARMv8 AArch64 come combinazione CPU-e ABI di destinazione:

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

Per ulteriori dettagli sulle ABI dell'architettura e sui problemi di compatibilità associati, consulta le ABI di Android.

I nuovi ABI target avranno valori diversi in futuro.

TARGET_ABI

Una concatenazione del livello API Android target e dell'ABI. È particolarmente utile quando vuoi eseguire il test in base a un'immagine di sistema di destinazione specifica per un dispositivo reale. Ad esempio, per controllare un dispositivo ARM a 64 bit in esecuzione sul livello API Android 22:

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

Variabili di descrizione del modulo

Le variabili in questa sezione descrivono il modulo al sistema di compilazione. Ogni descrizione del modulo deve seguire questo flusso di base:

1. Inizializza o non definisci le variabili associate al modulo utilizzando la variabile CLEAR_VARS.
2. Assegna dei valori alle variabili utilizzate per descrivere il modulo.
3. Imposta il sistema di compilazione NDK in modo che utilizzi lo script di compilazione appropriato per il modulo, utilizzando la variabile BUILD_XXX.

LOCAL_PATH

Questa variabile viene utilizzata per indicare il percorso del file corrente. Devi definirlo all'inizio del file Android.mk. L'esempio seguente mostra come fare:

LOCAL_PATH := $(call my-dir)

Lo script a cui punta CLEAR_VARS non cancella questa variabile. Pertanto, devi definirlo una sola volta, anche se il file Android.mk descrive più moduli.

MODULO_LOCALE

Questa variabile memorizza il nome del modulo. Deve essere univoco tra i nomi di tutti i moduli e non deve contenere spazi. Devi definirlo prima di includere qualsiasi script (diverso da quello per CLEAR_VARS). Non devi aggiungere il prefisso lib o l'estensione del file .so o .a; il sistema di compilazione apporta queste modifiche automaticamente. In tutti i file Android.mk e Application.mk, fai riferimento al modulo con il nome non modificato. Ad esempio, la seguente riga genera la generazione di un modulo della libreria condivisa denominato libfoo.so:

LOCAL_MODULE := "foo"

Se vuoi che il modulo generato abbia un nome diverso da lib + il valore LOCAL_MODULE, puoi utilizzare la variabile LOCAL_MODULE_FILENAME per assegnare al modulo generato un nome a tua scelta.

LOCAL_MODULE_FILENAME

Questa variabile facoltativa consente di eseguire l'override dei nomi che il sistema di compilazione utilizza per impostazione predefinita per i file che genera. Ad esempio, se il nome di LOCAL_MODULE è foo, puoi forzare il sistema a chiamare il file che genera libnewfoo. L'esempio seguente mostra come eseguire questa operazione:

LOCAL_MODULE := foo
LOCAL_MODULE_FILENAME := libnewfoo

Per un modulo della libreria condivisa, questo esempio genera un file denominato libnewfoo.so.

LOCAL_SRC_FILES

Questa variabile contiene l'elenco dei file di origine che il sistema di compilazione utilizza per generare il modulo. Elenca solo i file effettivamente passati dal sistema di compilazione al compilatore, poiché il sistema di compilazione calcola automaticamente eventuali dipendenze associate. Tieni presente che puoi utilizzare percorsi dei file sia relativi (a LOCAL_PATH) che assoluti.

Ti consigliamo di evitare percorsi file assoluti; i percorsi relativi rendono il file Android.mk più portabile.

LOCAL_CPP_EXTENSION

Puoi utilizzare questa variabile facoltativa per indicare un'estensione di file diversa da.cpp per i file di origine C++. Ad esempio, la riga seguente cambia l'estensione in .cxx. L'impostazione deve includere il punto.

LOCAL_CPP_EXTENSION := .cxx

Puoi utilizzare questa variabile per specificare più estensioni. Ad esempio:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

LOCAL_CPP_FEATURES

Puoi utilizzare questa variabile facoltativa per indicare che il codice si basa su funzionalità C++ specifiche. Attiva i flag del compilatore e del linker corretti durante il processo di compilazione. Per i binari precompilati, questa variabile dichiara anche le funzionalità da cui dipende il binario, contribuendo a garantire il corretto funzionamento del collegamento finale. Ti consigliamo di utilizzare questa variabile anziché attivare -frtti e -fexceptions direttamente nella definizione di LOCAL_CPPFLAGS.

L'uso di questa variabile consente al sistema di compilazione di utilizzare i flag appropriati per ciascun modulo. L'utilizzo di LOCAL_CPPFLAGS fa sì che il compilatore utilizzi tutti i flag specificati per tutti i moduli, indipendentemente dalle esigenze effettive.

Ad esempio, per indicare che il codice utilizza RTTI (RunTime Type Information), scrivi:

LOCAL_CPP_FEATURES := rtti

Per indicare che il codice utilizza eccezioni C++, scrivi:

LOCAL_CPP_FEATURES := exceptions

Puoi anche specificare più valori per questa variabile. Ad esempio:

LOCAL_CPP_FEATURES := rtti features

L'ordine in cui descrivi i valori non è importante.

LOCAL_C_INCLUDES

Puoi utilizzare questa variabile facoltativa per specificare un elenco di percorsi, relativi alla directory root NDK, da aggiungere al percorso di ricerca delle include durante la compilazione di tutti i sorgenti (C, C++ e assembly). Ad esempio:

LOCAL_C_INCLUDES := sources/foo

Oppure:

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

Definisci questa variabile prima di impostare eventuali flag di inclusione corrispondenti tramite LOCAL_CFLAGS o LOCAL_CPPFLAGS.

Il sistema di compilazione utilizza automaticamente anche i percorsi LOCAL_C_INCLUDES quando avvia il debugging nativo con ndk-gdb.

LOCAL_ASFLAG

Indicatori che verranno passati a Clang durante la compilazione dei file .s o .S.

ASMFLAG LOCALI

Contrassegni che verranno passati a Yasm durante la creazione di file .asm.

CFLAG LOCALI

Indicatori che verranno passati a Clang durante la compilazione di file di origine C, C++ e di alcuni assembly (.s e .S, ma non .asm). Questa operazione può essere utile per specificare ulteriori definizioni di macro o opzioni di compilazione. Usa LOCAL_CPPFLAGS per specificare i flag solo per C++. Utilizza LOCAL_CONLYFLAGS per specificare flag solo per C.

Cerca di non modificare il livello di ottimizzazione/debug nel file Android.mk. Il sistema di compilazione può gestire automaticamente questa impostazione per te, utilizzando le informazioni pertinenti nel file Application.mk. In questo modo il sistema di compilazione può generare file di dati utili utilizzati durante il debug.

È possibile specificare percorsi di inclusione aggiuntivi scrivendo:

LOCAL_CFLAGS += -I<path>,

Tuttavia, è preferibile utilizzare LOCAL_C_INCLUDES per questo scopo, poiché in questo modo è possibile utilizzare anche i percorsi disponibili per il debug nativo con ndk-gdb.

LOCAL_CONLYFLAG

Flag che verranno passati a Clang durante la compilazione delle sorgenti C. A differenza di LOCAL_CFLAGS, LOCAL_CONLYFLAGS non verrà passato a Clang durante la compilazione C++ o delle origini assembly.

CPPFLAG LOCALI

Un insieme facoltativo di flag del compilatore che verranno passati durante la compilazione solo dei file di codice sorgente C++. Verranno visualizzati dopo LOCAL_CFLAGS sulla riga di comando del compilatore. Utilizza LOCAL_CFLAGS per specificare i flag sia per C che per C++.

LOCAL_STATIC_LIBRARIES

Questa variabile memorizza l'elenco dei moduli delle librerie statiche su cui dipende il modulo corrente.

Se il modulo attuale è una libreria condivisa o un eseguibile, questa variabile fornirà il collegamento di queste librerie nel file binario risultante.

Se il modulo attuale è una libreria statica, questa variabile indica semplicemente che altri moduli a seconda di quello attuale dipenderanno anch'essi dalle librerie elencate.

LIBRERIE_LOCAL_SHARED_LIBRARI

Questa variabile è l'elenco dei moduli delle librerie condivise su cui questo modulo dipende in fase di esecuzione. Queste informazioni sono necessarie al momento del collegamento e per incorporare le informazioni corrispondenti nel file generato.

LIBRERIE_STATICHE_INTERE_LOCALI

Questa variabile è una variante di LOCAL_STATIC_LIBRARIES ed indica che il linker deve trattare i moduli della libreria associati come interi archivi. Per maggiori informazioni su interi archivi, consulta la documentazione di GNU ld per il flag --whole-archive.

Questa variabile è utile quando sono presenti dipendenze circolari tra diverse librerie statiche. Quando utilizzi questa variabile per creare una libreria condivisa, questo obbliga il sistema di compilazione ad aggiungere tutti i file oggetto delle tue librerie statiche al programma binario finale. Lo stesso non vale, però, per la generazione di file eseguibili.

LIBRE_LOCALI

Questa variabile contiene l'elenco di flag linker aggiuntivi da utilizzare nella creazione della libreria condivisa o dell'eseguibile. Ti consente di utilizzare il prefisso -l per trasmettere il nome di librerie di sistema specifiche. Ad esempio, l'esempio seguente indica al linker di generare un modulo che collega a /system/lib/libz.so al momento del caricamento:

LOCAL_LDLIBS := -lz

Per l'elenco delle librerie di sistema esposte a cui puoi collegarti in questa release NDK, consulta API native.

FLAG_LOCALI

L'elenco di altri flag del linker da utilizzare dal sistema di compilazione durante la compilazione della biblioteca o dell'eseguibile condiviso. Ad esempio, per utilizzare il linker ld.bfd su ARM/X86:

LOCAL_LDFLAGS += -fuse-ld=bfd

LOCAL_ALLOW_UNDEFINED_SYMBOLS

Per impostazione predefinita, quando il sistema di compilazione rileva un riferimento non definito durante il tentativo di creare un file condiviso, genera un errore di simbolo indefinito. Questo errore può aiutarti a individuare i bug nel tuo codice sorgente.

Per disattivare questo controllo, imposta questa variabile su true. Tieni presente che questa impostazione potrebbe causare il caricamento della libreria condivisa in fase di runtime.

LOCAL_ARM_MODE

Per impostazione predefinita, il sistema di build genera binari di destinazione ARM in modalità thumb, dove ogni istruzione ha una larghezza di 16 bit ed è collegata alle librerie STL nella directory thumb/. La definizione di questa variabile come arm forza il sistema di compilazione a generare i file oggetto del modulo in modalità arm a 32 bit. L'esempio seguente mostra come eseguire questa operazione:

LOCAL_ARM_MODE := arm

Puoi anche indicare al sistema di compilazione di compilare solo origini specifiche in modalità arm aggiungendo il suffisso .arm ai nomi dei file di origine. Ad esempio, l'esempio seguente indica al sistema di compilazione di compilare sempre bar.c in modalità ARM, ma di creare foo.c in base al valore di LOCAL_ARM_MODE.

LOCAL_SRC_FILES := foo.c bar.c.arm

LOCAL_ARM_NEON

Questa variabile è importante solo se scegli come target l'ABI armeabi-v7a. Consente l'utilizzo dei componenti intrinseci del compilatore ARM Advanced SIMD (NEON) nelle origini C e C++, nonché le istruzioni NEON nei file Assembly.

Tieni presente che non tutte le CPU basate su ARMv7 supportano le estensioni del set di istruzioni NEON. Per questo motivo, devi eseguire un rilevamento del runtime per poter utilizzare questo codice in modo sicuro in fase di runtime. Per ulteriori informazioni, consulta Supporto Neon e Funzionalità CPU.

In alternativa, puoi utilizzare il suffisso .neon per specificare che il sistema di compilazione deve compilare solo file di origine specifici con il supporto di NEON. Nell'esempio seguente, il sistema di compilazione compila foo.c con il supporto di Thumb e Neon, bar.c con il supporto di Thumb e zoo.c con il supporto di ARM e NEON:

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

Se utilizzi entrambi i suffissi, .arm deve precedere .neon.

LOCAL_DISABLE_FORMAT_STRING_CHECKS

Per impostazione predefinita, il sistema di compilazione compila il codice con la protezione delle stringhe di formato. In questo modo viene forzato un errore del compilatore se in una funzione in stile printf viene utilizzata una stringa di formato non costante. Questa protezione è attiva per impostazione predefinita, ma puoi disattivarla impostando il valore di questa variabile su true. Sconsigliamo di farlo senza un motivo convincente.

ESPORTAZIONE_LOCALE_CFLAGS

Questa variabile registra un insieme di flag del compilatore C/C++ da aggiungere alla definizione di LOCAL_CFLAGS di qualsiasi altro modulo che lo utilizza tramite le variabili LOCAL_STATIC_LIBRARIES o LOCAL_SHARED_LIBRARIES.

Ad esempio, considera la seguente coppia di moduli: foo e bar, che dipende da 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)

Qui il sistema di compilazione passa i flag -DFOO=1 e -DBAR=2 al compilatore durante la compilazione di bar.c. Inoltre, antepone i flag esportati all'oggetto LOCAL_CFLAGS del modulo per consentirti di eseguirne facilmente l'override.

Inoltre, la relazione tra i moduli è transitiva: se zoo dipende da bar, che a sua volta dipende da foo, zoo eredita anche tutti i flag esportati da foo.

Infine, il sistema di compilazione non utilizza i flag esportati durante la compilazione locale (ovvero la compilazione del modulo di cui sta esportando i flag). Pertanto, nell'esempio precedente, non passa -DFOO=1 al compilatore durante la creazione di foo/foo.c. Per creare in locale, utilizza invece LOCAL_CFLAGS.

LOCAL_EXPORT_CPPFLAGS

Questa variabile è uguale a LOCAL_EXPORT_CFLAGS, ma solo per i flag C++.

LOCAL_EXPORT_C_INCLUDES

Questa variabile è uguale a LOCAL_EXPORT_CFLAGS, ma per C include i percorsi. È utile nei casi in cui, ad esempio, bar.c debba includere le intestazioni del modulo foo.

LOCAL_EXPORT_LDFLAGS

Questa variabile è uguale a LOCAL_EXPORT_CFLAGS, ma per i flag linker.

LOCAL_EXPORT_LDLIBS

Questa variabile è uguale a LOCAL_EXPORT_CFLAGS e indica al sistema di build di passare i nomi delle librerie di sistema specifiche al compilatore. Anteponi -l al nome di ogni libreria specificata.

Tieni presente che il sistema di compilazione aggiunge i flag del linker importati al valore della variabile LOCAL_LDLIBS del modulo. Questo accade a causa del funzionamento dei linker di Unix.

Questa variabile è in genere utile quando il modulo foo è una libreria statica e ha codice che dipende da una libreria di sistema. Puoi quindi utilizzare LOCAL_EXPORT_LDLIBS per esportare la dipendenza. Ad esempio:

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)

In questo esempio, il sistema di compilazione inserisce -llog alla fine del comando linker quando crea libbar.so. In questo modo, il linker viene informato che, poiché libbar.so dipende da foo, dipende anche dalla libreria di registrazione di sistema.

LOCAL_SHORT_COMMANDS

Imposta questa variabile su true quando il modulo ha un numero molto elevato di origini e/o librerie statiche o condivise dipendenti. In questo modo, il sistema di build deve utilizzare la sintassi @ per gli archivi contenenti file di oggetti intermedi o librerie di collegamento.

Questa funzionalità può essere utile su Windows, dove la riga di comando accetta un massimo di 8191 caratteri, che potrebbero essere troppo piccoli per progetti complessi. Riguarda anche la compilazione di singoli file di origine, inserendo quasi tutti i flag del compilatore anche all'interno dei file di elenco.

Tieni presente che qualsiasi valore diverso da true ripristinerà il comportamento predefinito. Puoi anche definire APP_SHORT_COMMANDS nel file Application.mk per forzare questo comportamento per tutti i moduli del progetto.

Sconsigliamo di abilitare questa funzionalità per impostazione predefinita, poiché rallenta la build.

ARCHIVIO_LOCALE_THIN

Imposta questa variabile su true quando crei librerie statiche. In questo modo verrà generato un archivio thin, un file della raccolta che non contiene file oggetto, ma solo percorsi dei file agli oggetti effettivi che normalmente conterrebbe.

Questo è utile per ridurre le dimensioni dell'output della compilazione. Lo svantaggio è che queste librerie non possono essere spostate in un'altra posizione (tutti i percorsi al loro interno sono relativi).

I valori validi sono true, false o vuoto. Puoi impostare un valore predefinito nel file Application.mk tramite la variabile APP_THIN_ARCHIVE.

LOCAL_FILTER_ASM

Definisci questa variabile come un comando shell che il sistema di compilazione utilizzerà per filtrare i file di assembly estratti o generati dai file specificati per LOCAL_SRC_FILES. La definizione di questa variabile comporta quanto segue:

1. Il sistema di compilazione genera un file assembly temporaneo da qualsiasi file di codice sorgente C o C++, anziché compilarli in un file oggetto.
2. Il sistema di compilazione esegue il comando shell in LOCAL_FILTER_ASM su qualsiasi file di Assembly temporaneo e su qualsiasi file di assembly elencato in LOCAL_SRC_FILES, generando così un altro file di assembly temporaneo.
3. Il sistema di compilazione compila questi file di assembly filtrati in un file oggetto.

Ad esempio:

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" corrisponde al compilatore, "2" al filtro e "3" all'assemblatore. Il filtro deve essere un comando a shell autonomo che prende il nome del file di input come primo argomento e il nome del file di output come secondo. Ad esempio:

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

Macro di funzioni fornite dall'NDK

Questa sezione spiega le macro di funzioni GNU Make fornite dall'NDK. Utilizza $(call <function>) per valutarle; restituiscono informazioni di testo.

mia-dir

Questa macro restituisce il percorso dell'ultimo makefile incluso, che in genere è la directory Android.mk attuale. my-dir è utile per definireLOCAL_PATH all'inizio del file Android.mk. Ad esempio:

LOCAL_PATH := $(call my-dir)

Per via del funzionamento di GNU Make, la macro restituisce il percorso dell'ultimo makefile incluso dal sistema di compilazione durante l'analisi degli script di build. Per questo motivo, non devi chiamare my-dir dopo aver incluso un altro file.

Considera ad esempio il seguente:

LOCAL_PATH := $(call my-dir)

# ... declare one module

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

LOCAL_PATH := $(call my-dir)

# ... declare another module

Il problema qui è che la seconda chiamata a my-dir definisce LOCAL_PATH come $PATH/foo anziché $PATH, perché era lì che puntava la sua inclusione più recente.

Puoi evitare questo problema inserendo altri include dopo tutto il resto nel file Android.mk. Ad esempio:

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

Se non è possibile strutturare il file in questo modo, salva il valore della prima chiamata a my-dir in un'altra variabile. Ad esempio:

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

tutti-subdir-makefiles

Restituisce l'elenco dei file Android.mk che si trovano in tutte le sottodirectory del percorso my-dir corrente.

Puoi utilizzare questa funzione per fornire al sistema di compilazione gerarchie di directory di origine nidificate in modo approfondito. Per impostazione predefinita, NDK cerca solo i file nella directory contenente il file Android.mk.

this-makefile

Restituisce il percorso del file make corrente (da cui il sistema di compilazione ha chiamato la funzione).

parent-makefile

Restituisce il percorso del makefile principale nell'albero di inclusione (il percorso del makefile che includeva quello corrente).

makefile-antenato

Restituisce il percorso del file make del nonno nell'albero di inclusione (il percorso del file make che include quello corrente).

modulo-importazione

Una funzione che consente di trovare e includere il file Android.mk di un modulo in base al nome del modulo. Un esempio tipico è il seguente:

$(call import-module,<name>)

In questo esempio, il sistema di compilazione cerca il modulo con tag <name> nell'elenco di directory a cui fa riferimento la variabile di ambiente NDK_MODULE_PATH e include automaticamente il file Android.mk.