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:
- La versione della piattaforma corrispondente a
APP_PLATFORM
. - Il prossimo livello API disponibile inferiore a
APP_PLATFORM
. Ad esempio,android-19
verrà utilizzato quandoAPP_PLATFORM
èandroid-20
, dato che non erano presenti nuove API native in android-20. - 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