Android.Mk

Auf dieser Seite wird die Syntax der Build-Datei Android.mk beschrieben, die von ndk-build.

Übersicht

Die Datei Android.mk befindet sich in einem Unterverzeichnis der Datei jni/ Ihres Projekts. und beschreibt Ihre Quellen und gemeinsam genutzten Bibliotheken im Build-System. Es ist ein winziges GNU-Makefile-Fragment, das vom Build-System einmal oder mehrmals geparst wird. Die Datei Android.mk ist nützlich, um projektweite Einstellungen zu definieren, Application.mk, das Build-System und Ihre Umgebungsvariablen nicht definiert. Außerdem lassen sich damit projektweite Einstellungen für bestimmte Module überschreiben.

Mit der Syntax von Android.mk kannst du Quellen in Modulen gruppieren. Ein Modul ist entweder eine statische Bibliothek, eine gemeinsam genutzte Bibliothek oder eine eigenständige ausführbare Datei. Sie können in jeder Android.mk-Datei ein oder mehrere Module definieren. können Sie dieselbe Quelldatei in mehreren Modulen verwenden. Nur das Build-System fügt freigegebene Bibliotheken in Ihr Anwendungspaket ein. Außerdem können statische Bibliotheken gemeinsam genutzte Bibliotheken generieren.

Neben der Paketerstellung für Bibliotheken verarbeitet das Build-System auch für Sie. Sie müssen beispielsweise keine Header-Dateien oder expliziten zwischen den generierten Dateien in der Datei Android.mk. Das NDK-Buildsystem berechnet diese Beziehungen automatisch für Sie. Daher sollten Sie in zukünftigen NDK-Releases von der neuen Toolchain-/Plattformunterstützung profitieren können, ohne Ihre Android.mk-Datei ändern zu müssen.

Die Syntax dieser Datei ähnelt der Syntax der Android.mk-Dateien, die im vollständigen Android Open Source Project enthalten sind. Während das Build-System Implementierung, bei der sie anders sind, ist ihre Ähnlichkeit eine beabsichtigte Designentscheidung, die Anwendungsentwicklern die Wiederverwendung für externe Bibliotheken.

Grundlegende Informationen

Bevor Sie sich genauer mit der Syntax befassen, sollten Sie sich zunächst Grundlagen des Inhalts einer Android.mk-Datei In diesem Abschnitt wird die Methode Android.mk im Hello-JNI-Beispiel. Hier wird die Rolle erklärt. jede Zeile in der Datei abgespielt wird.

Eine Android.mk-Datei muss mit der Definition der Variablen LOCAL_PATH beginnen:

LOCAL_PATH := $(call my-dir)

Diese Variable gibt den Speicherort der Quelldateien in der Entwicklung an Baum. Hier gibt die Makrofunktion my-dir, die vom Build-System bereitgestellt wird, den Pfad des aktuellen Verzeichnisses zurück (das Verzeichnis, das die Android.mk-Datei selbst enthält).

In der nächsten Zeile wird die Variable CLEAR_VARS deklariert, deren Wert das Build-System .

include $(CLEAR_VARS)

Die Variable CLEAR_VARS verweist auf ein spezielles GNU-Makefile, mit dem viele LOCAL_XXX-Variablen für Sie, wie LOCAL_MODULE, LOCAL_SRC_FILES und LOCAL_STATIC_LIBRARIES Hinweis: LOCAL_PATH wird nicht gelöscht. Dieses Variable muss ihren Wert beibehalten, da das System alle Build-Steuerdateien parst. in einem einzigen GNU Make-Ausführungskontext, in dem alle Variablen global sind. Du musst (re-)deklarieren Sie diese Variable, bevor Sie die einzelnen Module beschreiben.

Als Nächstes speichert die Variable LOCAL_MODULE den Namen des Moduls, das Sie erstellen. Verwenden Sie diese Variable einmal pro Modul in Ihrer Anwendung.

LOCAL_MODULE := hello-jni

Jeder Modulname muss eindeutig sein und darf keine Leerzeichen enthalten. Das Build-System fügt dem Namen, den Sie LOCAL_MODULE zuweisen, beim Generieren der endgültigen Datei der freigegebenen Bibliothek automatisch das richtige Präfix und Suffix hinzu. Beispiel: Im Beispiel oben wird eine Bibliothek mit dem Namen libhello-jni.so

In der nächsten Zeile sind die Quelldateien aufgeführt, wobei durch Leerzeichen mehrere Dateien:

LOCAL_SRC_FILES := hello-jni.c

Die Variable LOCAL_SRC_FILES muss eine Liste von C- und/oder C++-Quelldateien enthalten. ein Modul zu erstellen.

Die letzte Zeile hilft dem System, alles zusammenzuführen:

