Native APIs

Diese Seite bietet einen Überblick über die im NDK enthaltenen Bibliotheken, mit Links zu den relevanten Teilen der NDK API-Referenz und zu Anleitungen, wo sie vorhanden sind.

Native APIs verwenden

Die Verwendung einer vom NDK bereitgestellten Bibliothek erfolgt in zwei Schritten:

1. Weisen Sie das Build-System an, eine Verknüpfung zur Bibliothek herzustellen.

   • Wenn Sie ndk-build verwenden, fügen Sie die Bibliothek in LOCAL_LDLIBS in der Datei Android.mk hinzu. Beachten Sie, dass Sie das vorangestellte lib entfernen und stattdessen -l sagen. Für eine Verknüpfung mit libfoo und libbar würden Sie beispielsweise Folgendes schreiben: makefile LOCAL_LDLIBS := -lfoo -lbar

     Weitere Informationen zu LOCAL_LDLIBS finden Sie in der Dokumentation zu Android.mk.

   • Wenn Sie CMake verwenden: Folgen Sie der Anleitung in der Studio-Dokumentation NDK APIs hinzufügen.

2. #include die entsprechenden Header aus Ihrem Code.

APIs, die neuer als die minSdkVersion Ihrer Anwendung sind, können nicht standardmäßig aufgerufen werden. Sie müssen sie stattdessen über dlopen() und dlsym() verwenden. Einen einfacheren Ansatz finden Sie unter Neuere APIs verwenden.

Core-C/C++

C-Bibliothek

Die Header der C11-Standardbibliothek wie <stdlib.h> und <stdio.h> sind wie gewohnt verfügbar.

Beachten Sie, dass es unter Android im Gegensatz zu Linux keine separaten libpthread- oder librt-Bibliotheken gibt. Diese Funktion ist direkt in libc enthalten, für das nicht explizit eine Verknüpfung hergestellt werden muss.

Für mathematische Funktionen gibt es gemäß der üblichen Unix-Tradition ein separates libm-Objekt, das jedoch wie libc automatisch von den Build-Systemen verknüpft wird.

In <dlfcn.h> sind dynamische Verknüpfungsfunktionen wie dlopen(3) und dlsym(3) verfügbar. Sie müssen aber explizit eine Verknüpfung mit libdl herstellen.

Bibliothek: libc / libm / libdl

C++-Bibliothek

C++17-Support ist verfügbar. Weitere Informationen zur Unterstützung von C++-Bibliotheken finden Sie unter Unterstützung von C++-Bibliotheken.

Protokollierung

<android/log.h> enthält APIs für das Logging in logcat.

Verfügbar seit API-Level 3.

Bibliothek: liblog

Referenz: Logging

Trace

Die native Tracing API <android/trace.h> bietet das native Äquivalent der Klasse android.os.Trace in der Programmiersprache Java. Mit dieser API können Sie benannte Arbeitseinheiten in Ihrem Code verfolgen, indem Sie Trace-Ereignisse in den System-Trace-Zwischenspeicher schreiben. Anschließend können Sie die Trace-Ereignisse mit dem Systrace-Tool erfassen und analysieren.

Verfügbar ab API-Level 23.

Bibliothek: libandroid

Anleitung: Natives Tracing

zlib-Komprimierung

Sie können die Zlib-Komprimierungsbibliothek verwenden, indem Sie <zlib.h> einfügen und eine Verknüpfung mit libz herstellen.

Das NDK enthält immer die neuesten zlib-Headerdateien zum Zeitpunkt der Veröffentlichung. Das im NDK für statische Verknüpfungen enthaltene libz.a ist immer dieselbe Version. Die libz.so für die dynamische Verknüpfung stammt jedoch vom Gerät und ist die Version, die auf diesem Gerät veröffentlicht wurde. Das bedeutet insbesondere, dass die von Ihnen erstellten Header nicht der Version von zlib auf dem Gerät entsprechen. Daher sind die üblichen Warnungen vor Annahmen zu Implementierungsdetails hier besonders gültig. Uns sind keine Probleme mit der öffentlichen API bekannt, aber insbesondere das Strukturlayout hat sich im Laufe der Zeit geändert und wird dies wahrscheinlich auch weiterhin tun. Beachten Sie, dass neue APIs in späteren zlib-Versionen offensichtlich nicht für Betriebssystemversionen verfügbar sind, die älter als die API sind. Alle diese Probleme lassen sich auf Kosten einer höheren APK-Größe vermeiden, indem immer die statische libz.a anstelle von libz.so verwendet wird.

Verfügbar seit API-Level 3 (siehe Hinweis oben).

Bibliothek: libz

Grafik

OpenGL ES 1.0–3.2

Die standardmäßigen OpenGL ES 1.x-Header (<GLES/gl.h> und <GLES/glext.h>), 2.0-Header (<GLES2/gl2.h> und <GLES2/gl2ext.h>), 3.0-Header (<GLES3/gl3.h> und <GLES3/gl3ext.h>), 3.1-Header (<GLES3/gl31.h> und <GLES3/gl3ext.h>) und 3.2-Header (<GLES3/gl32.h> und <GLES3/gl3ext.h>) enthalten die für OpenGL ES erforderlichen Deklarationen.

