Anwendung.Mk

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:

  1. Die Plattformversion, die mit APP_PLATFORM übereinstimmt.
  2. Das nächste verfügbare API-Level unter APP_PLATFORM. Beispielsweise wird android-19 verwendet, wenn APP_PLATFORM den Wert android-20 hat, da es unter Android-20 keine neuen nativen APIs gab.
  3. 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