include $(BUILD_SHARED_LIBRARY)

Die Variable BUILD_SHARED_LIBRARY verweist auf ein GNU-Makefile-Script, in dem alle Informationen erfasst werden, die Sie seit der letzten include in LOCAL_XXX-Variablen definiert haben. Dieses Skript bestimmt, was erstellt wird und wie es ausgeführt wird.

In den Beispielverzeichnissen befinden sich komplexere Beispiele, Android.mk-Dateien, die du dir ansehen kannst. Außerdem enthält Beispiel: native Aktivität enthält eine ausführliche Erklärung der Android.mk-Datei dieses Beispiels. Unter Variablen und Makros finden Sie weitere Informationen zu den Variablen in diesem Abschnitt.

Variablen und Makros

Das Build-System bietet viele mögliche Variablen zur Verwendung in der Datei Android.mk. Viele dieser Variablen haben vordefinierte Werte. Andere weisen Sie zu.

Zusätzlich zu diesen Variablen können Sie auch eigene willkürliche Variablen definieren. Beachten Sie dabei, dass die folgenden Variablennamen vom NDK-Buildsystem reserviert sind:

• Namen, die mit LOCAL_ beginnen, z. B. LOCAL_MODULE.
• Namen, die mit PRIVATE_, NDK_ oder APP beginnen. Das Build-System verwendet diese intern.
• Kleinbuchstaben, z. B. my-dir Sie werden auch intern vom Build-System verwendet.

Wenn Sie eigene praktische Variablen in einer Android.mk-Datei definieren müssen, empfehlen wir, den Namen mit MY_ zu beginnen.

NDK-definierte einzuschließende Variablen

In diesem Abschnitt werden die vom Build-System definierten GNU Make-Variablen erläutert. bevor Sie die Android.mk-Datei parsen. Unter bestimmten Umständen kann das NDK Ihre Android.mk-Datei wird möglicherweise mehrmals mit einer anderen Definition geparst für einige dieser Variablen.

CLEAR_VARS

Diese Variable verweist auf ein Build-Skript, das fast alle LOCAL_XXX undefiniert. Variablen, die unter „Vom Entwickler definierte Variablen“ aufgeführt sind weiter unten. Verwenden um dieses Skript einzubinden, bevor ein neues Modul beschrieben wird. Die Syntax für wenn Sie sie verwenden:

include $(CLEAR_VARS)

ERSTELLUNG_AUSFÜHRBAR

Diese Variable verweist auf ein Build-Skript, das alle Informationen das Modul, das Sie in Ihren LOCAL_XXX-Variablen bereitgestellt haben, und bestimmt, wie eine ausführbare Zieldatei aus den aufgeführten Quellen erstellen Für die Verwendung dieses Scripts müssen Sie mindestens LOCAL_MODULE und LOCAL_SRC_FILES bereits Werte zugewiesen haben. Weitere Informationen zu diesen Variablen finden Sie unter Variablen für Modulbeschreibungen.

Die Syntax für die Verwendung dieser Variablen lautet:

include $(BUILD_EXECUTABLE)

GEMEINSAM GENUTZTE_BIBLIOTHEK

Diese Variable verweist auf ein Build-Skript, das alle Informationen das Modul, das Sie in Ihren LOCAL_XXX-Variablen bereitgestellt haben, und bestimmt, wie eine gemeinsam genutzte Zielbibliothek aus den aufgeführten Quellen erstellen Beachten Sie, dass die Verwendung dieser müssen Sie bereits Werte für LOCAL_MODULE und LOCAL_SRC_FILES (weitere Informationen zu diesen Variablen finden Sie unter Variablen für Modulbeschreibung).

Die Syntax für die Verwendung dieser Variablen lautet:

include $(BUILD_SHARED_LIBRARY)

Eine Variable für die gemeinsam genutzte Bibliothek führt dazu, dass das Build-System eine Bibliotheksdatei generiert. mit der Erweiterung .so.

BUILD_STATIC_LIBRARY