Wenn du OpenGL ES 1.x verwenden möchtest, musst du dein natives Modul mit libGLESv1_CM verknüpfen.

Wenn du OpenGL ES 2.0 verwenden möchtest, verknüpfe dein natives Modul mit libGLESv2.

Wenn du OpenGL ES 3.x verwenden möchtest, musst du dein natives Modul mit libGLESv3 verknüpfen.

Alle Android-basierten Geräte unterstützen OpenGL ES 1.0 und 2.0.

Spätere Versionen von OpenGL ES unterstützen nur Android-Geräte mit der erforderlichen GPU vollständig. Die Bibliotheken sind jedoch auf allen Geräten vorhanden, die die API-Ebene unterstützen, auf der sie eingeführt wurden. Die Verknüpfung mit den Bibliotheken ist bedenkenlos, aber eine App muss den OpenGL ES-Versions- und Erweiterungsstring abfragen, um festzustellen, ob das aktuelle Gerät die benötigten Funktionen unterstützt. Informationen zum Ausführen dieser Abfrage finden Sie in der Beschreibung von glGetString() in der OpenGL-Spezifikation.

Außerdem müssen Sie ein <uses-feature>-Tag in Ihre Manifestdatei einfügen, um die benötigte Version von OpenGL ES anzugeben.

OpenGL ES 1.0 ist seit API-Level 4 verfügbar.

OpenGL ES 2.0 ist seit API-Level 5 verfügbar.

OpenGL ES 3.0 ist seit API-Level 18 verfügbar.

OpenGL ES 3.1 ist seit API-Level 21 verfügbar.

OpenGL ES 3.2 ist seit API-Level 24 verfügbar.

EGL

EGL bietet über die Header <EGL/egl.h> und <EGL/eglext.h> eine native Plattformschnittstelle zum Zuweisen und Verwalten von OpenGL ES-Kontexten und ‐Oberflächen.

Mit EGL können Sie die folgenden Vorgänge über nativen Code ausführen:

• Unterstützte EGL-Konfigurationen auflisten.
• OpenGL ES-Oberflächen werden zugewiesen und freigegeben.
• OpenGL ES-Kontexte erstellen und löschen.
• Oberflächen tauschen oder drehen.

API-Level 24 unterstützt die Erweiterungen EGL_KHR_mutable_render_buffer, ANDROID_create_native_client_buffer und ANDROID_front_buffer_auto_refresh.

Verfügbar seit API-Level 9.

Bibliothek: libEGL

Leitfaden: Native EGL-Plattformschnittstelle

Vulkan

Vulkan ist eine plattformübergreifende API mit geringem Aufwand für das Hochleistungs-3D-Grafikrendering. Vulkan ist ein offener Standard, der von der Khronos Group verwaltet wird. Die Standardheaderdatei <vulkan/vulkan.h> enthält die Deklarationen, die für Vulkan-Rendering-Aufrufe aus deinem Code erforderlich sind.

Codebeispiele finden Sie in den LunarG-Projekten VulkanSamples und android-vulkan-tutorials auf GitHub.

Die Vulkan-Bibliothek ist auf allen Geräten verfügbar, die API-Level 24 oder höher unterstützen. Apps müssen jedoch während der Laufzeit prüfen, ob die erforderliche GPU-Hardwareunterstützung verfügbar ist. Auf Geräten ohne Vulkan-Unterstützung werden keine Geräte aus vkEnumeratePhysicalDevices zurückgegeben.

Verfügbar seit API-Level 24.

Bibliothek: libvulkan

Leitfaden: Leitfaden zur Vulkan Graphics API

Bitmaps

Die libjnigraphics-Bibliothek stellt eine API bereit, die den Zugriff auf die Pixelpuffer von Java-Bitmap-Objekten ermöglicht. Der Workflow sieht so aus:

1. Rufen Sie AndroidBitmap_getInfo() auf, um Informationen wie Breite und Höhe zu einem bestimmten Bitmap-Handle abzurufen.

2. Rufen Sie AndroidBitmap_lockPixels() auf, um den Pixelpuffer zu sperren und einen Zeiger darauf abzurufen. Dadurch wird sichergestellt, dass sich die Pixel nicht bewegen, bis die App AndroidBitmap_unlockPixels() aufruft.

3. Passen Sie den Pixelzwischenspeicher entsprechend seinem Pixelformat, seiner Breite und anderen Eigenschaften an.

4. Rufen Sie AndroidBitmap_unlockPixels() auf, um den Zwischenspeicher zu entsperren.

Verfügbar seit API-Level 8.

Bibliothek: libjnigraphics

Referenz: Bitmap API-Referenz

Synchronisierungs-API

Verfügbar seit API-Level 26.

Bibliothek: libsync

Referenz: Sync API-Referenz

Kamera

