CMake

Das Android NDK unterstützt die Verwendung von CMake, um C- und C++-Code für Ihre Anwendung zu kompilieren. Auf dieser Seite wird erläutert, wie Sie CMake mit dem NDK über die ExternalNativeBuild des Android-Gradle-Plug-ins CMake direkt aufrufen.

Hinweis: Wenn Sie Android Studio verwenden, gehen Sie zu Hinzufügen von C- und C++-Code zu Ihrem Projekt, um die Grundlagen zu lernen, wie Sie Ihrem Projekt native Quellen hinzufügen, ein CMake-Build-Skript, das ihr CMake-Projekt als Gradle-Abhängigkeit hinzufügt, und Sie verwenden neuere CMake-Versionen als im SDK enthalten.

Die CMake-Toolchain-Datei

Das NDK unterstützt CMake über eine Toolchain-Datei. Toolchain-Dateien sind CMake-Dateien. die das Verhalten der Toolchain für die Cross-Kompilierung anpassen. Die Toolchain für das NDK verwendete Datei befindet sich im NDK unter <NDK>/build/cmake/android.toolchain.cmake

Hinweis: Wenn das Android SDK installiert ist, wird das NDK im SDK installiert in ndk/version/ oder ndk-bundle/.

Build-Parameter wie ABI, minSdkVersion usw. werden im Befehl angegeben Zeile beim Aufrufen von cmake. Eine Liste der unterstützten Argumente finden Sie in der Toolchain-Argumente.

Achtung :CMake hat eine eigene integrierte NDK-Unterstützung, die sich im Verhalten unterscheidet. im Vergleich zur CMake-Toolchain-Datei des NDK. Android unterstützt oder testet die integrierten Workflow. Wir empfehlen die Verwendung unserer Toolchain-Datei. externalNativeBuild (den NDK-Workflow, der Teil des Android-Gradle-Plug-ins ist), erhalten Nutzer automatisch anpassen. Wenn Sie externalNativeBuild nicht verwenden, finden Sie unten Informationen zu wie Sie unsere Toolchain-Datei direkt verwenden.

Das „neue“ Toolchain-Datei

Warnung: Die Verwendung von -DANDROID_USE_LEGACY_TOOLCHAIN_FILE=OFF wird nicht empfohlen. Die Legacy-Toolchain ist die Standardeinstellung, und wir empfehlen trotz ihres Namens.

Frühere NDKs haben mit einer neuen Implementierung der Toolchain-Datei experimentiert, die Verhaltensunterschiede zwischen der Verwendung der Toolchain-Datei des NDK und mit der integrierten CMake-Unterstützung. Dies erforderte letztlich einen erheblichen die noch nicht abgeschlossen ist, aber das Verhalten nicht verbessert hat, Deshalb verfolgen wir dieses Ziel nicht mehr.

Das „neue“ Toolchain-Datei weist im Vergleich zur Legacy-Datei auf das Verhalten zurück. Toolchain-Datei. Das Standardverhalten entspricht dem empfohlenen Workflow. Wenn Sie mit -DANDROID_USE_LEGACY_TOOLCHAIN_FILE=OFF empfehlen wir, dieses Flag zu entfernen aus Ihrem Build. Die neue Toolchain-Datei hat nie Parität mit der Legacy-Datei erreicht Toolchain-Datei, sodass es wahrscheinlich zu einem Rückgang des Verhaltens kommt.

Obwohl wir von der Verwendung der neuen Toolchain-Datei abraten, gibt es derzeit keine aus dem NDK zu entfernen. Ansonsten würden Builds beschädigt werden, Unterschiede im Verhalten der neuen und Legacy-Toolchain-Dateien die Option umbenannt, um deutlich zu machen, dass "Legacy" ist eigentlich würden die Nutzer dieser Option ebenfalls unbrauchbar sein. Wenn Sie die Methode Neue Toolchain-Datei, die Sie nicht migrieren müssen, aber alle Fehler gemeldet haben neuen Verhalten der Toolchain-Datei wahrscheinlich nicht korrigiert. die Sie migrieren müssen.

Nutzung

Logo: Gradle

Die CMake-Toolchain-Datei wird automatisch verwendet, wenn Sie externalNativeBuild Weitere Informationen finden Sie unter C++- und C++-Code zu Ihrem weitere Informationen.

Befehlszeile

Beim Erstellen mit CMake außerhalb von Gradle werden die Toolchain-Datei selbst und müssen ihre Argumente an CMake übergeben werden. Beispiel:

$ cmake \
    -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake \
    -DANDROID_ABI=$ABI \
    -DANDROID_PLATFORM=android-$MINSDKVERSION \
    $OTHER_ARGS

Toolchain-Argumente

Die folgenden Argumente können an die Toolchain-Datei von CMake übergeben. Wenn Sie fügen Sie mit Gradle Argumente android.defaultConfig.externalNativeBuild.cmake.arguments gemäß den ExternalNativeBuild-Dokumentation Beim Erstellen über die Befehlszeile übergeben Sie Argumente an CMake mit -D. Wenn Sie beispielsweise erzwingen möchten, dass Armeabi-v7a nicht mit Neon erstellt wird erhalten Sie über -DANDROID_ARM_NEON=FALSE.