Eine Variante von BUILD_SHARED_LIBRARY, die zum Erstellen einer statischen Bibliothek verwendet wird. Die erstellt das Build-System statische Bibliotheken nicht in Ihr Projekt/Ihre Pakete, können damit gemeinsam genutzte Bibliotheken erstellen (siehe LOCAL_STATIC_LIBRARIES und LOCAL_WHOLE_STATIC_LIBRARIES. Die Syntax für die Verwendung dieser Variablen lautet:

include $(BUILD_STATIC_LIBRARY)

Eine statische-library-Variable bewirkt, dass das Build-System eine Bibliothek mit einem Erweiterung .a.

VORTEILE_GETEILTE_BIBLIOTHEK

Verweist auf ein Build-Skript, mit dem eine vordefinierte gemeinsam genutzte Bibliothek angegeben wird. „Mag ich“-Bewertung in den Fall von BUILD_SHARED_LIBRARY und BUILD_STATIC_LIBRARY, hier der Wert von LOCAL_SRC_FILES kann keine Quelldatei sein. Stattdessen muss es sich um einen einzelnen Pfad zu einer vorkonfigurierten freigegebenen Bibliothek wie foo/libfoo.so handeln. Die Syntax für die Verwendung dieser Variablen lautet:

include $(PREBUILT_SHARED_LIBRARY)

Sie können auch in einem anderen Modul auf eine vordefinierte Bibliothek verweisen, indem Sie die Methode LOCAL_PREBUILTS. Weitere Informationen zur Verwendung vordefinierter Modelle finden Sie unter Vordefinierte Bibliotheken verwenden.

VORABVERTEILTE_STATISCHE_BIBLIOTHEK

Entspricht PREBUILT_SHARED_LIBRARY, aber für eine vordefinierte statische Bibliothek. Für Weitere Informationen zur Verwendung von vordefinierten Bibliotheken finden Sie unter Vordefinierte Bibliotheken verwenden.

Variablen für Zielinformationen

Das Build-System parst Android.mk einmal pro ABI, das durch APP_ABI angegeben wird Variable definiert, die normalerweise in der Datei Application.mk definiert ist. Wenn APP_ABI all ist, parst das Build-System Android.mk einmal pro ABI und dem NDK. unterstützt. In diesem Abschnitt werden Variablen beschrieben, die das Build-System jedes Mal definiert, wenn es parst Android.mk.

TARGET_ARCH

Die CPU-Familie, auf die das Buildsystem beim Parsen dieser Android.mk-Datei ausgerichtet ist. Diese Variable ist entweder arm, arm64, x86 oder x86_64.

ZIELPLATTFORM

Die Android-API-Ebene, auf die das Build-System beim Parsen dieser Android.mk-Datei ausgerichtet ist. Die Systembilder von Android 5.1 entsprechen beispielsweise dem Android API-Level 22: android-22. Eine vollständige Liste der Plattformnamen und der entsprechenden Android-Systemimages finden Sie unter Native APIs. Das folgende Beispiel zeigt die Syntax für die Verwendung dieser Variablen:

ifeq ($(TARGET_PLATFORM),android-22)
    # ... do something ...
endif

ABI_ZIEL_ARCH

Das ABI, auf das das Buildsystem beim Parsen dieser Android.mk-Datei abzielt. Tabelle 1 zeigt die ABI-Einstellung, die für jede unterstützte CPU und Architektur verwendet wird.

Tabelle 1 ABI-Einstellungen für verschiedene CPUs und Architekturen.

Das folgende Beispiel zeigt, wie Sie prüfen, ob ARMv8 AArch64 als Ziel-CPU- und -ABI-Kombination verwendet wird:

ifeq ($(TARGET_ARCH_ABI),arm64-v8a)
  # ... do something ...
endif

Weitere Informationen zu Architektur-ABIs und zugehörigen Kompatibilitätsproblemen finden Sie unter Android-ABIs.

Neue Ziel-ABIs werden in Zukunft andere Werte haben.

TARGET_ABI

Eine Verkettung von Android-Ziel-API-Level und ABI. Das ist besonders nützlich, wenn Sie einen Test mit einem bestimmten Zielsystem-Image für ein echtes Gerät durchführen möchten. So suchen Sie beispielsweise nach einem 64-Bit-ARM-Gerät mit Android API-Level 22:

ifeq ($(TARGET_ABI),android-22-arm64-v8a)
  # ... do something ...
endif

Variablen für Modulbeschreibung

Die Variablen in diesem Abschnitt beschreiben das Modul für das Buildsystem. Jede Modulbeschreibung sollte diesem grundlegenden Ablauf folgen:

1. Initialisieren oder definieren Sie die mit dem Modul verknüpften Variablen mithilfe der Variablen CLEAR_VARS.
2. Weisen Sie den Variablen, die zur Beschreibung des Moduls verwendet werden, Werte zu.
3. Legen Sie mithilfe der Variablen BUILD_XXX fest, dass das NDK-Build-System das entsprechende Build-Script für das Modul verwenden soll.

LOCAL_PATH

Diese Variable wird verwendet, um den Pfad der aktuellen Datei anzugeben. Sie müssen sie am Anfang der Android.mk-Datei definieren. Das folgende Beispiel zeigt, wie das geht:

LOCAL_PATH := $(call my-dir)

Das Skript, auf das CLEAR_VARS verweist, löscht diese Variable nicht. Sie müssen sie daher nur einmal definieren, auch wenn Ihre Android.mk-Datei mehrere Module beschreibt.

LOKALES_MODUL

Diese Variable speichert den Namen Ihres Moduls. Er muss unter allen Modulen eindeutig sein Namen und darf keine Leerzeichen enthalten. Sie müssen ihn definieren, bevor Skripts (außer dem für CLEAR_VARS) Sie müssen weder das Element lib oder die Dateiendung .so oder .a. macht das Build-System diese automatisch Änderungen vornehmen. Verwenden Sie in Ihren Android.mk- und Application.mk-Dateien den unveränderten Namen Ihres Moduls. Mit der folgenden Zeile wird beispielsweise ein Modul für eine freigegebene Bibliothek namens libfoo.so generiert:

LOCAL_MODULE := "foo"

Wenn das generierte Modul einen anderen Namen als lib + den Wert von LOCAL_MODULE haben, können Sie die Variable LOCAL_MODULE_FILENAME verwenden, stattdessen einen Namen Ihrer Wahl generiert.

LOCAL_MODULE_FILENAME

Mit dieser optionalen Variablen können Sie die Namen überschreiben, die das Build-System standardmäßig für generierte Dateien verwendet. Wenn beispielsweise der Name Ihres LOCAL_MODULE gleich foo ist, können Sie erzwingen, dass das System die generierte Datei aufruft. libnewfoo Das folgende Beispiel zeigt, wie das geht:

LOCAL_MODULE := foo
LOCAL_MODULE_FILENAME := libnewfoo

Für ein Modul der gemeinsam genutzten Bibliothek würde in diesem Beispiel eine Datei namens libnewfoo.so

LOCAL_SRC_FILES

Diese Variable enthält die Liste der Quelldateien, die vom Build-System zum Generieren des Moduls verwendet werden. Nur die Dateien auflisten, die vom Build-System tatsächlich übergeben werden an den Compiler übergeben, da das Build-System automatisch alle verknüpften Abhängigkeiten. Sie können sowohl relative (zu LOCAL_PATH) als auch absolute Dateipfade verwenden.

Wir empfehlen, absolute Dateipfade zu vermeiden. Mit relativen Pfaden ist Ihre Android.mk-Datei portabel.

LOKALE_CPP_ERWEITERUNG

Sie können diese optionale Variable verwenden, um eine andere Dateiendung als .cpp für Ihre C++-Quelldateien. Mit der folgenden Zeile wird beispielsweise Erweiterung auf .cxx. (Die Einstellung muss einen Punkt enthalten.)

LOCAL_CPP_EXTENSION := .cxx

Mit dieser Variablen können Sie mehrere Erweiterungen angeben. Beispiel:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

LOCAL_CPP_FEATURES

Mit dieser optionalen Variablen können Sie angeben, dass Ihr Code auf bestimmten C++-Funktionen basiert. Während des Builds werden die richtigen Compiler- und Verknüpfungs-Flags aktiviert. . Bei vorgefertigten Binärdateien wird mit dieser Variablen auch angegeben, von welchen Funktionen die Binärdatei abhängt. So lässt sich die korrekte Verknüpfung der finalen Datei gewährleisten. Mi. empfehlen, diese Variable zu verwenden, anstatt -frtti und -fexceptions direkt in Ihrer LOCAL_CPPFLAGS-Definition.

Mit dieser Variablen kann das Build-System die entsprechenden Flags für zu den einzelnen Modulen. Bei Verwendung von LOCAL_CPPFLAGS verwendet der Compiler alle angegebenen für alle Module unabhängig vom tatsächlichen Bedarf.

Wenn Sie beispielsweise angeben möchten, dass in Ihrem Code RTTI (RunTime Type Information) verwendet wird, schreiben Sie Folgendes:

LOCAL_CPP_FEATURES := rtti

Um anzugeben, dass Ihr Code C++-Ausnahmen verwendet, schreiben Sie:

LOCAL_CPP_FEATURES := exceptions

Sie können auch mehrere Werte für diese Variable angeben. Beispiel:

LOCAL_CPP_FEATURES := rtti features

Die Reihenfolge, in der Sie die Werte beschreiben, spielt keine Rolle.

LOCAL_C_INCLUDES

Sie können diese optionale Variable verwenden, um eine Liste von Pfaden relativ zum NDK-Verzeichnis root, das zum Einschließen-Suchpfad bei der Kompilierung aller Quellen (C, C++ und Assembly). Beispiel:

LOCAL_C_INCLUDES := sources/foo

Oder:

LOCAL_C_INCLUDES := $(LOCAL_PATH)/<subdirectory>/foo

Definieren Sie diese Variable, bevor Sie entsprechende Einschluss-Flags über LOCAL_CFLAGS oder LOCAL_CPPFLAGS festlegen.

Das Build-System verwendet beim Start auch automatisch LOCAL_C_INCLUDES-Pfade. native Debugging-Tools mit ndk-gdb.

LOKALE_ASFLAGS

Flags, die beim Erstellen von .s- oder .S-Dateien an Clang übergeben werden.

LOKALE_ASMFLAGS

Flags, die beim Erstellen von .asm-Dateien an yasm übergeben werden.

LOCAL_CFLAGS

Flags, die beim Erstellen von C, C++ und einigen an Clang übergeben werden. Assembly-Quelldateien (.s und .S, aber nicht .asm). Die Möglichkeit, dies zu tun, kann nützlich sein, um zusätzliche Makrodefinitionen oder Kompilierungsoptionen anzugeben. Verwenden Sie Mit LOCAL_CPPFLAGS können Sie Flags nur für C++ angeben. LOCAL_CONLYFLAGS für Folgendes verwenden: Flags nur für C angeben.

Ändern Sie die Optimierungs-/Debugebene in der Datei Android.mk möglichst nicht. Das Build-System kann diese Einstellung automatisch für Sie übernehmen, indem es die relevanten Informationen in der Datei Application.mk verwendet. So kann das Build-System nützliche Datendateien generieren, die beim Debuggen verwendet werden.

Es ist möglich, zusätzliche Einschlusspfade anzugeben, indem Sie Folgendes schreiben:

LOCAL_CFLAGS += -I<path>,

Es ist jedoch besser, LOCAL_C_INCLUDES für diesen Zweck zu verwenden, da Dadurch ist es auch möglich, die für das native Debugging verfügbaren Pfade mit ndk-gdb.

LOCAL_CONLYFLAGS

Flags, die beim Kompilieren von C-Quellen an Clang übergeben werden. „Mag ich“-Bewertung entfernen LOCAL_CFLAGS, LOCAL_CONLYFLAGS wird bei der Kompilierung nicht an Clang übergeben C++ oder Assembly-Quellen.

LOCAL_CPPFLAGS

Eine optionale Reihe von Compiler-Flags, die nur beim Erstellen von C++-Quelldateien übergeben werden. Sie werden nach LOCAL_CFLAGS in der Compiler- Befehlszeile. Mit LOCAL_CFLAGS können Sie sowohl für C als auch für C++ Flags angeben.

LOKALE_STATISCHE_BIBLIOTHEKEN

Diese Variable speichert die Liste der statischen Bibliotheksmodule, in denen die aktuelle hängt davon ab.

Wenn das aktuelle Modul eine freigegebene Bibliothek oder eine ausführbare Datei ist, werden diese Bibliotheken mit dieser Variablen in das resultierende Binärprogramm eingebunden.

Wenn das aktuelle Modul eine statische Bibliothek ist, gibt diese Variable einfach an, Die anderen Module hängen auch vom aktuellen Modul ab. Bibliotheken.

LOCAL_SHARED_LIBRARIES

Diese Variable ist die Liste der Module der freigegebenen Bibliotheken, von denen dieses Modul zur Laufzeit abhängt. Diese Informationen sind zum Verknüpfen erforderlich und werden in die generierte Datei eingebettet.

LOCAL_WHOLE_STATIC_LIBRARIES

Diese Variable ist eine Variante von LOCAL_STATIC_LIBRARIES und drückt aus, dass die Linker sollte die zugehörigen Bibliotheksmodule wie ganze Archive behandeln. Weitere Informationen zu ganzen Archiven finden Sie in der GNU ld-Dokumentation zum Flag --whole-archive.

Diese Variable ist nützlich, wenn zwischen mehreren statische Bibliotheken. Wenn Sie diese Variable zum Erstellen einer freigegebenen Bibliothek verwenden, wird das Build-System gezwungen, der endgültigen Binärdatei alle Objektdateien aus Ihren statischen Bibliotheken hinzuzufügen. Dies gilt jedoch nicht für die Generierung ausführbarer Dateien.

LOKALE_LDLIBS

Diese Variable enthält die Liste zusätzlicher Verknüpfungs-Flags zum Erstellen von eine gemeinsam genutzte Bibliothek oder eine ausführbare Datei zu erstellen. Sie können das Präfix -l verwenden, um Namen bestimmter Systembibliotheken. Im folgenden Beispiel sehen Sie Verknüpfung zum Generieren eines Moduls, das beim Laden auf /system/lib/libz.so verweist Zeit:

LOCAL_LDLIBS := -lz

Eine Liste der freigegebenen Systembibliotheken, mit denen Sie in dieser NDK-Version verknüpfen können, finden Sie unter Native APIs.

LOKALE_LDFLAGS

Die Liste anderer Verknüpfungs-Flags, die das Build-System beim Erstellen Ihres eine gemeinsam genutzte Bibliothek oder eine ausführbare Datei zur Verfügung. So verwenden Sie beispielsweise den ld.bfd-Linker unter ARM/X86:

LOCAL_LDFLAGS += -fuse-ld=bfd

LOCAL_ALLOW_UNDEFINED_SYMBOLS

Wenn das Build-System auf einen nicht definierten Verweis stößt, wird standardmäßig wird der Fehler undefined symbol ausgegeben. Dieses kann Ihnen dabei helfen, Programmfehler im Quellcode zu finden.

Um diese Prüfung zu deaktivieren, legen Sie diese Variable auf true fest. Hinweis: Diese Einstellung kann dazu führen, dass die freigegebene Bibliothek zur Laufzeit geladen wird.

LOCAL_ARM_MODE

Standardmäßig generiert das Build-System ARM-Zielbinärdateien im thumb-Modus. wobei jeder Befehl 16 Bit breit ist und mit den STL-Bibliotheken im thumb/. Wenn Sie diese Variable als arm definieren, wird das Build-System gezwungen, die Objektdateien des Moduls im 32-Bit-arm-Modus zu generieren. Im folgenden Beispiel zeigt, wie das geht:

LOCAL_ARM_MODE := arm

Sie können das Build-System auch anweisen, nur bestimmte Quellen im arm-Modus zu erstellen, indem Sie den Quelldateinamen das Suffix .arm anhängen. Beispiel: Der Parameter Im folgenden Beispiel wird das Build-System angewiesen, bar.c immer im ARM-Modus zu kompilieren. sondern um foo.c entsprechend dem Wert von LOCAL_ARM_MODE zu erstellen.

LOCAL_SRC_FILES := foo.c bar.c.arm

LOKALER_ARM-NEON

Diese Variable ist nur wichtig, wenn das Targeting auf das ABI „armeabi-v7a“ erfolgt. Sie ermöglicht die Verwendung von ARM Advanced SIMD (NEON)-Compiler-Intrinsiks in Ihren C- und C++-Quellen sowie NEON-Anweisungen in Assembly-Dateien.

Beachten Sie, dass nicht alle ARMv7-basierten CPUs die NEON-Anweisungssatzerweiterungen unterstützen. Aus diesem Grund müssen Sie die Laufzeiterkennung ausführen, um diesen Code während der Laufzeit sicher verwenden zu können. Weitere Informationen finden Sie unter Neon-Support und CPU-Features:

Alternativ können Sie das Suffix .neon verwenden, um anzugeben, dass das Build-System nur bestimmte Quelldateien mit NEON-Unterstützung kompilieren soll. Im folgenden Beispiel kompiliert das Buildsystem foo.c mit Thumb- und Neon-Unterstützung, bar.c mit Thumb-Unterstützung und zoo.c mit Unterstützung für ARM und NEON:

LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon

Wenn Sie beide Suffixe verwenden, muss .arm vor .neon stehen.

LOCAL_DISABLE_FORMAT_STRING_CHECKS

Standardmäßig kompiliert das Buildsystem Code mit Formatstringschutz. Tun Erzwingt einen Compilerfehler, wenn ein nicht konstanter Formatstring in einem printf-Stil verwenden. Dieser Schutz ist standardmäßig aktiviert. Sie können ihn jedoch deaktivieren, indem Sie den Wert dieser Variablen auf true setzen. Wir raten davon ab, dies ohne triftigen Grund zu tun.

LOCAL_EXPORT_CFLAGS

Diese Variable enthält eine Reihe von C/C++-Compiler-Flags, die der LOCAL_CFLAGS-Definition jedes anderen Moduls hinzugefügt werden, das dieses über die Variablen LOCAL_STATIC_LIBRARIES oder LOCAL_SHARED_LIBRARIES verwendet.

Betrachten Sie beispielsweise das folgende Modulpaar: foo und bar. ist abhängig von foo:

include $(CLEAR_VARS)
LOCAL_MODULE := foo
LOCAL_SRC_FILES := foo/foo.c
LOCAL_EXPORT_CFLAGS := -DFOO=1
include $(BUILD_STATIC_LIBRARY)


include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.c
LOCAL_CFLAGS := -DBAR=2
LOCAL_STATIC_LIBRARIES := foo
include $(BUILD_SHARED_LIBRARY)

Hier übergibt das Build-System die Flags -DFOO=1 und -DBAR=2 beim Erstellen von bar.c an den Compiler. Außerdem werden exportierte Flags an den Anfang der LOCAL_CFLAGS Ihres Moduls angehängt, damit Sie sie ganz einfach überschreiben können.

Darüber hinaus ist die Beziehung zwischen den Modulen transitiv: Wenn zoo von folgendem Wert abhängt, bar, die wiederum von foo abhängig ist, übernimmt zoo auch alle Flags aus foo exportiert.

Außerdem verwendet das Build-System keine exportierten Flags, wenn es lokal erstellt wird, d. h., wenn das Modul erstellt wird, dessen Flags es exportiert. Daher ist in dem Beispiel oben angegeben wird, wird -DFOO=1 beim Erstellen von foo/foo.c nicht an den Compiler übergeben. Verwenden Sie stattdessen LOCAL_CFLAGS, um lokal zu erstellen.

LOCAL_EXPORT_CPPFLAGS

Diese Variable ist mit LOCAL_EXPORT_CFLAGS identisch, gilt jedoch nur für C++-Flags.

LOCAL_EXPORT_C_INCLUDES

Diese Variable ist mit LOCAL_EXPORT_CFLAGS identisch, beinhaltet aber für C Pfade. Es ist nützlich, wenn bar.c beispielsweise Header aus Modul foo.

LOCAL_EXPORT_LDFLAGS

Diese Variable ist mit LOCAL_EXPORT_CFLAGS identisch, gilt jedoch für Verknüpfungs-Flags.

LOCAL_EXPORT_LDLIBS

Diese Variable ist mit LOCAL_EXPORT_CFLAGS identisch und weist das Build-System an, Namen bestimmter Systembibliotheken an den Compiler übergeben. Fügen Sie dem Namen jeder angegebenen Bibliothek -l voran.

Das Build-System hängt dem Wert der Variablen LOCAL_LDLIBS Ihres Moduls importierte Linker-Flags an. Das liegt an der Funktionsweise von Unix-Linkern.

Diese Variable ist in der Regel nützlich, wenn das Modul foo eine statische Bibliothek ist und der von einer Systembibliothek abhängt. Anschließend können Sie LOCAL_EXPORT_LDLIBS verwenden, um um die Abhängigkeit zu exportieren. Beispiel:

include $(CLEAR_VARS)
LOCAL_MODULE := foo
LOCAL_SRC_FILES := foo/foo.c
LOCAL_EXPORT_LDLIBS := -llog
include $(BUILD_STATIC_LIBRARY)

include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.c
LOCAL_STATIC_LIBRARIES := foo
include $(BUILD_SHARED_LIBRARY)

In diesem Beispiel setzt das Build-System -llog an das Ende des Verknüpfungsbefehls. wenn libbar.so erstellt wird. Dadurch wird der Verknüpfung mitgeteilt, dass libbar.so hängt von foo ab, aber auch von der System-Logging-Bibliothek.

LOCAL_SHORT_BEFEHLE

Legen Sie diese Variable auf true fest, wenn Ihr Modul eine sehr große Anzahl von Quellen und/oder abhängigen statischen oder freigegebenen Bibliotheken hat. Dadurch wird das Build-System gezwungen, Verwenden Sie die Syntax @ für Archive, die Zwischenobjektdateien oder Verknüpfungen enthalten Bibliotheken.

Diese Funktion kann unter Windows nützlich sein, wo die Befehlszeile ein Maximum an von nur 8.191 Zeichen, was für komplexe Projekte zu klein sein kann. Außerdem wirkt sich auf die Kompilierung einzelner Quelldateien aus, sodass fast alle Compiler auch in Listendateien.

Bei einem anderen Wert als true wird das Standardverhalten wiederhergestellt. Sie können APP_SHORT_COMMANDS auch in der Datei Application.mk definieren, um dieses Verhalten für alle Module in Ihrem Projekt zu erzwingen.

Wir empfehlen nicht, diese Funktion standardmäßig zu aktivieren, da sie den Build verlangsamt.

LOKALE_THIN_ARCHIV

Legen Sie diese Variable auf true fest, wenn Sie statische Bibliotheken erstellen. Dadurch wird ein Thin-Archiv generieren, eine Bibliotheksdatei, die keine Objektdateien enthält, sondern nur Dateipfade zu den Objekten, die normalerweise enthalten.

Das ist nützlich, um die Größe der Build-Ausgabe zu reduzieren. Der Nachteil ist, dass Solche Bibliotheken können nicht an einen anderen Speicherort verschoben werden (alle darin enthaltenen Pfade). relativ sind).

