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 das Build-System einmal parst mehr. 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 Bibliothek. ausführbar sein. 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 werden statische können gemeinsam genutzte Bibliotheken generieren.

Neben der Paketerstellung für Bibliotheken verarbeitet das Build-System auch für Sie. Sie müssen z. B. keine Header-Dateien oder expliziten zwischen den generierten Dateien in der Datei Android.mk. Der NDK-Build diese Beziehungen automatisch für Sie. Daher sollten Sie sollte im zukünftigen NDK von der neuen Toolchain-/Plattformunterstützung profitieren können. veröffentlicht, ohne deine Android.mk-Datei bearbeiten zu müssen.

Die Syntax dieser Datei ist der Syntax der Android.mk-Dateien sehr ähnlich. vertrieben werden, die über das vollständige Android Open Source-Projekt vertrieben werden. 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 Variable LOCAL_PATH beginnen:

LOCAL_PATH := $(call my-dir)

Diese Variable gibt den Speicherort der Quelldateien in der Entwicklung an Baum. Hier gibt die vom Build-System bereitgestellte Makrofunktion my-dir Pfad des aktuellen Verzeichnisses (Verzeichnis mit der Datei Android.mk) -Datei selbst).

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, beim Erstellen der endgültigen Datei aus der gemeinsam genutzten Bibliothek, werden automatisch die entsprechenden Präfix und Suffix zu dem Namen, den Sie LOCAL_MODULE zuweisen. Beispiel: Im Beispiel oben wird eine Bibliothek mit dem Namen libhello-jni.so

Hinweis: Wenn der Name Ihres Moduls bereits mit lib beginnt, beginnt das Build-System nicht ein zusätzliches Präfix lib voranstellen. wird der Modulname unverändert übernommen und .so-Erweiterung. Eine Quelldatei mit dem Namen libfoo.c wird trotzdem eine Datei mit gemeinsam genutzten Objekten namens libfoo.so erstellt. Durch dieses Verhalten Bibliotheken unterstützen, die von den Android-Plattformquellen aus Android.mk generiert werden Dateien; beginnen die Namen all dieser Bibliotheken mit lib.

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 miteinander zu verknüpfen:

include $(BUILD_SHARED_LIBRARY)

Die Variable BUILD_SHARED_LIBRARY verweist auf ein Skript in GNU Makefile, das alle Informationen erfasst, die Sie in LOCAL_XXX-Variablen definiert haben, include zuletzt verwendet. 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. Schließlich: Unter Variablen und Makros finden Sie weitere Informationen zu den Variablen in diesem .

Variablen und Makros

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

Zusätzlich zu diesen Variablen können Sie auch eigene willkürliche Variablen definieren. Behalten Sie in diesem Fall dass das NDK-Build-System die folgenden Variablennamen reserviert:

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

Wenn Sie Ihre eigenen Convenience-Variablen in einer Android.mk-Datei definieren müssen, empfehlen, den Namen MY_ voranzustellen.

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.

VARIANZEN_LÖSCHEN

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 wie 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 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_EXECUTABLE)

Hinweis: Die meisten Android-Apps enthalten keine ausführbaren Dateien, sie sind aber nützlich für und Unittests und andere Debugging-Tools erstellen.

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.

STATISCHE_BIBLIOTHEK_ERSTELLEN

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_GEMEINSAM GENUTZTE_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 ein einzelner Pfad zum vordefinierte gemeinsam genutzte Bibliothek, z. B. foo/libfoo.so Die Syntax für die Verwendung dieses Variable 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 von vordefinierten 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.

ZIELARCH

Die CPU-Familie, auf die das Build-System ausgerichtet ist, während es diese Android.mk parst -Datei. Diese Variable ist entweder arm, arm64, x86 oder x86_64.

ZIELPLATTFORM

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

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

ABI_ZIEL_ARCH

Die ABI, auf die das Build-System ausgerichtet ist, während es diese Android.mk-Datei parst. 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.

