Android.Mk

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

Übersicht

Die Datei Android.mk befindet sich in einem Unterverzeichnis des Verzeichnisses jni/ Ihres Projekts und beschreibt die Quellen und freigegebenen Bibliotheken für das Build-System. Es ist ein winziges GNU-Makefile-Fragment, das vom Build-System einmal oder mehrmals geparst wird. Die Datei Android.mk eignet sich zum Definieren projektweiter Einstellungen, die von Application.mk, dem Build-System und Ihren Umgebungsvariablen nicht definiert werden. Außerdem können Sie damit projektweite Einstellungen für bestimmte Module überschreiben.

Mit der Syntax von Android.mk können Sie Ihre 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 und dieselbe Quelldatei in mehreren Modulen verwenden. Das Build-System fügt Ihrem Anwendungspaket nur freigegebene Bibliotheken hinzu. Darüber hinaus können mit statischen Bibliotheken gemeinsam genutzte Bibliotheken generiert werden.

Neben der Paketerstellung für Bibliotheken übernimmt das Build-System eine Vielzahl anderer Details für Sie. So müssen Sie beispielsweise keine Headerdateien oder explizite Abhängigkeiten zwischen generierten Dateien in der Datei Android.mk auflisten. 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 ist der Syntax der Android.mk-Dateien sehr ähnlich, die mit dem vollständigen Android Open Source-Projekt vertrieben werden. Die Implementierung des Build-Systems, in dem sie verwendet werden, ist zwar unterschiedlich, ihre Ähnlichkeit ist jedoch eine beabsichtigte Designentscheidung, die es Anwendungsentwicklern erleichtern soll, den Quellcode für externe Bibliotheken wiederzuverwenden.

Grundlegende Informationen

Bevor wir uns die Syntax genauer ansehen, sollten Sie wissen, was eine Android.mk-Datei im Wesentlichen enthält. In diesem Abschnitt wird die Datei Android.mk aus dem Hello-JNI-Beispiel verwendet, um zu erklären, welche Rolle jede Zeile in der Datei spielt.

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 im Entwicklungsbaum an. Hier gibt die vom Build-System bereitgestellte Makrofunktion my-dir den Pfad des aktuellen Verzeichnisses zurück, also des Verzeichnisses, das die Datei Android.mk selbst enthält.

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

include $(CLEAR_VARS)

Die Variable CLEAR_VARS verweist auf ein spezielles GNU-Makefile, das viele LOCAL_XXX-Variablen für Sie löscht, z. B. LOCAL_MODULE, LOCAL_SRC_FILES und LOCAL_STATIC_LIBRARIES. Beachten Sie, dass LOCAL_PATH nicht gelöscht wird. Diese Variable muss ihren Wert beibehalten, da das System alle Build-Kontrolldateien in einem einzigen GNU-Make-Ausführungskontext analysiert, in dem alle Variablen global sind. Sie müssen diese Variable vor der Beschreibung jedes Moduls deklarieren (oder neu deklarieren).

Als Nächstes speichert die Variable LOCAL_MODULE den Namen des Moduls, das Sie erstellen möchten. 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. Im Beispiel oben wird beispielsweise die Bibliothek libhello-jni.so generiert.

Hinweis: Wenn der Name Ihres Moduls bereits mit lib beginnt, fügt das Build-System kein zusätzliches lib-Präfix hinzu. Es verwendet den Modulnamen unverändert und fügt die Erweiterung .so hinzu. Aus einer Quelldatei, die ursprünglich beispielsweise libfoo.c hieß, wird also weiterhin eine Shared Object-Datei namens libfoo.so erstellt. Auf diese Weise werden Bibliotheken unterstützt, die von den Quellen der Android-Plattform aus Android.mk-Dateien generiert werden. Die Namen all dieser Bibliotheken beginnen mit lib.

In der nächsten Zeile werden die Quelldateien aufgelistet. Mehrere Dateien werden durch Leerzeichen voneinander getrennt:

LOCAL_SRC_FILES := hello-jni.c