Gültige Werte sind true, false oder leer. In Ihrem Application.mk-Datei über die Variable APP_THIN_ARCHIVE.

LOKALER_FILTER_ASM

Definieren Sie diese Variable als Shell-Befehl, den das Build-System zum Filtern verwendet die Assembly-Dateien, die aus den Dateien extrahiert oder generiert wurden, die Sie für LOCAL_SRC_FILES Wenn Sie diese Variable definieren, geschieht Folgendes:

1. Das Build-System generiert eine temporäre Assembly-Datei aus einer beliebigen C- oder C++-Quelle. anstatt sie in einer Objektdatei zu kompilieren.
2. Das Build-System führt den Shell-Befehl in LOCAL_FILTER_ASM auf allen temporären Assemblerdateien und auf allen in LOCAL_SRC_FILES aufgeführten Assemblerdateien aus und generiert so eine weitere temporäre Assemblerdatei.
3. Das Build-System kompiliert diese gefilterten Assembly-Dateien in eine Objektdatei.

Beispiel:

LOCAL_SRC_FILES  := foo.c bar.S
LOCAL_FILTER_ASM :=

foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.o
bar.S                                 --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o

„1“ entspricht dem Compiler, „2“ dem Filter und „3“ dem Assembler. Der Filter muss ein eigenständiger Shell-Befehl sein, der den Namen der Eingabe verwendet -Datei als erstes Argument und den Namen der Ausgabedatei als zweites Argument. Beispiel:

myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S

Von NDK bereitgestellte Funktionsmakros

In diesem Abschnitt werden GNU-Make-Funktionsmakros beschrieben, die vom NDK bereitgestellt werden. Verwenden Sie $(call <function>), um sie zu bewerten. Sie geben Textinformationen zurück.

my-dir

Dieses Makro gibt den Pfad des letzten eingeschlossenen Makefile zurück. Dieser ist normalerweise Das aktuelle Verzeichnis von Android.mk. my-dir eignet sich zum Definieren LOCAL_PATH am Anfang Ihrer Android.mk-Datei. Beispiel:

LOCAL_PATH := $(call my-dir)

Aufgrund der Funktionsweise von GNU Make gibt dieses Makro tatsächlich den Pfad des letzten Makefiles zurück, das das Build-System beim Parsen der Build-Scripts eingeschlossen hat. Aus diesem Grund sollten Sie my-dir nicht aufrufen, nachdem Sie eine andere Datei eingefügt haben.

Betrachten Sie dazu beispielsweise das folgende Beispiel:

LOCAL_PATH := $(call my-dir)

# ... declare one module

include $(LOCAL_PATH)/foo/`Android.mk`

LOCAL_PATH := $(call my-dir)

# ... declare another module

Das Problem hier ist, dass LOCAL_PATH beim zweiten Aufruf von my-dir als $PATH/foo anstelle von $PATH definiert wird, da dort die letzte Include-Anweisung verweist.