Die nativen Kamera-APIs führen eine detailgenaue Aufnahme und Verarbeitung von Fotos durch. Im Gegensatz zur Java camera2 API unterstützt die native Camera API keine verworfenen Kamera-HAL 1.0-Implementierungen. Das bedeutet, dass in der Liste der verfügbaren Kamerageräte in der nativen Kamera-API keine Kamerageräte mit LEGACY-Hardwareebene aufgeführt werden.

Verfügbar seit API-Level 24.

Bibliothek: libcamera2ndk

Referenz: Camera API-Referenz

Medien

Libmediandk

Die Media APIs bieten native Low-Level-Oberflächen ähnlich wie MediaExtractor, MediaCodec und andere verwandte Java APIs.

Bibliothek: libmediandk

Referenz: Referenz zur Media API

OpenMAX AL

Die Verarbeitung nativer Android-Multimediatheken basiert auf der Khronos Group OpenMAX AL 1.0.1 API.

Die OpenMAX-AL-Header <OMXAL/OpenMAXAL.h> und <OMXAL/OpenMAXAL_Platform.h> enthalten die Deklarationen, die für eine Multimedia-Ausgabe auf der nativen Seite von Android erforderlich sind.

Die NDK-Distribution von OpenMAX AL bietet auch Android-spezifische Erweiterungen. Weitere Informationen zu diesen Erweiterungen finden Sie in den Kommentaren unter <OMXAL/OpenMAXAL_Android.h>.

Verfügbar seit API-Level 14.

Bibliothek: libOpenMAXAL

APIs für native Android-Anwendungen

Weitere Informationen finden Sie in der Referenzdokumentation zur Android NDK API.

Zu den APIs gehören:

• Asset
• Choreograf
• Konfiguration
• Eingang
• Schleife
• Native Aktivität
• Native Hardware-Puffer
• Natives Fenster
• Arbeitsspeicher
• Networking
• Sensor
• Speicher
• Oberflächentextur

Bibliothek: libandroid

Bibliothek: libnativewindow für neuere native Fensterfunktionen

Vollständige Referenz: Android NDK API-Referenz

Hardware-Puffer-APIs

Es gibt zwei native APIs, mit denen Sie Ihre eigenen Pipelines für die prozessübergreifende Zwischenspeicherverwaltung erstellen können.

Mit der nativen Hardware Puffer API <android/hardware_buffer.h> können Sie Zwischenspeicher direkt zuweisen, um eigene Pipelines für die prozessübergreifende Zwischenspeicherverwaltung zu erstellen. Sie können ein AHardwareBuffer zuweisen und damit einen Ressourcentyp EGLClientBuffer über die Erweiterung eglGetNativeClientBufferANDROID abrufen. Sie können diesen Zwischenspeicher an eglCreateImageKHR übergeben, um einen Ressourcentyp EGLImage zu erstellen, der dann auf unterstützten Geräten über glEGLImageTargetTexture2DOES an eine Textur gebunden werden kann. Dies kann beim Erstellen von Texturen hilfreich sein, die prozessübergreifend geteilt werden können.

Mit der nativen Hardware-Zwischenspeicher-JNI API (<android/hardware_buffer_jni.h>) können Sie ein HardwareBuffer-Objekt abrufen, das ein Parcelable-Objekt ist und somit zwischen zwei verschiedenen Prozessen übertragen werden kann. Dadurch bietet Ihre App ähnliche Funktionen wie SurfaceFlinger. Sie können beispielsweise Ihre eigene Pufferwarteschlange zwischen Prozessen erstellen, ohne auf interne Android-APIs zuzugreifen.

Audio

Audio

AAudio ist die derzeit unterstützte API für native Audioanzeigen. Es ersetzt OpenSL ES und bietet eine bessere Unterstützung für leistungsstarke Audioanwendungen, die Audio mit niedriger Latenz benötigen.

Verfügbar seit API-Level 26.

Bibliothek: libaaudio

Leitfaden: AAudio API-Leitfaden

Referenz: AAudio API-Referenz

OpenSL (Spanisch)

OpenSL ES ist eine weitere native Audio API, die ebenfalls unterstützt wird. Weitere Informationen finden Sie im Hinweis in der Anleitung unten.

Verfügbar seit API-Level 9. API-Level 14 unterstützt jetzt PCM.

Bibliothek: libOpenSLES

Leitfaden: Leitfaden zu OpenSL ES für Android

Neural Networks API

Die Neural Networks API (NNAPI) bietet Anwendungen eine Hardwarebeschleunigung für On-Device-ML-Vorgänge. Die API unterstützt die Erstellung, Kompilierung und Ausführung von Modellen auf dem Gerät. Anwendungen verwenden NNAPI normalerweise nicht direkt. Stattdessen soll die API von Bibliotheken für maschinelles Lernen, Frameworks und Tools aufgerufen werden, mit denen Entwickler ihre Modelle trainieren und auf Android-Geräten bereitstellen können.

Verfügbar ab API-Level 27.

Bibliothek: libneuralnetworks

Anleitung: Leitfaden zu neuronalen Netzwerken

Referenz: Referenz zur Neural Networks API