Die Variable LOCAL_SRC_FILES muss eine Liste von C- und/oder C++-Quelldateien enthalten, die in ein Modul eingebunden werden sollen.

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 finden Sie komplexere Beispiele mit kommentierten Android.mk-Dateien. Außerdem finden Sie unter Sample: native-activity eine detaillierte 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 Variablen, die in der Android.mk-Datei verwendet werden können. Viele dieser Variablen haben vorab zugewiesene Werte. Andere, die Sie zuweisen.

Zusätzlich zu diesen Variablen können Sie auch eigene definieren. Beachten Sie dabei, 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.
• 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 GNU-Make-Variablen erläutert, die vom Build-System definiert werden, bevor die Android.mk-Datei geparst wird. Unter bestimmten Umständen parst das NDK Ihre Android.mk-Datei mehrmals und verwendet jedes Mal eine andere Definition für einige dieser Variablen.

CLEAR_VARS

Diese Variable verweist auf ein Build-Skript, das fast alle LOCAL_XXX-Variablen undefiniert, die unten im Abschnitt „Vom Entwickler definierte Variablen“ aufgeführt sind. Verwenden Sie diese Variable, um dieses Script einzufügen, bevor Sie ein neues Modul beschreiben. Die Syntax für die Verwendung lautet:

include $(CLEAR_VARS)

ERSTELLUNG_AUSFÜHRBAR

Diese Variable verweist auf ein Build-Script, das alle Informationen zum Modul erfasst, die Sie in Ihren LOCAL_XXX-Variablen angegeben haben, und bestimmt, wie eine Zielausführbare aus den von Ihnen aufgeführten Quellen erstellt wird. Für die Verwendung dieses Skripts 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 die 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 zum Erstellen von Einheitentests und anderen Debugging-Tools nützlich.

GEMEINSAM GENUTZTE_BIBLIOTHEK

Diese Variable verweist auf ein Build-Script, das alle Informationen zum Modul erfasst, die Sie in Ihren LOCAL_XXX-Variablen angegeben haben, und bestimmt, wie eine Ziel-Bibliothek aus den von Ihnen aufgeführten Quellen erstellt wird. 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_SHARED_LIBRARY)

Durch eine Variable für eine freigegebene Bibliothek generiert das Build-System eine Bibliotheksdatei mit der Erweiterung .so.

STATISCHE_BIBLIOTHEK_ERSTELLEN

Eine Variante von BUILD_SHARED_LIBRARY, die zum Erstellen einer statischen Bibliothek verwendet wird. Das Build-System kopiert statische Bibliotheken nicht in Ihr Projekt bzw. Ihre Pakete, kann diese jedoch zum Erstellen gemeinsam genutzter Bibliotheken verwenden (siehe LOCAL_STATIC_LIBRARIES und LOCAL_WHOLE_STATIC_LIBRARIES unten). 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 der Erweiterung .a generiert.

VORTEILE_GEMEINSAM GENUTZTE_BIBLIOTHEK

Verweist auf ein Build-Skript, mit dem eine vordefinierte gemeinsam genutzte Bibliothek angegeben wird. Im Gegensatz zu BUILD_SHARED_LIBRARY und BUILD_STATIC_LIBRARY kann der Wert von LOCAL_SRC_FILES hier keine Quelldatei sein. Stattdessen muss es ein einzelner Pfad zu einer vordefinierten gemeinsam genutzten Bibliothek wie foo/libfoo.so sein. Die Syntax für die Verwendung dieser Variablen lautet:

include $(PREBUILT_SHARED_LIBRARY)

Sie können auch mithilfe der Variablen LOCAL_PREBUILTS auf eine vordefinierte Bibliothek in einem anderen Modul verweisen. Weitere Informationen zur Verwendung von vordefinierten Bibliotheken finden Sie unter Vordefinierte Bibliotheken verwenden.

PREBUILT_STATIC_LIBRARY

Wie PREBUILT_SHARED_LIBRARY, aber für eine vorkonfigurierte statische Bibliothek. Weitere Informationen zur Verwendung von vordefinierten Elementen finden Sie unter Vordefinierte Bibliotheken verwenden.

Variablen für Zielinformationen

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

TARGET_ARCH

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

ZIELPLATTFORM