Hinweis :Alle erforderlichen Argumente werden von Gradle automatisch übergeben und müssen nur wird explizit übergeben, wenn Sie einen Build über die Befehlszeile ausführen.

ANDROID_ABI

Hinweis :Dies ist ein erforderliches Argument.

Das Ziel-ABI. Informationen zu unterstützten ABIs finden Sie unter Android-ABIs.

Logo: Gradle

Gradle stellt dieses Argument automatisch bereit. Nicht explizit festlegen Argument in der Datei build.gradle. Um zu steuern, worauf ABIs Gradle ausgerichtet ist, Verwende abiFilters, wie in Android-ABIs beschrieben.

Befehlszeile

Erstellen Sie Builds für ein einzelnes Ziel pro Build. Ausrichtung auf mehrere Android-Geräte ABI, du musst einmal pro ABI erstellen. Es wird empfohlen, einen anderen Build zu verwenden Verzeichnisse für jedes ABI, um Konflikte zwischen Builds zu vermeiden.

Wert	Hinweise
armeabi-v7a
armeabi-v7a with NEON	Wie bei armeabi-v7a.
arm64-v8a
x86
x86_64

ANDROID_ARM_MODE

Gibt an, ob Arm- oder Daumenanweisungen für armeabi-v7a generiert werden sollen. Enthält keine für andere ABIs. Weitere Informationen finden Sie in den Android-ABIs. Dokumentation.

Wert	Hinweise
Arm
Daumen	Standardverhalten.

ANDROID_NATIVE_API_LEVEL

Alias für ANDROID_PLATFORM.

ANDROID_PLATFORM

Gibt das von der Anwendung oder Bibliothek unterstützte minimale API-Level an. Dieses -Wert entspricht dem minSdkVersion der Anwendung.

Logo: Gradle

Wenn Sie das Android-Gradle-Plug-in verwenden, wird dieser Wert automatisch auf entspricht dem minSdkVersion der Anwendung und sollte nicht manuell festgelegt werden.

Befehlszeile

Beim direkten Aufrufen von CMake wird standardmäßig die niedrigste API-Ebene verwendet. die vom verwendeten NDK unterstützt werden. Mit NDK r20 wird dieser Wert beispielsweise auf API-Level 16.

Warnung: NDK-Bibliotheken können nicht auf Geräten mit einer API-Ebene unter der ANDROID_PLATFORM-Wert, mit dem der Code erstellt wurde.

Für diesen Parameter sind mehrere Formate zulässig:

• android-$API_LEVEL
• $API_LEVEL
• android-$API_LETTER

Mit dem Format $API_LETTER können Sie android-N angeben, ohne die mit dieser Veröffentlichung verknüpfte Nummer ermitteln. Beachten Sie, dass einige Releases hat eine API-Erhöhung ohne Brieferhöhung erhalten. Diese APIs können angegeben werden indem Sie das Suffix -MR1 anhängen. API-Level 25 ist beispielsweise android-N-MR1.

ANDROID_STL

Gibt an, welche STL für diese Anwendung verwendet werden soll. Weitere Informationen finden Sie unter C++ Bibliotheksunterstützung. Standardmäßig wird c++_static verwendet.

Achtung :Das Standardverhalten ist nicht für alle Anwendungen geeignet. Achten Sie darauf, finden Sie im Leitfaden zur Unterstützung der C++-Bibliothek, insbesondere im Abschnitt über statischen Laufzeiten vor, bevor Sie eine STL-Datei auswählen.

Wert	Hinweise
C++-geteilt	Die Variante der gemeinsam genutzten Bibliothek von libc++.
C++_statisch	Die statische Bibliotheksvariante von libc++.
Keine	Keine Unterstützung der C++-Standardbibliothek.
Infotainmentsystem	Die System-STL

CMake-Build-Befehl verstehen

Beim Beheben von CMake-Build-Problemen ist es hilfreich, den spezifischen Build Argumente, die Gradle bei der Cross-Kompilierung für Android verwendet.

Das Android-Gradle-Plug-in speichert die Build-Argumente, die zum Ausführen eines CMake-Build für jedes ABI und jeden Build-Typ erstellen mit build_command.txt koppeln. Diese Dateien befinden sich hier: Verzeichnis:

<project-root>/<module-root>/.cxx/cmake/<build-type>/<ABI>/

Das folgende Snippet zeigt ein Beispiel für die CMake-Argumente zum Erstellen einer Debug-fähige Version des hello-jni-Beispiels mit Ausrichtung auf armeabi-v7a Architektur.

                    Executable : ${HOME}/Android/Sdk/cmake/3.10.2.4988404/bin/cmake
