Android.MK

In questa pagina viene descritta la sintassi del file di build 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 del file di makefile GNU che il sistema di compilazione analizza una volta o altro ancora. Il file Android.mk è utile per definire impostazioni a livello di progetto che Application.mk, il sistema di compilazione e le variabili di ambiente lasciano non definito. 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 una libreria indipendente eseguibile. Puoi definire uno o più moduli in ogni file Android.mk e puoi 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 una varietà di altri i dettagli per te. Ad esempio, non è necessario elencare file di intestazione o delle dipendenze tra i file generati nel file Android.mk. La build NDK il sistema elabora automaticamente queste relazioni. Di conseguenza, dovrebbe poter beneficiare del supporto di una nuova catena di strumenti/piattaforma nel futuro NDK senza dover modificare il file Android.mk.

La sintassi di questo file è molto simile a quella utilizzata nei file Android.mk distribuiti con il progetto open source Android completo. 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 esaminare la sintassi in dettaglio, è utile iniziare a comprendere le nozioni di base su cosa contiene un file Android.mk. In questa sezione vengono utilizzati i Android.mk nell'esempio Hello-JNI a questo scopo, che spiega il ruolo riprodotta da 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. In questo caso, la funzione macro my-dir, fornita dal sistema di compilazione, restituisce il percorso della directory corrente (la directory contenente Android.mk file stesso).

La riga successiva dichiara la variabile CLEAR_VARS, il cui valore è il sistema di compilazione fornisce.

include $(CLEAR_VARS)

La variabile CLEAR_VARS punta a uno speciale Makefile GNU che cancella molti LOCAL_XXX variabili per te, ad esempio LOCAL_MODULE, LOCAL_SRC_FILES e LOCAL_STATIC_LIBRARIES. Tieni presente che non cancella 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)dichiari 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 nella tua 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 della libreria condivisa finale, aggiunge automaticamente il prefisso e il suffisso appropriati al nome assegnato 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++ in un modulo.

L'ultima riga consente al sistema di collegare tutti gli elementi:

include $(BUILD_SHARED_LIBRARY)

La variabile BUILD_SHARED_LIBRARY rimanda a uno script GNU Makefile che raccoglie tutte le informazioni che hai definito nelle variabili LOCAL_XXX a partire dalla include recente. Questo script determina cosa creare e come farlo.

Ci sono esempi più complessi nelle directory di esempio, con Android.mk file che puoi esaminare. Inoltre, Sample: native-activity fornisce una spiegazione dettagliata del file Android.mk del Sample. Infine, Variabili e macro fornisce ulteriori informazioni sulle variabili di questo .

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 arbitrarie. In questo caso, tieni presente che il sistema di compilazione 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 utilizza internamente.
• Nomi in minuscolo, ad esempio my-dir. Anche il sistema di compilazione li utilizza internamente.

Se devi definire le tue variabili di utilità in un file Android.mk, ti 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.

CANCELLA_VAR

Questa variabile fa riferimento a uno script di compilazione che annulla la definizione di quasi tutte le variabili LOCAL_XXX elencate nella sezione "Variabili definite dallo sviluppatore" di seguito. Usa questa per includere questo script prima di descrivere un nuovo modulo. La sintassi per è:

include $(CLEAR_VARS)

BUILD_EXECUTABLE

Questa variabile punta a uno script di build che raccoglie tutte le informazioni il modulo che hai fornito nelle variabili LOCAL_XXX e determina come creare un eseguibile di destinazione dalle origini elencate. Tieni presente che l'utilizzo di questo script richiede che tu abbia già assegnato valori a LOCAL_MODULE e LOCAL_SRC_FILES, come minimo (per ulteriori informazioni su queste variabili, consulta Voci di descrizione del modulo).

La sintassi per l'utilizzo di questa variabile è:

include $(BUILD_EXECUTABLE)

BUILD_SHARED_LIBRARY

Questa variabile punta a uno script di compilazione che raccoglie tutte le informazioni sul modulo fornito nelle variabili LOCAL_XXX e determina come compilare una libreria condivisa di destinazione dalle origini elencate. Tieni presente che l'utilizzo di lo script richiede che tu abbia già assegnato valori a LOCAL_MODULE e Almeno LOCAL_SRC_FILES (per ulteriori 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 un'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/nei pacchetti, ma può utilizzarle per compilare le 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.

LIBRERIA_CONDIVISA_PREBUILT

Punta a uno script di build utilizzato per specificare una libreria condivisa predefinita. Non mi piace in nel caso di BUILD_SHARED_LIBRARY e BUILD_STATIC_LIBRARY, in questo caso il valore LOCAL_SRC_FILES non può essere un file di origine. Deve invece essere un singolo percorso che rimandi a una libreria condivisa precompilata, ad esempio foo/libfoo.so. La sintassi per l'utilizzo è:

