Applicazione.mk

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

Ti consigliamo di leggere la pagina Concetti prima di questa.

Panoramica

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

Variabili

APP_ABI

Per impostazione predefinita, il sistema di compilazione NDK genera il codice per tutte le ABI non ritirate. Puoi utilizzare l'impostazione APP_ABI per generare il codice per ABI specifiche. La tabella 1 mostra le impostazioni APP_ABI per diversi set di istruzioni.

Tabella 1. 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 da spazi. Ecco alcuni esempi:

APP_ABI := armeabi-v7a arm64-v8a x86

Per l'elenco di tutte le ABI supportate e per i dettagli sul relativo utilizzo e sulle limitazioni, consulta la pagina relativa alle ABI Android.

APP_ASFLAGS

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

APP_ASMFLAGS

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

APP_CREA_SCRIPT

Per impostazione predefinita, ndk-build presuppone che il file Android.mk si trovi in jni/Android.mk rispetto alla directory principale del progetto.

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

APP_CFLAGS

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

Vedi anche: APP_CONLYFLAGS, APP_CPPFLAGS.

APP_CLING_TIDY

Impostalo su true per attivare lo clang-tidy per tutti i moduli del progetto. Disabilitato per impostazione predefinita.

FLAGS_CLANG_TIDY

Bandiere da passare per tutte le esecuzioni clangiate del progetto.

APP_CSOLOFLAGS

Flag da passare per tutte le compilazioni C nel progetto. Questi flag non saranno usati per il codice C++.

Vedi anche: APP_CFLAGS, APP_CPPFLAGS.

APP_CPPFLAGS

Flag da passare per tutte le compilazioni C++ nel progetto. Questi flag non verranno usati per il codice C.

Vedi anche: APP_CFLAGS, APP_C ONLYFLAGS.

APP_CXXFLAGS

Identico a APP_CPPFLAGS, ma verrà visualizzato dopo APP_CPPFLAGS nel comando compile. Ecco alcuni esempi:

APP_CPPFLAGS := -DFOO
APP_CXXFLAGS := -DBAR

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

DEBUG_APP

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

APP_LDFLAGS

Flag da trasmettere durante il collegamento di eseguibili e librerie condivise.

MANIFEST_APP

Percorso assoluto di un file AndroidManifest.xml.

Per impostazione predefinita, verrà utilizzato $(APP_PROJECT_PATH)/AndroidManifest.xml), se esistente.

MODULI_APP

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

Per impostazione predefinita, ndk-build crea tutte le librerie condivise, gli eseguibili e le relative dipendenze. Le librerie statiche verranno create solo se vengono utilizzate dal progetto, se il progetto contiene solo librerie statiche o se sono denominate in APP_MODULES.

OTTIMIZZAZIONE_APP

Definisci questa variabile facoltativa come release o debug. I programmi binari delle release verranno creati per impostazione predefinita.

La modalità di rilascio consente ottimizzazioni e potrebbe produrre programmi binari non utilizzabili con un debugger. La modalità di debug disabilita le ottimizzazioni in modo da poter utilizzare dei debugger.

Tieni presente che puoi eseguire il debug di programmi binari di rilascio o di debug. Tuttavia, rilascia programmi binari per fornire meno informazioni durante il debug. Ad esempio, le variabili possono essere ottimizzate, impedendo l'ispezione. Inoltre, il riordinamento del codice può rendere più difficile l'esecuzione dei passaggi; le analisi dello stack potrebbero non essere affidabili.

La dichiarazione android:debuggable nel tag <application> del manifest dell'applicazione farà sì che questa variabile venga impostata su debug anziché su release per impostazione predefinita. Sostituisci questo valore predefinito impostando APP_OPTIM su release.

PIATTAFORMA_APP

APP_PLATFORM dichiara il livello API Android in base a cui è stata sviluppata questa applicazione e corrisponde al minSdkVersion dell'applicazione.

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

Ad esempio, un valore android-16 specifica che la tua libreria utilizza API che non sono disponibili precedenti ad Android 4.1 (livello API 16) e non possono essere utilizzate su dispositivi che eseguono una versione precedente della piattaforma. Per un elenco completo dei nomi delle piattaforme e delle immagini di sistema Android corrispondenti, consulta l'articolo sulle API native NDK di Android.

Quando utilizzi Gradle e externalNativeBuild, questo parametro non deve essere impostato direttamente. Imposta invece la proprietà minSdkVersion nei blocchi defaultConfig o productFlavors del file build.gradle a livello di modulo. Ciò garantisce che la raccolta venga utilizzata solo dalle app installate su dispositivi con una versione adeguata di Android.

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 nell'NDK. ndk-build utilizza, in ordine di preferenza decrescente:

  1. La versione della piattaforma corrispondente a APP_PLATFORM.
  2. Il prossimo livello API disponibile inferiore a APP_PLATFORM. Ad esempio, android-19 verrà utilizzato quando APP_PLATFORM è android-20, dato che non erano presenti nuove API native in android-20.
  3. Il livello API minimo supportato dall'NDK.

APP_PROGETTO_PATH

Il percorso assoluto della directory principale del progetto.

APP_SHORT_COMANDI

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

APP_STL

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

Per impostazione predefinita viene utilizzato il codice STL system. Altre opzioni sono c++_shared, c++_static e none. Consulta l'articolo su funzionalità e runtime NDK C++.

MODALITÀ_APP_Strip

L'argomento da passare a strip per i moduli di questa applicazione. Il valore predefinito è --strip-unneeded. Per evitare di eliminare tutti i programmi binari nel modulo, imposta il valore su none. Per altre modalità Strip, consulta la documentazione di Strip.

ARCHIVIO_APP_THIN

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

APP_WRAP_SH

Percorso del file wrap.sh da includere in questa applicazione.

Esiste una variante di questa variabile per ogni ABI, 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