In diesem Dokument wird die von ndk-build
verwendete Build-Datei Application.mk
erläutert.
Wir empfehlen Ihnen, die Seite Konzepte vorher zu lesen.
Übersicht
Das Application.mk
gibt projektweite Einstellungen für ndk-build an. Sie befindet sich standardmäßig unter jni/Application.mk
im Projektverzeichnis Ihrer Anwendung.
Variablen
APP_ABI
Standardmäßig generiert das NDK-Build-System Code für alle nicht verworfenen ABIs. Mit der Einstellung APP_ABI
können Sie Code für bestimmte ABIs generieren. Tabelle 1 zeigt die APP_ABI
-Einstellungen für verschiedene Befehlssätze.
Tabelle 1 APP_ABI
-Einstellungen für verschiedene Anweisungssätze.
Anleitungssatz | Antwort |
---|---|
32-Bit-ARMv7 | APP_ABI := armeabi-v7a |
64-Bit-ARMv8 (AArch64) | APP_ABI := arm64-v8a |
x86 | APP_ABI := x86 |
x86–64 | APP_ABI := x86_64 |
Alle unterstützten ABIs (Standardeinstellung) | APP_ABI := all |
Sie können auch mehrere Werte angeben, indem Sie sie durch Leerzeichen voneinander getrennt in dieselbe Zeile einfügen. Beispiele:
APP_ABI := armeabi-v7a arm64-v8a x86
Eine Liste aller unterstützten ABIs und Details zu ihrer Nutzung und Einschränkungen finden Sie unter Android-ABIs.
APP_ASFLAGS
Flags, die für jede Assembly-Quelldatei (.s
- und .S
-Dateien) im Projekt an den Assembler übergeben werden.
APP_ASMFLAGS
Flags, die bei allen YASM-Quelldateien an YASM übergeben werden (nur .asm
, x86/x86_64).
SKRIPT FÜR DIE APP
Standardmäßig geht „ndk-build“ davon aus, dass sich die Datei Android.mk im Stammverzeichnis des Projekts unter jni/Android.mk
befindet.
Wenn Sie eine Android.mk-Datei von einem anderen Speicherort aus laden möchten, setzen Sie APP_BUILD_SCRIPT
auf den absoluten Pfad der Android.mk-Datei.
APP_CFLAGS
Flags, die für alle C/C++-Kompilierungen im Projekt übergeben werden sollen.
Weitere Informationen finden Sie unter APP_CONLYFLAGS und APP_CPPFLAGS.
APP_CLANG_TIDY
Setzen Sie diesen Wert auf „true“, um clang-tidy für alle Module im Projekt zu aktivieren. Standardmäßig deaktiviert.
APP_CLANG_TIDY_FLAGS
Flags, die für alle umgangssprachlichen Ausführungen im Projekt zu übergeben sind.
APP_CONLYFLAGS
Flags, die für alle C-Kompilierungen im Projekt übergeben werden sollen. Diese Flags werden nicht für C++-Code verwendet.
Weitere Informationen finden Sie unter APP_CFLAGS, APP_CPPFLAGS.
APP_CPPFLAGS
Flags, die für alle C++-Kompilierungen im Projekt übergeben werden sollen. Diese Flags werden nicht für C-Code verwendet.
Weitere Informationen finden Sie unter APP_CFLAGS, APP_CONLYFLAGS.
APP_CXXFLAGS
Identisch mit APP_CPPFLAGS
, wird aber im Kompilierungsbefehl nach APP_CPPFLAGS
angezeigt. Beispiele:
APP_CPPFLAGS := -DFOO
APP_CXXFLAGS := -DBAR
Die obige Konfiguration führt zu einem Kompilierungsbefehl, der clang++
-DFOO -DBAR
und nicht clang++ -DBAR -DFOO
ähnelt.
APP_FEHLERBEHEBUNG
Setzen Sie den Wert auf „true“, um eine debug-fähige Anwendung zu erstellen.
APP_LDFLAGS
Flags, die beim Verknüpfen von ausführbaren Dateien und gemeinsam genutzten Bibliotheken übergeben werden sollen.
APP_MANIFEST (APP_MANIFEST)
Absoluter Pfad zu einer AndroidManifest.xml-Datei.
Standardmäßig wird $(APP_PROJECT_PATH)/AndroidManifest.xml)
verwendet, sofern vorhanden.
APP-MODULE
Eine explizite Liste der zu erstellenden Module. Die Elemente dieser Liste sind die Namen der Module, wie sie in LOCAL_MODULE
in der Datei Android.mk vorkommen.
Standardmäßig erstellt „ndk-build“ alle gemeinsam genutzten Bibliotheken, ausführbaren Dateien und deren Abhängigkeiten. Statische Bibliotheken werden nur erstellt, wenn sie vom Projekt verwendet werden, das Projekt nur statische Bibliotheken enthält oder in APP_MODULES
benannt ist.
APP_OPTIM (APP_OPTIM)
Definieren Sie diese optionale Variable als release
oder debug
. Release-Binärdateien werden standardmäßig erstellt.
Der Release-Modus ermöglicht Optimierungen und generiert möglicherweise Binärprogramme, die nicht mit einem Debugger verwendet werden können. Im Debug-Modus werden Optimierungen deaktiviert, sodass Debugger verwendet werden können.
Beachten Sie, dass Sie sowohl Release- als auch Binärdateien debuggen können. Geben Sie Binärdateien jedoch frei, um bei der Fehlerbehebung weniger Informationen zu liefern. So können z. B. Variablen optimiert werden und so eine Prüfung verhindern. Außerdem kann eine Neuanordnung des Codes das schrittweise Durchgehen des Codes erschweren; Stacktraces sind möglicherweise nicht zuverlässig.
Wenn du android:debuggable
im <application>
-Tag deines Anwendungsmanifests deklariert, wird für diese Variable standardmäßig debug
anstelle von release
festgelegt.
Sie können diesen Standardwert überschreiben, indem Sie APP_OPTIM
auf release
setzen.
APP_PLATTFORM
APP_PLATFORM
gibt das Android API-Level an, für das diese App erstellt wird, und entspricht dem minSdkVersion
der App.
Wenn keine Angabe erfolgt, zielt „ndk-build“ auf das vom NDK unterstützte minimale API-Level ab. Das vom aktuellen NDK unterstützte Mindest-API-Level ist immer niedrig genug, um fast alle aktiven Geräte zu unterstützen.
Ein Wert von android-16
gibt beispielsweise an, dass deine Bibliothek APIs verwendet, die unter Android 4.1 (API-Level 16) nicht verfügbar sind und nicht auf Geräten mit einer niedrigeren Plattformversion verwendet werden können. Eine vollständige Liste der Plattformnamen und der entsprechenden Android-System-Images finden Sie unter Android NDK-native APIs.
Wenn Sie Gradle und externalNativeBuild
verwenden, sollte dieser Parameter nicht direkt festgelegt werden. Legen Sie stattdessen das Attribut minSdkVersion
im defaultConfig
- oder productFlavors
-Block der build.gradle
-Datei auf Modulebene fest. Dadurch wird sichergestellt, dass deine Mediathek nur von Apps verwendet wird, die auf Geräten mit einer geeigneten Android-Version installiert sind.
Hinweis: Der NDK enthält nicht für jedes API-Level von Android Bibliotheken. Versionen, die keine neuen nativen APIs enthalten, werden ausgelassen, um Speicherplatz im NDK zu sparen. ndk-build verwendet in absteigender Reihenfolge der Präferenz:
- Die Plattformversion, die mit
APP_PLATFORM
übereinstimmt. - Das nächste verfügbare API-Level unter
APP_PLATFORM
. Beispielsweise wirdandroid-19
verwendet, wennAPP_PLATFORM
den Wertandroid-20
hat, da es unter Android-20 keine neuen nativen APIs gab. - Das minimale API-Level, das vom NDK unterstützt wird.
APP_PROJEKT_PFAD
Der absolute Pfad des Stammverzeichnisses des Projekts.
APP_SHORT_COMMANDS
Das projektweite Äquivalent zu LOCAL_SHORT_COMMANDS
. Weitere Informationen findest du in der Dokumentation zu LOCAL_SHORT_COMMANDS
unter Android.mk.
APP_STL
C++-Standardbibliothek zur Verwendung für diese Anwendung.
Standardmäßig wird die STL system
verwendet. Weitere Optionen sind c++_shared
, c++_static
und none
. Siehe NDK-C++-Laufzeiten und -Features.
APP_STRIP_MODE
Das Argument, das für Module in dieser Anwendung an strip
übergeben werden soll. Die Standardeinstellung ist --strip-unneeded
. Legen Sie none
fest, um zu vermeiden, dass alle Binärprogramme im Modul entfernt werden. Informationen zu anderen Entfernungsmodi finden Sie in der Strip-Dokumentation.
APP_SCHNELL_ARCHIV
Legen Sie diesen Wert auf „true“ fest, um für alle statischen Bibliotheken im Projekt dünne Archive zu verwenden. Weitere Informationen findest du in der Dokumentation zu LOCAL_THIN_ARCHIVE
unter Android.mk.
APP_WRAP_SH
Pfad zur Datei wrap.sh, die in diese Anwendung aufgenommen werden soll.
Für jede ABI gibt es eine Variante dieser Variable sowie eine ABI-generische Variante:
APP_WRAP_SH
APP_WRAP_SH_armeabi-v7a
APP_WRAP_SH_arm64-v8a
APP_WRAP_SH_x86
APP_WRAP_SH_x86_64