arguments :
-H${HOME}/Dev/github-projects/googlesamples/ndk-samples/hello-jni/app/src/main/cpp
-DCMAKE_FIND_ROOT_PATH=${HOME}/Dev/github-projects/googlesamples/ndk-samples/hello-jni/app/.cxx/cmake/universalDebug/prefab/armeabi-v7a/prefab
-DCMAKE_BUILD_TYPE=Debug
-DCMAKE_TOOLCHAIN_FILE=${HOME}/Android/Sdk/ndk/22.1.7171670/build/cmake/android.toolchain.cmake
-DANDROID_ABI=armeabi-v7a
-DANDROID_NDK=${HOME}/Android/Sdk/ndk/22.1.7171670
-DANDROID_PLATFORM=android-23
-DCMAKE_ANDROID_ARCH_ABI=armeabi-v7a
-DCMAKE_ANDROID_NDK=${HOME}/Android/Sdk/ndk/22.1.7171670
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON
-DCMAKE_LIBRARY_OUTPUT_DIRECTORY=${HOME}/Dev/github-projects/googlesamples/ndk-samples/hello-jni/app/build/intermediates/cmake/universalDebug/obj/armeabi-v7a
-DCMAKE_RUNTIME_OUTPUT_DIRECTORY=${HOME}/Dev/github-projects/googlesamples/ndk-samples/hello-jni/app/build/intermediates/cmake/universalDebug/obj/armeabi-v7a
-DCMAKE_MAKE_PROGRAM=${HOME}/Android/Sdk/cmake/3.10.2.4988404/bin/ninja
-DCMAKE_SYSTEM_NAME=Android
-DCMAKE_SYSTEM_VERSION=23
-B${HOME}/Dev/github-projects/googlesamples/ndk-samples/hello-jni/app/.cxx/cmake/universalDebug/armeabi-v7a
-GNinja
jvmArgs :


                    Build command args: []
                    Version: 1

Vordefinierte Bibliotheken verwenden

Wenn die zu importierende vordefinierte Bibliothek als AAE bereitgestellt wird, folgen Sie Abhängigkeitsdokumente in Studio um sie zu importieren und zu verwenden. Wenn Sie nicht AGP verwenden, können Sie https://google.github.io/prefab/example-workflow.html, doch wahrscheinlich zu AGP zu migrieren.

Für Bibliotheken, die nicht als AAE verteilt werden, Anleitungen zur Verwendung Bibliotheken mit CMake verwenden, finden Sie in der add_library-Dokumentation zu IMPORTED im CMake-Handbuch.

Drittanbietercode erstellen

Es gibt einige Möglichkeiten, Drittanbietercode im Rahmen Ihres CMake-Codes zu erstellen. und welche Option am besten funktioniert, hängt von Ihrer Situation ab. Das Beste ist es oft, dies gar nicht zu tun. Erstellen Sie stattdessen automatisch angewendete Empfehlungen für das und in Ihrer Anwendung verwenden. Sie müssen nicht unbedingt Automatisch angewendete Empfehlungen veröffentlichen. Sie kann innerhalb Ihres Gradle-Projekts verwendet werden.

Sollte dies keine Option sein, gehen Sie so vor:

• Drittanbieterquelle in Ihr Repository übertragen (d.h. kopieren) und verwenden add_subdirectory dafür verwendet. Dies funktioniert nur, wenn die andere Bibliothek ebenfalls mit CMake erstellt.
• Definieren Sie ein ExternalProject.
• Erstellen Sie die Bibliothek getrennt von Ihrem Projekt und folgen Sie Verwenden Sie vordefinierte Bibliotheken, um sie als vordefinierten Import zu importieren.

YASM-Unterstützung in CMake

Das NDK bietet CMake-Unterstützung für die Erstellung von Assembly-Code, der in YASM zur Ausführung auf x86 und x86-64 Architekturen. YASM ist ein Open-Source-Assembler für x86 und x86-64 Architekturen, die auf dem NASM-Assembler basieren.

Um Assembly-Code mit CMake zu erstellen, nehmen Sie die folgenden Änderungen im CMakeLists.txt:

1. Rufen Sie enable_language mit dem Wert ASM_NASM auf.
2. Je nachdem, ob Sie eine gemeinsam genutzte Bibliothek oder eine ausführbare add_library oder add_executable aufrufen. In Die Argumente übergeben eine Liste von Quelldateien, die aus den .asm-Dateien besteht. für das Assembly-Programm in YASM und die .c-Dateien für das zugehörige C Bibliotheken oder Funktionen.

Das folgende Snippet zeigt, wie du dein CMakeLists.txt so konfigurieren kannst, dass es ein YASM-Programm als gemeinsam genutzte Bibliothek erstellen.

cmake_minimum_required(VERSION 3.6.0)

enable_language(ASM_NASM)

add_library(test-yasm SHARED jni/test-yasm.c jni/print_hello.asm)

Ein Beispiel für die Erstellung eines YASM-Programms als ausführbare Datei finden Sie in der yasm-Bibliothek test im NDK-Git-Repository.

Probleme melden

Sollten Probleme mit dem NDK oder der zugehörigen CMake-Toolchain-Datei auftreten, melden Sie diese bitte. über die Problemverfolgung android-ndk/ndk auf GitHub. Für Gradle oder Probleme mit dem Android-Gradle-Plug-in: Melden Sie stattdessen einen Studio-Fehler.