CPU und Architektur	Einstellung
ARMv7	armeabi-v7a
ARMv8 AArch64	arm64-v8a
i686	x86
x86–64	x86_64

Das folgende Beispiel zeigt, wie nach ARMv8 AArch64 als Ziel gesucht wird Kombination aus CPU und ABI:

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

Weitere Informationen zu Architektur-ABIs und zugehörigen Kompatibilitätsproblemen siehe Android-ABIs.

Neue Ziel-ABIs werden in Zukunft andere Werte haben.

ABI-ZIEL

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 Ihr Modul für das Build-System. Jedes sollte die Modulbeschreibung diesem grundlegenden Ablauf folgen:

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

LOKALER_PFAD

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

LOCAL_PATH := $(call my-dir)

Das Skript, auf das CLEAR_VARS verweist, löscht diese Variable nicht. Dementsprechend wird brauchen Sie sie nur einmal zu definieren, auch wenn Ihre Android.mk-Datei beschreibt mehrere Module.

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 ändern. Während des gesamten Android.mk und Application.mk -Dateien verweisen auf das Modul mit seinem unveränderten Namen. Beispiel: führt zur Generierung eines Moduls der gemeinsam genutzten Bibliothek namens libfoo.so:

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 vom Build-System standardmäßig für Dateien, die es erstellt. 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 Sie dies erreichen:

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

Hinweis: Der Dateipfad und die Dateiendung lassen sich nicht überschreiben.

LOKALE_SRC-DATEIEN

Diese Variable enthält die Liste der Quelldateien, die das Build-System verwendet, um um das Modul zu generieren. 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. Beachten Sie, dass Sie sowohl relative (zu LOCAL_PATH) als auch absolute Dateipfaden.

Wir empfehlen, absolute Dateipfade zu vermeiden. relative Pfade machen Android.mk Datei leichter portierbar sein.

Hinweis: Verwenden Sie in Build-Dateien immer Schrägstriche (/) im Unix-Stil. Der Build umgekehrte Schrägstriche (\) im Windows-Stil nicht richtig verarbeitet.

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

Sie können diese Variable verwenden, um mehrere Erweiterungen anzugeben. Beispiel:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

LOKALE_CPP-FUNKTIONEN

Sie können diese optionale Variable verwenden, um anzugeben, dass Ihr Code auf bestimmten C++ Funktionen. Während des Builds werden die richtigen Compiler- und Verknüpfungs-Flags aktiviert. . Bei vordefinierten Binärdateien deklariert diese Variable auch, welche Funktionen hängt davon ab, ob die endgültige Verknüpfung korrekt funktioniert. 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.

Um beispielsweise anzuzeigen, dass Ihr Code RTTI (RunTime Type Information) verwendet, Schreiben:

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 sogar:

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

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

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

LOKALE_UNTERLAGEN

Diese optionale Variable legt Compiler-Flags fest, die vom Build-System übergeben werden, wenn Erstellen von C-und C++-Quelldateien Die Möglichkeit, dies zu tun, ist nützlich für zusätzliche Makrodefinitionen oder Kompilierungsoptionen angeben. LOCAL_CPPFLAGS verwenden zur Angabe von Flags nur für C++.

Ändern Sie die Optimierungs-/Debug-Ebene in der Datei Android.mk nicht. Das Build-System übernimmt diese Einstellung automatisch für Sie, indem es die relevante Informationen in der Datei Application.mk. Auf diese Weise können die um nützliche Datendateien für die Fehlerbehebung zu generieren.

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.

LOKALE_CPPFLAGS

Ein optionaler Satz von Compiler-Flags, die beim Erstellen der C++-Quelle übergeben werden nur Dateien. Sie werden nach LOCAL_CFLAGS in der Compiler- Befehlszeile. Verwenden Sie LOCAL_CFLAGS, um Flags sowohl für C als auch für C++ anzugeben.

LOKALE_STATISCHE_BIBLIOTHEKEN

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