include $(PREBUILT_SHARED_LIBRARY)

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

PREBUILT_STATIC_LIBRARY

Uguale a PREBUILT_SHARED_LIBRARY, ma per una libreria statica predefinita. Per Per saperne 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 ABI specificato dalla variabile APP_ABI, che in genere è definita nel file Application.mk. Se APP_ABI è all, il sistema di compilazione analizza Android.mk una volta per ogni ABI supportato dall'NDK. In questa sezione vengono descritte le variabili definite dal sistema di compilazione ogni volta che viene analizza Android.mk.

ARCHIVIO_TARGET

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

PIATTAFORMA_TARGET

Il numero a livello di API Android scelto come target dal sistema di compilazione durante l'analisi. Android.mk. Ad esempio, le immagini di sistema Android 5.1 corrispondono 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 scelta come target dal sistema di compilazione durante l'analisi di questo file Android.mk. La tabella 1 mostra l'impostazione ABI utilizzata per ogni CPU e architettura supportata.

Tabella 1. Impostazioni ABI per CPU e architetture diverse.

L'esempio seguente mostra come verificare la presenza di ARMv8 AArch64 come combinazione di 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.

Le nuove ABI target in futuro avranno valori diversi.

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. Ciascuna la descrizione del modulo deve seguire questo flusso di base:

1. Inizializza o definisce le variabili associate al modulo utilizzando la variabile CLEAR_VARS.
2. Assegna 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.

PERCORSO LOCALE

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

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 tutti i moduli e non devono 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. Nei file Android.mk e Application.mk, fai riferimento al modulo con il nome non modificato. Ad esempio, riga genera 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 di 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 sostituire i nomi utilizzati per impostazione predefinita dal sistema di compilazione per i file generati. Ad esempio, se il nome del tuo 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 genererà un file chiamato libnewfoo.so.

LOCAL_SRC_FILES

Questa variabile contiene l'elenco dei file di origine utilizzati dal sistema di compilazione per generare il modulo. Elenca solo i file effettivamente trasmessi dal sistema di compilazione al compilatore, dato che il sistema di compilazione calcola automaticamente eventuali delle dipendenze. Tieni presente che puoi utilizzare sia valori relativi (per LOCAL_PATH) che assoluti percorsi di archiviazione dei file.

Consigliamo di evitare percorsi di file assoluti, per i percorsi relativi, Android.mk per rendere più portabile il file.

LOCAL_CPP_EXTENSION

Puoi utilizzare questa variabile facoltativa per indicare un'estensione del file diversa da .cpp per i file sorgente C++. Ad esempio, la riga seguente modifica 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 così 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 usare i flag appropriati per in ogni 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

