Applicazione.mk

Questo documento illustra il file di build Application.mk utilizzato da ndk-build.

Ti consigliamo di leggere la pagina Concetti prima di questo uno.

Panoramica

Il Application.mk specifica le impostazioni a livello di progetto per ndk-build. Per impostazione predefinita, si trova all'indirizzo jni/Application.mk, nella directory del progetto dell'applicazione.

Variabili

APP_ABI

Per impostazione predefinita, il sistema di build NDK genera codice per tutte le ABI non deprecate. Tu puoi utilizzare l'impostazione APP_ABI per generare codice per ABI specifiche. La tabella 1 mostra le impostazioni di APP_ABI per i diversi set di istruzioni.

Tabella 1. Impostazioni di APP_ABI per diversi set di istruzioni.

Set di istruzioni	Valore
ARMv7 a 32 bit	APP_ABI := armeabi-v7a
ARMv8 a 64 bit (AArch64)	APP_ABI := arm64-v8a
x86	APP_ABI := x86
x86-64	APP_ABI := x86_64
Tutte le ABI supportate (impostazione predefinita)	APP_ABI := all

Puoi anche specificare più valori posizionandoli nella stessa riga, delimitati per spazi. Ad esempio:

APP_ABI := armeabi-v7a arm64-v8a x86

Per l'elenco di tutte le ABI supportate e i dettagli sul loro utilizzo e limitazioni, fai riferimento all'articolo sulle ABI Android.

APP_ASFLAGS

Flag da passare all'assemblatore per ogni file di origine dell'assemblaggio (.s e .S file) nel progetto.

APP_ASMFLAGS

Flag da passare a YASM per tutti i file di origine YASM (.asm, x86/x86_64 ).

SCRIPT_ED_CREAZIONE_APP

Per impostazione predefinita, ndk-build presuppone che il file Android.mk si trovi nella posizione jni/Android.mk rispetto alla radice del progetto.

Per caricare un file Android.mk da una posizione diversa, imposta APP_BUILD_SCRIPT al percorso assoluto del file Android.mk.

APP_CFLAGS

Flag da passare per tutte le compilazioni C/C++ nel progetto.

Vedi anche: APP_CONLYFLAGS e APP_CPPFLAGS.

APP_LINGUA_TIDY

Impostalo su true per abilitare clang-tidy per tutti i moduli del progetto. Disattivata da predefinito.

APP_CLING_TIDY_FLAGS

Contrassegni da passare per tutte le esecuzioni ordinate nel progetto.

APP_CONLYFLAGS

Flag da passare per tutte le compilazioni C nel progetto. Queste segnalazioni non saranno utilizzata per il codice C++.

Vedi anche: APP_CFLAGS, APP_CPPFLAGS.

CPPFLAGS

Flag da passare per tutte le compilazioni C++ nel progetto. Queste segnalazioni non saranno utilizzata per il codice C.

Vedi anche: APP_CFLAGS e APP_CONLYFLAGS.

APP_CXXFLAGS

Identico a APP_CPPFLAGS, ma verrà visualizzato dopo APP_CPPFLAGS nella compilazione . Ad esempio:

APP_CPPFLAGS := -DFOO
APP_CXXFLAGS := -DBAR

La configurazione precedente genererà un comando di compilazione simile a clang++ -DFOO -DBAR anziché a clang++ -DBAR -DFOO.

DEBUG APP

Impostalo su true per creare un'applicazione di cui è possibile eseguire il debug.

APP_LDFLAGS

Flag da passare durante il collegamento degli eseguibili e delle librerie condivise.

MANIFESTAZIONE_APP

Percorso assoluto di un file AndroidManifest.xml.

Per impostazione predefinita, verrà usato $(APP_PROJECT_PATH)/AndroidManifest.xml) esiste già.

MODULI_APP

Un elenco esplicito di moduli da creare. Gli elementi di questo elenco sono i nomi così come vengono visualizzati in LOCAL_MODULE all'interno del file Android.mk.

Per impostazione predefinita, ndk-build creerà tutte le librerie condivise, gli eseguibili e i relativi delle dipendenze. Le librerie statiche verranno create solo se vengono utilizzate progetto, il progetto contiene solo librerie statiche o, se sono denominate APP_MODULES.