Wenn das aktuelle Modul eine gemeinsam genutzte Bibliothek oder eine ausführbare Datei ist, wird diese Variable die Verknüpfung dieser Bibliotheken mit der resultierenden Binärdatei erzwingen.

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

LOKALE_GEMEINSAM GENUTZTE_BIBLIOTHEKEN

Diese Variable ist die Liste der Module der gemeinsam genutzten Bibliotheken, auf denen dieses Modul basiert. hängt von der Laufzeit ab. Diese Informationen werden zum Zeitpunkt der Verknüpfung und zum Einbetten der die entsprechenden Informationen in der generierten Datei enthalten.

LOKALE_STATISCHE_BIBLIOTHEKEN

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. Für Weitere Informationen zu ganzen Archiven finden Sie in der GNU ld-Dokumentation für die --whole-archive-Flag.

Diese Variable ist nützlich, wenn zwischen mehreren statische Bibliotheken. Wenn Sie diese Variable zum Erstellen einer gemeinsam genutzten Bibliothek verwenden, das Build-System dazu zwingen, alle Objektdateien aus Ihren statischen Bibliotheken zum endgültigen Binärcode. 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 veröffentlichten Systembibliotheken, zu denen Sie in diesem NDK eine Verknüpfung herstellen können finden Sie unter Native APIs.

Hinweis: Wenn Sie diese Variable für eine statische Bibliothek definieren, ignoriert das Build-System und ndk-build gibt eine Warnung aus.

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. Wenn Sie beispielsweise die ld.bfd-Verknüpfung auf einem ARM/X86:

LOCAL_LDFLAGS += -fuse-ld=bfd

Hinweis: Wenn Sie diese Variable für eine statische Bibliothek definieren, ignoriert das Build-System und „ndk-build“ gibt eine Warnung aus.

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 dir dabei helfen, Programmfehler im Quellcode zu finden.

Um diese Prüfung zu deaktivieren, legen Sie diese Variable auf true fest. Beachten Sie, dass diese Einstellung dass die gemeinsam genutzte Bibliothek zur Laufzeit geladen wird.

Hinweis: Wenn Sie diese Variable für eine statische Bibliothek definieren, ignoriert das Build-System und „ndk-build“ gibt eine Warnung aus.

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, Generieren der Objektdateien des Moduls im 32-Bit-Modus arm. Im folgenden Beispiel zeigt, wie das geht:

LOCAL_ARM_MODE := arm

Sie können das Build-System auch anweisen, nur bestimmte Quellen in arm zu erstellen Modus, indem Sie das Suffix .arm an die Namen der Quelldateien 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

Hinweis: Sie können auch erzwingen, dass das Build-System ARM-Binärdateien generiert, indem Sie Folgendes festlegen: APP_OPTIM in deiner Datei Application.mk an debug. debug angeben Erzwingt einen ARM-Build, da der Toolchain-Debugger keinen Thumb-Code verarbeitet ordnungsgemäß funktioniert.

LOKALER_ARM-NEON

Diese Variable ist nur wichtig, wenn das Targeting auf das ABI „armeabi-v7a“ erfolgt. Es ermöglicht die Verwendung von NEON-Compiler-Intrinsiken (ARM Advanced SIMD) in Ihrem 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 eine Laufzeiterkennung durchführen, um die um diesen Code zur Laufzeit zu übertragen. Weitere Informationen finden Sie unter Neon-Support und CPU-Features:

Alternativ können Sie mit dem Suffix .neon angeben, dass das Build-System bestimmte Quelldateien mit NEON-Unterstützung kompilieren. Im folgenden Beispiel das Build-System kompiliert foo.c mit Daumen- und Neon-Unterstützung, bar.c mit Daumen hoch 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 Build-System 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 aber deaktivieren indem Sie den Wert dieser Variablen auf true setzen. Wir raten jedoch davon ab, ohne triftigen Grund.

LOCAL_EXPORT_CFLAGS