Sie können dieses Problem vermeiden, indem Sie nach allem anderen "Includes" (Einschließen) einfügen. in der Datei Android.mk. Beispiel:

LOCAL_PATH := $(call my-dir)

# ... declare one module

LOCAL_PATH := $(call my-dir)

# ... declare another module

# extra includes at the end of the Android.mk file
include $(LOCAL_PATH)/foo/Android.mk

Wenn die Datei nicht so strukturiert werden kann, speichern Sie den Wert des ersten my-dir-Aufrufs in einer anderen Variablen. Beispiel:

MY_LOCAL_PATH := $(call my-dir)

LOCAL_PATH := $(MY_LOCAL_PATH)

# ... declare one module

include $(LOCAL_PATH)/foo/`Android.mk`

LOCAL_PATH := $(MY_LOCAL_PATH)

# ... declare another module

alle-unterverzeichnis-makefiles

Gibt die Liste der Android.mk-Dateien zurück, die sich in allen Unterverzeichnissen der Aktueller my-dir-Pfad.

Mit dieser Funktion können Sie dem Build-System tief verschachtelte Verzeichnishierarchien für Quellverzeichnisse zur Verfügung stellen. Standardmäßig sucht das NDK nur im Verzeichnis nach Dateien, das die Datei Android.mk enthält.

dieses Makefile

Gibt den Pfad des aktuellen Makefile zurück, aus dem das Build-System den .

Parent-Makefile

Gibt den Pfad des übergeordneten Makefiles im Einschlussbaum zurück (den Pfad des Makefiles, das das aktuelle enthält).

Grand-Parent-Makefile

Gibt den Pfad des übergeordneten Makefile im Einschlussbaum zurück (den Pfad von das Makefile, das das aktuelle enthält).

import-module

Eine Funktion, mit der Sie die Datei Android.mk eines Moduls suchen und einschließen können, indem Sie den Namen des Moduls. Hier ein typisches Beispiel:

$(call import-module,<name>)

In diesem Beispiel sucht das Build-System in der Liste der Verzeichnisse, auf die die Umgebungsvariable NDK_MODULE_PATH verweist, nach dem Modul mit dem Tag <name> und fügt die zugehörige Android.mk-Datei automatisch ein.