Die Nummer der Android API-Ebene, auf die das Build-System beim Parsen dieser Android.mk-Datei abzielt. Die Systembilder von Android 5.1 entsprechen beispielsweise dem Android API-Level 22: android-22. Eine vollständige Liste der Plattformnamen und 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

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 Sie nach ARMv8 AArch64 als Zielkombination aus CPU und ABI suchen:

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 haben in Zukunft andere Werte.

ABI-ZIEL

Eine Konkatenierung des Ziel-API-Levels von Android und der ABI. Dies ist besonders nützlich, wenn Sie mit einem bestimmten Zielsystem-Image für ein echtes Gerät testen möchten. So prüfen Sie beispielsweise, ob ein 64-Bit-ARM-Gerät mit Android API-Level 22 verwendet wird:

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.

LOKALER_PFAD

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

LOCAL_PATH := $(call my-dir)

Das Script, 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

In dieser Variablen wird der Name Ihres Moduls gespeichert. Er muss unter allen Modulnamen eindeutig sein und darf keine Leerzeichen enthalten. Sie müssen sie definieren, bevor Sie Scripts einfügen (außer dem für CLEAR_VARS). Sie müssen weder das Präfix lib noch die Dateiendung .so oder .a hinzufügen. Diese Änderungen werden automatisch vom Build-System vorgenommen. In den Dateien Android.mk und Application.mk verweisen Sie auf das Modul mit seinem unveränderten Namen. Die folgende Zeile führt beispielsweise 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 soll, können Sie mit der Variablen LOCAL_MODULE_FILENAME einen beliebigen Namen festlegen.

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 der Name Ihrer LOCAL_MODULE beispielsweise foo lautet, können Sie das System dazu zwingen, die generierte Datei libnewfoo zu nennen. Das folgende Beispiel zeigt, wie Sie dies erreichen:

LOCAL_MODULE := foo
LOCAL_MODULE_FILENAME := libnewfoo

Für ein Modul einer freigegebenen Bibliothek würde in diesem Beispiel die Datei libnewfoo.so generiert.

Hinweis: Sie können den Dateipfad oder die Dateiendung nicht überschreiben.

LOCAL_SRC_FILES

Diese Variable enthält die Liste der Quelldateien, die das Build-System zum Generieren des Moduls verwendet. Geben Sie nur die Dateien an, die das Build-System tatsächlich an den Compiler weitergibt, da das Build-System alle zugehörigen Abhängigkeiten automatisch berechnet. Sie können sowohl relative (zu LOCAL_PATH) als auch absolute Dateipfade verwenden.

Wir empfehlen, absolute Dateipfade zu vermeiden. Durch relative Pfade wird die Android.mk-Datei portabler.

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

LOKALE_CPP_ERWEITERUNG