Diese Variable zeichnet eine Reihe von C/C++-Compiler-Flags auf, die dem LOCAL_CFLAGS hinzugefügt werden eines anderen Moduls, das dieses über die LOCAL_STATIC_LIBRARIES oder LOCAL_SHARED_LIBRARIES.

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 an den Compiler. beim Erstellen von bar.c. Außerdem werden dem Code Ihres Moduls Exportierte Flags vorangestellt. LOCAL_CFLAGS, damit Sie sie 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.

Schließlich verwendet das Build-System keine exportierten Flags, wenn es lokal erstellt wird. (d.h. Erstellen des Moduls, dessen Flags exportiert werden). Daher ist in dem Beispiel oben angegeben wird, wird -DFOO=1 beim Erstellen von foo/foo.c nicht an den Compiler übergeben. Bis lokal erstellen, verwenden Sie stattdessen LOCAL_CFLAGS.

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 die gleiche wie LOCAL_EXPORT_CFLAGS, aber für C schließen Sie Pfade ein. 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. -l dem Abschnitt Namen jeder von Ihnen angegebenen Bibliothek.

Das Build-System hängt importierte Verknüpfungs-Flags an den Wert Ihres der Variable LOCAL_LDLIBS des Moduls. Dies liegt an der Funktionsweise der Unix-Verknüpfung.

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

Setzen Sie diese Variable auf true, wenn Ihr Modul eine sehr hohe Anzahl von Quellen hat. und/oder abhängigen statischen oder gemeinsam genutzten Bibliotheken. 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.

Beachten Sie, dass alle Werte außer true auf das Standardverhalten zurückgesetzt werden. Ich können Sie auch APP_SHORT_COMMANDS in Ihrer Application.mk-Datei definieren, um in Ihrem Projekt für alle Module.

Wir raten davon ab, diese Funktion standardmäßig zu aktivieren, da dadurch der Build langsamer machen.

LOKALE_THIN_ARCHIV

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

Dies 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.

Hinweis: Dies wird bei nicht statischen Bibliotheksmodulen oder vordefinierten statischen Bibliothek ignoriert.

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 einem beliebigen temporäre Assembly-Datei und in jeder Assembly-Datei, die in LOCAL_SRC_FILES aufgeführt ist, und generiert so eine weitere temporäre Assembly-Datei.
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“ mit dem Filter und „3“ mit 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 die Makros der GNU Make-Funktion erläutert, die vom NDK bereitgestellt werden. Verwenden Sie $(call <function>), um sie zu bewerten; geben sie Textinformationen zurück.

my-dir

Dieses Makro gibt den Pfad des letzten eingeschlossenen Makefile zurück, das 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 letztes Makefile, das das Build-System beim Parsen der Build-Skripts verwendet hat. Für Aus diesem Grund sollten Sie my-dir nicht aufrufen, nachdem Sie eine weitere Datei eingefügt haben.

Hier ein 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 ist, dass der zweite Aufruf von my-dir LOCAL_PATH als $PATH/foo anstelle von $PATH, da dort die neueste Einbeziehung spitz.

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 es nicht möglich ist, die Datei auf diese Weise zu strukturieren, speichern Sie den Wert des ersten my-dir-Aufruf in eine andere Variable ein. 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 Hierarchien von tief verschachtelten Quellverzeichnissen für des Build-Systems. Standardmäßig sucht das NDK nur nach Dateien im Verzeichnis mit der Datei Android.mk.

dieses Makefile

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

Parent-Makefile

Gibt den Pfad des übergeordneten Makefile in der Einschlussstruktur zurück (den Pfad des Makefile, in dem das aktuelle Makefile enthalten ist).

Grand-Parent-Makefile

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

Importmodul

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 nach dem Modul <name> in die Liste der Verzeichnisse, auf die Ihre NDK_MODULE_PATH-Umgebung verweist Variable verweist und die Android.mk-Datei automatisch für Sie mitnimmt.