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 nella directory jni/Application.mk della tua applicazione.

Nota: molti di questi parametri hanno anche un equivalente per modulo. Ad esempio, APP_CFLAGS corrisponde a LOCAL_CFLAGS. In ogni caso, l'opzione specifica del modulo avrà la precedenza su quella a livello di applicazione. Per i flag vengono utilizzati entrambi, ma i flag specifici per il modulo vengono visualizzati in un secondo momento nella riga di comando, quindi possono sostituire le impostazioni a livello di progetto.

Variabili

APP_ABI

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

Tabella 1. Impostazioni di APP_ABI per diversi insiemi 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
Tutti gli ABI supportati (opzione predefinita)	APP_ABI := all

Puoi anche specificare più valori posizionandoli sulla stessa riga, delimitandoli. Ecco alcuni esempi:

APP_ABI := armeabi-v7a arm64-v8a x86

Nota: APP_ABI viene ignorato dal externalNativeBuild di Gradle. Utilizza invece un blocco abiFilters oppure, se utilizzi "APK multipli", un blocco abi all'interno di un blocco splits.

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

APP_ASFLAGS

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

Nota: ASFLAGS è diverso da ASMFLAGS. Quest'ultimo si applica in modo specifico ai file di origine YASM (vedi la sezione su APP_ASMFLAGS).

APP_ASMFLAGS

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

SCRIPT_APP

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

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

Nota: il externalNativeBuild di Gradle lo configurerà automaticamente in base alla variabile externalNativeBuild.ndkBuild.path.

APP_CFLAGS

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

Nota: i percorsi di inclusione devono utilizzare i flag LOCAL_C_INCLUDES anziché espliciti -I.

Vedi anche: APP_CONLYFLAGS, APP_CPPFLAGS.

APP_CLANG_TIDY

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

APP_CLANG_TIDY_FLAGS

Flag da passare per tutte le esecuzioni del linguaggio ordinato nel progetto.

APP_CONLYFLAGS

Flag da passare per tutte le compilazioni C nel progetto. Questi flag non verranno 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 utilizzati per il codice C.

Vedi anche: APP_CFLAGS, APP_CONLYFLAGS.

APP_CXXFLAGS

Nota: APP_CPPFLAGS deve essere preferito per APP_CXXFLAGS.

Identico a APP_CPPFLAGS, ma verrà visualizzato dopo il giorno APP_CPPFLAGS nel comando di compilazione. Ecco alcuni esempi:

APP_CPPFLAGS := -DFOO
APP_CXXFLAGS := -DBAR

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

APP_DEBUG

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

APP_LDFLAGS

Flag da trasmettere quando colleghi eseguibili e librerie condivise.

Nota: questi flag non hanno effetto sulle librerie statiche. Le librerie statiche non sono collegate.

APP_MANIFEST

Percorso assoluto a un file AndroidManifest.xml.

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

Nota: quando utilizzi externalNativeBuild, questo valore non verrà impostato da Gradle.

APP_MODULI

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

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

Nota: i moduli importati (quelli definiti negli script di build importati con $(call import-module) non verranno creati, a meno che non sia basato su un modulo da creare o elencare in APP_MODULES.

APP_OTTIMI

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

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

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

Se dichiari android:debuggable nel tag <application> del manifest dell'applicazione, per impostazione predefinita questa variabile sarà debug anziché release. Sostituisci questo valore predefinito impostando APP_OPTIM su release.

Nota: durante la creazione con externalNativeBuild, Android Studio imposterà correttamente questo flag in base al tuo sapore di build.

APP_PIATTAFORMA

APP_PLATFORM dichiara il livello API Android per cui è stata creata questa applicazione e corrisponde al valore minSdkVersion dell'applicazione.

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

Avviso: l'impostazione di APP_PLATFORM su un valore superiore a minSdkVersion di un'applicazione probabilmente genererà un'applicazione che non verrà eseguita sui dispositivi meno recenti. Nella maggior parte dei casi le librerie non riusciranno a essere caricate perché fanno riferimento a simboli non disponibili sui dispositivi meno recenti.

Ad esempio, un valore android-16 specifica che la libreria utilizza API che non sono disponibili sotto Android 4.1 (livello API 16) e non possono essere utilizzate su dispositivi con una versione della piattaforma inferiore. Per un elenco completo dei nomi delle piattaforme e delle immagini di sistema Android corrispondenti, consulta le 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 tuo file build.gradle a livello di modulo. In questo modo puoi assicurarti che la raccolta venga utilizzata soltanto dalle app installate sui dispositivi che eseguono 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. Utilizza ndk-build, in ordine decrescente di preferenza:

1. La versione della piattaforma corrispondente a APP_PLATFORM.
2. Il prossimo livello API disponibile inferiore a APP_PLATFORM. Ad esempio, il criterio android-19 verrà utilizzato quando APP_PLATFORM è in formato android-20, poiché non erano disponibili nuove 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_COMMANDS

L'equivalente a livello di progetto di LOCAL_SHORT_COMMANDS. Per ulteriori informazioni, consulta 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 il protocollo STL di system. Altre opzioni disponibili sono c++_shared, c++_static e none. Consulta Runtime e funzionalità di NDK C++.

APP_STRIP_MODE

L'argomento da passare a strip per i moduli dell'applicazione. Il valore predefinito è --strip-unneeded. Per evitare di rimuovere tutti i programmi binari nel modulo, imposta questo valore su none. Per altre modalità di rimozione, consulta la documentazione relativa alle righe.

ARCHIVIAZIONE_APP_THIN

Impostato su "true" per utilizzare archivi sottili per tutte le librerie statiche nel progetto. Per scoprire di più, 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

Nota: APP_WRAP_SH_<abi> non può essere combinato con APP_WRAP_SH. Se un ABI usa un wrap.sh specifico per ABI, tutti gli ABI devono.