OTTIM_APP

Definisci questa variabile facoltativa come release o debug. Rilascia file binari per impostazione predefinita.

La modalità di rilascio consente ottimizzazioni e potrebbe produrre file binari non utilizzabili con un debugger. La modalità di debug disattiva le ottimizzazioni affinché i debugger possano essere in uso.

Tieni presente che puoi eseguire il debug di file binari di release o di debug. Rilasciare file binari, ma fornire meno informazioni durante il debug. Ad esempio, le variabili possono ottimizzare l'inventario, impedendo l'ispezione. Inoltre, riordinando il codice può aumentare è difficile analizzare il codice; le analisi dello stack potrebbero non essere affidabili.

Dichiarazione di android:debuggable nel file manifest della tua applicazione <application> farà sì che questa variabile sia impostata sul valore predefinito debug anziché su release. Sostituisci questo valore predefinito impostando APP_OPTIM su release.

PIATTAFORMA_APP

APP_PLATFORM dichiara il livello API Android rispetto a cui è basata questa applicazione e corrisponde al valore minSdkVersion dell'applicazione.

Se non specificato, ndk-build sceglierà come target il livello API minimo supportato dalla NDK Il livello API minimo supportato dall'NDK più recente sarà sempre sufficientemente basso per supportare quasi tutti i dispositivi attivi.

Ad esempio, il valore android-16 specifica che la libreria utilizza API che non sono disponibili precedenti ad Android 4.1 (livello API 16) e non possono essere utilizzate sui dispositivi che esegue una versione precedente della piattaforma. Per un elenco completo dei nomi delle piattaforme immagini di sistema Android corrispondenti, consulta la sezione Annunci nativi NDK Android per le API.

Quando utilizzi Gradle e externalNativeBuild, questo parametro non deve essere impostato strato Add. Imposta invece la proprietà minSdkVersion nel campo defaultConfig o productFlavors blocchi di file build.gradlea livello di modulo. Questo assicura che la raccolta sia utilizzata solo dalle app installate su dispositivi su cui è in esecuzione un di Android adeguato.

Tieni presente che l'NDK non contiene librerie per ogni livello API di Android. Le versioni che non includevano nuove API native vengono omesse per risparmiare spazio nella NDK ndk-build usa, in ordine decrescente di preferenza:

1. La versione della piattaforma corrispondente a APP_PLATFORM.
2. Il successivo livello API disponibile inferiore a APP_PLATFORM. Ad esempio, android-19 verrà utilizzato quando APP_PLATFORM è android-20, poiché non c'erano nuovi le API native in Android-20.
3. Il livello API minimo supportato dall'NDK.

PERCORSO_APP_PROGETTO

Il percorso assoluto della directory principale del progetto.

APP_SHORT_Comandi

L'equivalente a livello di progetto di LOCAL_SHORT_COMMANDS. Per ulteriori informazioni, vedi la documentazione di LOCAL_SHORT_COMMANDS in Android.mk.

APP_STL

La libreria standard C++ da utilizzare per questa applicazione.

Per impostazione predefinita viene utilizzato l'STL system. Altre opzioni sono c++_shared, c++_static e none. Vedi Runtime C++ di NDK e Funzionalità.

MODALITÀ_STRIP_APP

L'argomento da passare a strip per i moduli in questa applicazione. Valori predefiniti a --strip-unneeded. Per evitare di rimuovere tutti i file binari nel modulo, imposta su none. Per altre modalità strip, consulta la sezione Strip documentazione.

APP_THIN_ARCHIVE

Imposta il valore su true per utilizzare gli archivi thin per tutte le librerie statiche del progetto. Per ulteriori informazioni, consulta la documentazione per LOCAL_THIN_ARCHIVE in Android.mk.

APP_WRAP_SH

Percorso del file wrap.sh da includere nell'applicazione.

Per ogni ABI esiste una variante di questa variabile, così come una variante generica ABI:

• APP_WRAP_SH
• APP_WRAP_SH_armeabi-v7a
• APP_WRAP_SH_arm64-v8a
• APP_WRAP_SH_x86
• APP_WRAP_SH_x86_64

di Gemini Advanced.