Per questa variabile puoi anche specificare più valori. 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 Directory NDK root, da aggiungere al percorso di ricerca di inclusione durante la compilazione di tutte (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.

LOCAL_ASMFLAGS

Flag che verranno passati a yasm durante la compilazione dei 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 definizioni di macro o opzioni di compilazione aggiuntive. Utilizza LOCAL_CPPFLAGS per specificare i flag solo per C++. Utilizza LOCAL_CONLYFLAGS per specificare i 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 utilizzando le informazioni pertinenti nel file Application.mk. In questo modo per generare file di dati utili utilizzati durante il debug.

È possibile specificare percorsi di inclusione aggiuntivi scrivendo:

LOCAL_CFLAGS += -I<path>,

È comunque meglio utilizzare LOCAL_C_INCLUDES a questo scopo, dato che rende possibile l'utilizzo dei percorsi disponibili per il debug nativo con ndk-gdb.

LOCAL_CONLYFLAGS

Flag che verranno passati a Clang durante la compilazione di sorgenti C. Non mi piace LOCAL_CFLAGS, LOCAL_CONLYFLAGS non verranno passati a Clang durante la compilazione C++ o assembly.

LOCAL_CPPFLAGS

Set facoltativo di flag del compilatore che verranno passati durante la creazione dell'origine C++ solo file. Verranno visualizzati dopo il LOCAL_CFLAGS nella barra dalla riga di comando. Utilizza LOCAL_CFLAGS per specificare i flag sia per C che per C++.

LIBRERIE_STATICHE_LOCALI

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

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

Se il modulo corrente è una libreria statica, questa variabile indica semplicemente che gli altri moduli che dipendono da quello corrente dipenderanno anche 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 il le informazioni corrispondenti nel file generato.

LOCAL_WHOLE_STATIC_LIBRARIES

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

Questa variabile è utile quando esistono dipendenze circolari tra più librerie statiche. Quando utilizzi questa variabile per creare una libreria condivisa, questa costringe il sistema di compilazione ad aggiungere tutti i file oggetto delle librerie statiche alla binario finale. Lo stesso non è vero, però, quando si generano gli eseguibili.

LOCAL_LDLIBS

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

LOCAL_LDLIBS := -lz

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

FLAG_LOCALI

L'elenco di altri flag del linker che il sistema di compilazione può utilizzare durante la creazione libreria condivisa o eseguibile. 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 compilare un elemento condiviso, viene generato un errore simbolo non definito. Questo può aiutarti a individuare i bug nel 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 esecuzione.

LOCAL_ARM_MODE

Per impostazione predefinita, il sistema di compilazione genera file binari di destinazione ARM in modalità thumb. in cui ogni istruzione è larga 16 bit e collegata alle librerie STL del Directory thumb/. La definizione di questa variabile come arm obbliga il sistema di compilazione a generare i file oggetto del modulo in modalità arm a 32 bit. Nell'esempio che segue mostra come fare:

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 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 di utilizzare le istruzioni intrinseche del compilatore ARM Advanced SIMD (NEON) nei file di origine 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 usare in sicurezza questo codice in fase di runtime. Per ulteriori informazioni, vedi Assistenza Neon e Funzionalità della 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 per pollici e neon, bar.c con pollice e zoo.c con supporto per 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 da stringhe di formato. Attività quindi forza un errore del compilatore se in una stringa di formato non costante viene utilizzata Funzione di tipo printf. Questa protezione è attiva per impostazione predefinita, ma puoi disattivarla impostando il valore di questa variabile su true. Sconsigliamo di farlo senza un valido motivo.

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 al prompt LOCAL_CFLAGS in modo da poterli facilmente sostituire.

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

Infine, il sistema di compilazione non usa flag esportati quando crea in locale (ad es. creando il modulo di cui esporta i flag). Pertanto, nell'esempio in alto, non passa -DFOO=1 al compilatore durante la creazione di foo/foo.c. Per eseguire la compilazione localmente, utilizza LOCAL_CFLAGS.

ESPORTAZIONE_LOCALE_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.

ESPORTAZIONE_LOCALIZZATA_LDLIB

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

Tieni presente che il sistema di compilazione aggiunge i flag del linker importati al valore del tuo della variabile LOCAL_LDLIBS del modulo. Ciò è dovuto al funzionamento dei linker Unix.

Questa variabile è in genere utile quando il modulo foo è una libreria statica e ha che dipende da una libreria di sistema. Dopodiché potrai utilizzare LOCAL_EXPORT_LDLIBS per 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 compilazione è costretto a utilizzare la sintassi @ per gli archivi contenenti file oggetto intermedi o librerie di collegamento.

Questa funzionalità può essere utile su Windows, dove la riga di comando accetta un massimo di 8191 caratteri, che può essere troppo piccolo per progetti complessi. Inoltre, influisce sulla compilazione di singoli file sorgente, posizionando quasi tutto il compilatore anche all'interno di file elenco.

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

Non consigliamo di attivare questa funzionalità per impostazione predefinita, poiché rallenta la compilazione.

LOCAL_THIN_ARCHIVE

Imposta questa variabile su true durante la creazione di librerie statiche. In questo modo generare un archivio sottile, ovvero un file di libreria che non contiene file oggetto, ma solo percorsi di file degli oggetti effettivi che normalmente contengono.

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

I valori validi sono true, false o vuoto. Puoi impostare un valore predefinito nel 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 shell autonomo che prende il nome dell'input e il nome del file di output come secondo argomento. Ad esempio:

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

Macro di funzione fornite da NDK

Questa sezione spiega le macro delle funzioni GNU Make messe a disposizione 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 di Android.mk attuale. my-dir è utile per definire LOCAL_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 del l'ultimo makefile incluso dal sistema di compilazione durante l'analisi degli script di build. Per 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 è che la seconda chiamata a my-dir definisce LOCAL_PATH come $PATH/foo anziché $PATH, perché è lì che faceva riferimento la sua include 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 del parametro prima chiamata 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 di file Android.mk situati 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, l'NDK cerca solo i file nella directory contenente il file Android.mk.

questo-makefile

Restituisce il percorso del makefile corrente (da cui il sistema di compilazione ha chiamato ).

parent-makefile

Restituisce il percorso del file make principale nell'albero di inclusione (il percorso del file make che include 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 ti consente di trovare e includere il file Android.mk di un modulo tramite il nome del modulo. Ecco un esempio tipico:

$(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.