Sie können diese optionale Variable verwenden, um für Ihre C++-Quelldateien eine andere Dateiendung als .cpp anzugeben. In der folgenden Zeile wird beispielsweise die Erweiterung in .cxx geändert. (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

LOCAL_CPP_FEATURES

Sie können diese optionale Variable verwenden, um anzugeben, dass Ihr Code auf bestimmten C++-Features basiert. Während des Build-Prozesses werden die richtigen Compiler- und Verknüpfungs-Flags aktiviert. Bei vorgefertigten Binärdateien gibt diese Variable auch an, von welchen Funktionen die Binärdatei abhängt. So wird sichergestellt, dass die endgültige Verknüpfung korrekt funktioniert. Wir empfehlen, diese Variable zu verwenden, anstatt -frtti und -fexceptions direkt in der LOCAL_CPPFLAGS-Definition zu aktivieren.

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

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

Mit dieser optionalen Variablen können Sie eine Liste von Pfaden angeben, die relativ zum NDK-Verzeichnis root sind und dem Include-Suchpfad hinzugefügt werden sollen, wenn alle Quellcodedateien (C, C++ und Assembly) kompiliert werden. 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 festlegen.

Das Build-System verwendet außerdem automatisch LOCAL_C_INCLUDES-Pfade, wenn das native Debugging mit ndk-gdb gestartet wird.

LOKALE_ASFLAGS

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

Achtung: Dieser Name unterscheidet sich von LOCAL_ASMFLAGS, der für yasm-Quellen verwendet wird.

LOCAL_ASMFLAGS

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

Achtung: Dieser Name unterscheidet sich von LOCAL_ASFLAGS, der für nicht-yasm-Quellen verwendet wird.

LOKALE_UNTERLAGEN

Flags, die an Clang übergeben werden, wenn C-, C++- und einige Assembly-Quelldateien (.s und .S, aber nicht .asm) erstellt werden. Dies kann nützlich sein, wenn Sie zusätzliche Makrodefinitionen oder Kompilierungsoptionen angeben. Verwenden Sie LOCAL_CPPFLAGS, um nur Flags für C++ anzugeben. Verwenden Sie LOCAL_CONLYFLAGS, um Flags nur für C anzugeben.

Ä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 Sie dann auch die Pfade verwenden können, die für das native Debugging mit ndk-gdb verfügbar sind.

LOCAL_CONLYFLAGS

Flags, die beim Kompilieren von C-Quellen an Clang übergeben werden. Im Gegensatz zu LOCAL_CFLAGS wird LOCAL_CONLYFLAGS beim Kompilieren von C++- oder Assembly-Quellen nicht an Clang übergeben.

LOCAL_CPPFLAGS

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

LOKALE_STATISCHE_BIBLIOTHEKEN

In dieser Variablen wird die Liste der Module der statischen Bibliotheken gespeichert, von denen das aktuelle Modul abhängt.

Wenn das aktuelle Modul eine freigegebene Bibliothek oder eine ausführbare Datei ist, werden diese Bibliotheken durch diese Variable mit dem resultierenden Binärcode verknüpft.

Wenn das aktuelle Modul eine statische Bibliothek ist, gibt diese Variable einfach an, dass andere Module, die vom aktuellen Modul abhängen, auch von den aufgeführten Bibliotheken abhängen.

LOKALE_GEMEINSAM GENUTZTE_BIBLIOTHEKEN

Diese Variable ist die Liste der Module der freigegebenen Bibliotheken, von denen dieses Modul zur Laufzeit abhängt. Diese Informationen werden zum Zeitpunkt der Verknüpfung und zum Einbetten der entsprechenden Informationen in die generierte Datei benötigt.

LOCAL_WHOLE_STATIC_LIBRARIES

Diese Variable ist eine Variante von LOCAL_STATIC_LIBRARIES und gibt an, dass der Linker die zugehörigen Bibliotheksmodule als vollständige Archive behandeln soll. Weitere Informationen zu ganzen Archiven finden Sie in der GNU ld-Dokumentation zum Flag --whole-archive.

Diese Variable ist nützlich, wenn es zyklische Abhängigkeiten zwischen mehreren Static Libraries gibt. Wenn Sie diese Variable zum Erstellen einer gemeinsam genutzten Bibliothek verwenden, wird das Build-System gezwungen, alle Objektdateien aus Ihren statischen Bibliotheken in die endgültige Binärdatei einzufügen. Dies gilt jedoch nicht für die Generierung ausführbarer Dateien.

LOCAL_LDLIBS

Diese Variable enthält die Liste zusätzlicher Verknüpfungs-Flags zum Erstellen Ihrer gemeinsam genutzten Bibliothek oder ausführbaren Datei. Sie können das Präfix -l verwenden, um den Namen bestimmter Systembibliotheken zu übergeben. Im folgenden Beispiel wird die Verknüpfung angewiesen, ein Modul zu generieren, das zum Zeitpunkt des Ladevorgangs auf /system/lib/libz.so verweist:

LOCAL_LDLIBS := -lz

Eine Liste der bereitgestellten Systembibliotheken, zu denen Sie in diesem NDK-Release eine Verknüpfung herstellen können, finden Sie unter Native APIs.

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

LOCAL_LDFLAGS

Die Liste weiterer Verknüpfungs-Flags für das Build-System, die beim Erstellen Ihrer gemeinsam genutzten Bibliothek oder ausführbarer Datei verwendet werden sollen. So verwenden Sie beispielsweise den ld.bfd-Linker unter ARM/X86:

LOCAL_LDFLAGS += -fuse-ld=bfd

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

LOCAL_ALLOW_UNDEFINED_SYMBOLS

Wenn das Build-System beim Erstellen einer freigegebenen Bibliothek auf eine nicht definierte Referenz stößt, wird standardmäßig der Fehler Undefiniertes Symbol ausgegeben. Dieser Fehler kann Ihnen helfen, Fehler in Ihrem Quellcode zu finden.

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

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

LOCAL_ARM_MODE

Standardmäßig generiert das Build-System ARM-Zielbinärdateien im Thumb-Modus, bei dem jede Anweisung 16 Bit breit ist und mit den STL-Bibliotheken im Verzeichnis thumb/ verknüpft wird. Wenn Sie diese Variable als arm definieren, muss das Build-System die Objektdateien des Moduls im 32-Bit-arm-Modus generieren. Das folgende 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. Dazu hängen Sie das Suffix .arm an die Namen der Quelldateien an. Im folgenden Beispiel wird dem Build-System beispielsweise mitgeteilt, bar.c immer im ARM-Modus zu kompilieren, foo.c jedoch 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. Dazu setzen Sie APP_OPTIM in Ihrer Application.mk-Datei auf debug. Wenn Sie debug angeben, wird ein ARM-Build erzwungen, da der Debugger der Toolchain Thumb-Code nicht richtig verarbeitet.

LOKALER_ARM-NEON

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

Beachten Sie, dass nicht alle ARMv7-basierten CPUs die NEON-Befehlssatzerweiterungen unterstützen. Aus diesem Grund müssen Sie eine Laufzeiterkennung durchführen, um diesen Code sicher zur Laufzeit verwenden zu können. Weitere Informationen finden Sie unter Neon-Unterstützung und CPU-Features.

Alternativ können Sie das Suffix .neon verwenden, um anzugeben, dass das Build-System nur bestimmte Quelldateien mit NEON-Unterstützung kompiliert. Im folgenden Beispiel kompiliert das Build-System foo.c mit Daumen- und Neon-Unterstützung, bar.c mit Daumen-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 Build-System Code mit Formatstringschutz. Dadurch wird ein Compilerfehler erzwungen, wenn in einer Funktion vom Typ printf ein nicht konstanter Formatstring verwendet wird. Dieser Schutz ist standardmäßig aktiviert. Sie können ihn aber 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, das von foo abhängt:

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 dem LOCAL_CFLAGS Ihres Moduls exportierte Flags vorangestellt, damit Sie sie einfach überschreiben können.

Außerdem ist die Beziehung zwischen den Modulen übertragbar: Wenn zoo von bar abhängt, das wiederum von foo abhängt, erbt zoo auch alle Flags, die aus foo exportiert wurden.

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 wird im obigen Beispiel -DFOO=1 beim Erstellen von foo/foo.c nicht an den Compiler übergeben. Wenn Sie die App lokal erstellen möchten, verwenden Sie stattdessen LOCAL_CFLAGS.

LOCAL_EXPORT_CPPFLAGS

Diese Variable entspricht LOCAL_EXPORT_CFLAGS, gilt aber 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. Das ist beispielsweise nützlich, wenn bar.c Header aus dem Modul foo enthalten muss.

LOCAL_EXPORT_LDFLAGS

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

LOCAL_EXPORT_LDLIBS

Diese Variable entspricht LOCAL_EXPORT_CFLAGS und weist das Build-System an, dem Compiler Namen bestimmter Systembibliotheken zu übergeben. Stellen Sie -l dem Namen jeder Bibliothek voran, die Sie angeben.

Das Build-System hängt importierte Verknüpfungs-Flags an den Wert der Variablen LOCAL_LDLIBS Ihres Moduls an. Das liegt an der Funktionsweise von Unix-Linkern.

Diese Variable ist in der Regel nützlich, wenn Modul foo eine statische Bibliothek ist und Code enthält, der von einer Systembibliothek abhängt. Sie können dann LOCAL_EXPORT_LDLIBS verwenden, 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 fügt das Buildsystem -llog am Ende des Linker-Befehls ein, wenn libbar.so erstellt wird. Dadurch wird der Verknüpfung mitgeteilt, dass libbar.so auch von der Logging-Bibliothek des Systems abhängt, da libbar.so von foo abhängt.

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 muss das Build-System die Syntax @ für Archive verwenden, die Zwischenobjektdateien oder verknüpfende Bibliotheken enthalten.

Diese Funktion kann unter Windows nützlich sein, da die Befehlszeile maximal 8.191 Zeichen akzeptiert, was für komplexe Projekte zu wenig sein kann. Außerdem wirkt sich dies auf die Kompilierung einzelner Quelldateien aus, da nahezu alle Compiler-Flags auch in Listendateien platziert werden.

Hinweis: Für jeden anderen Wert als true wird das Standardverhalten wiederhergestellt. Sie können APP_SHORT_COMMANDS auch in Ihrer Application.mk-Datei definieren, um dieses Verhalten für alle Module in Ihrem Projekt zu erzwingen.

Wir raten davon ab, dieses Feature standardmäßig zu aktivieren, da der Build dadurch langsamer wird.

LOCAL_THIN_ARCHIVE

Legen Sie diese Variable beim Erstellen statischer Bibliotheken auf true fest. Dadurch wird ein dünnes Archiv generiert, eine Bibliotheksdatei, die keine Objektdateien, sondern nur Dateipfade zu den tatsächlichen Objekten enthält, die sie normalerweise enthalten würde.

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

Gültige Werte sind true, false oder leer. In der Datei Application.mk kann über die Variable APP_THIN_ARCHIVE ein Standardwert festgelegt werden.

Hinweis: Diese Option wird für nicht statische Bibliotheksmodule oder vorgefertigte statische Bibliotheksmodule ignoriert.

LOCAL_FILTER_ASM

Definieren Sie diese Variable als Shell-Befehl, mit dem das Build-System die Assemblydateien filtert, die aus den Dateien extrahiert oder generiert wurden, die Sie für LOCAL_SRC_FILES angegeben haben. Wenn Sie diese Variable definieren, geschieht Folgendes:

1. Das Build-System generiert aus jeder C- oder C++-Quelldatei eine temporäre Assembly-Datei, anstatt sie in eine 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 Eingabedatei als erstes Argument und den Namen der Ausgabedatei als zweites Argument verwendet. Beispiel:

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

Vom NDK bereitgestellte Funktionsmakros

In diesem Abschnitt werden die Makros der GNU Make-Funktion erläutert, die vom NDK bereitgestellt werden. Sie können sie mit $(call <function>) auswerten. Sie geben dann Textinformationen zurück.

my-dir

Dieses Makro gibt den Pfad des letzten eingeschlossenen Makefile zurück. In der Regel ist das das Verzeichnis des aktuellen Android.mk. Mit my-dir werden LOCAL_PATH am Anfang der Datei Android.mk definiert. 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 solltest du my-dir nicht aufrufen, nachdem du eine weitere Datei eingefügt hast.

Betrachten Sie 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 besteht darin, dass der zweite Aufruf von my-dir LOCAL_PATH als $PATH/foo und nicht als $PATH definiert, weil der letzte Einschließen-Vorgang auf diese Datei verweist.

Sie können dieses Problem vermeiden, indem Sie zusätzliche Includes nach allen anderen Elementen in der Android.mk-Datei einfügen. 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 des aktuellen my-dir-Pfads befinden.

Sie können diese Funktion verwenden, um dem Build-System tief verschachtelte Quellverzeichnishierarchien bereitzustellen. Standardmäßig sucht das NDK nur in dem Verzeichnis nach Dateien, das die Datei Android.mk enthält.

this-makefile

Gibt den Pfad des aktuellen Makefile zurück, über das das Build-System die Funktion aufgerufen hat.

parent-makefile

Gibt den Pfad des übergeordneten Makefile in der Einschlussstruktur zurück, also den Pfad des Makefile, das das aktuelle Makefile enthält.

grand-parent-makefile

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

import-module

Eine Funktion, mit der Sie die Datei Android.mk eines Moduls nach dem Namen des Moduls suchen und einschließen können. Ein typisches Beispiel sieht so aus:

$(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.