Native APIs

Auf dieser Seite finden Sie einen Überblick über die im NDK enthaltenen Bibliotheken mit Links zu den relevanten Teilen der NDK API-Referenz und zu Anleitungen, sofern verfügbar.

Native APIs verwenden

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

1. Das Build-System anweisen, eine Verknüpfung mit der Bibliothek herzustellen.

   • Wenn Sie ndk-build verwenden: Fügen Sie die Bibliothek in Android.mk zu LOCAL_LDLIBS hinzu. Achten Sie darauf, dass Sie das vorangestellte lib entfernen und stattdessen -l sagen. Wenn Sie beispielsweise libfoo und libbar verknüpfen möchten, schreiben Sie Folgendes: makefile LOCAL_LDLIBS := -lfoo -lbar

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

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

2. #include die entsprechenden Überschriften aus Ihrem Code.

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

C/C++-Kern

C-Bibliothek

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

Im Gegensatz zu Linux gibt es unter Android keine separaten libpthread- oder librt-Bibliotheken. Diese Funktion ist direkt in libc enthalten und muss nicht explizit verknüpft werden.

Es gibt eine separate libm für mathematische Funktionen (entsprechend der üblichen Unix-Tradition), die aber wie libc automatisch von den Build-Systemen verknüpft wird.

Die Funktionen des dynamischen Linker in <dlfcn.h> wie dlopen(3) und dlsym(3) sind verfügbar, Sie müssen jedoch explizit eine Verknüpfung mit libdl herstellen.

Bibliothek: libc / libm / libdl

C++-Bibliothek

C++17 wird unterstützt. 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 die Protokollierung in Logcat.

Verfügbar seit API-Level 3.

Bibliothek: liblog

Weitere Informationen finden Sie unter Logging.

Trace

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

Verfügbar seit API-Level 23.

Bibliothek: libandroid

Leitfaden: Natives Tracking

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. Die im NDK für die statische Verknüpfung 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 Header, auf die Sie den Build ausgeführt haben, nicht mit der zlib-Version auf dem Gerät übereinstimmen. Daher gelten die üblichen Warnungen vor Annahmen zu Implementierungsdetails hier besonders. Uns sind keine Probleme mit der öffentlichen API bekannt. Das Layout von Strukturen hat sich jedoch im Laufe der Zeit geändert und wird sich wahrscheinlich auch in Zukunft ändern. Die neue API in neueren zlib-Versionen ist natürlich nicht auf Betriebssystemversionen verfügbar, die älter als die API sind. Sie können all diese Probleme vermeiden (auf Kosten einer erhöhten APK-Größe), indem Sie immer die statische libz.a anstelle von libz.so verwenden.

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

Bibliothek: libz

Grafik

OpenGL ES 1.0 bis 3.2

Die Standard-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 Sie OpenGL ES 1.x verwenden möchten, verknüpfen Sie Ihr natives Modul mit libGLESv1_CM.

Wenn Sie OpenGL ES 2.0 verwenden möchten, verknüpfen Sie Ihr natives Modul mit libGLESv2.

Wenn Sie OpenGL ES 3.x verwenden möchten, verknüpfen Sie Ihr natives Modul mit libGLESv3.

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

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

Außerdem müssen Sie in Ihrer Manifestdatei das Tag <uses-feature> einfügen, um die erforderliche 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 <EGL/egl.h>- und <EGL/eglext.h>-Header eine native Plattformschnittstelle zum Zuweisen und Verwalten von OpenGL ES-Kontexten und ‑Oberflächen.

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

• Liste der unterstützten EGL-Konfigurationen.
• OpenGL ES-Oberflächen zuweisen und freigeben.
• OpenGL ES-Kontexte erstellen und löschen.
• Oberflächen tauschen oder spiegeln

Mit API-Ebene 24 wurde die Unterstützung für die Erweiterungen EGL_KHR_mutable_render_buffer, ANDROID_create_native_client_buffer und ANDROID_front_buffer_auto_refresh hinzugefügt.

Verfügbar seit API-Level 9.

Bibliothek: libEGL

Leitfaden: EGL Native Platform Interface

Vulkan

Vulkan ist eine plattformübergreifende API mit geringem Overhead für leistungsstarkes 3D-Grafik-Rendering. Vulkan ist ein offener Standard, der von der Khronos Group verwaltet wird. Die Standard-<vulkan/vulkan.h>-Headerdatei enthält die Deklarationen, die zum Ausführen von Vulkan-Renderingaufrufen aus Ihrem 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 vorhanden, die API-Ebene 24 oder höher unterstützen. Apps müssen jedoch zur Laufzeit prüfen, ob die erforderliche GPU-Hardware unterstützt wird. Bei Geräten ohne Vulkan-Unterstützung werden von vkEnumeratePhysicalDevices keine Geräte zurückgegeben.

Verfügbar seit API-Level 24.

Bibliothek: libvulkan

Leitfaden: Vulkan-Grafik-API-Leitfaden

Bitmaps

Die libjnigraphics-Bibliothek stellt eine API bereit, die den Zugriff auf die Pixelbuffer 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 Verweis darauf abzurufen. So wird sichergestellt, dass sich die Pixel erst bewegen, wenn die App AndroidBitmap_unlockPixels() aufruft.

3. Ändern Sie den Pixelpuffer entsprechend dem Pixelformat, der Breite und anderen Eigenschaften.

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

Verfügbar seit API-Level 8.

Bibliothek: libjnigraphics

Referenz: Bitmap API-Referenz

Sync API

Verfügbar seit API-Level 26.

Bibliothek: libsync

Referenz: Sync API-Referenz

Kamera

Die nativen Kamera-APIs ermöglichen eine detaillierte Aufnahme und Verarbeitung von Fotos. Im Gegensatz zur Java camera2 API unterstützt die native Kamera-API keine veralteten Kamera-HAL 1.0-Implementierungen. Das bedeutet, dass in der Liste der verfügbaren Kameras in der nativen Kamera-API keine Kamerageräte mit der Hardwareebene LEGACY aufgeführt werden.

Verfügbar seit API-Level 24.

Bibliothek: libcamera2ndk

Referenz: Camera API-Referenz

Medien

libmediandk

Die Media APIs bieten native Low-Level-Schnittstellen, die denen von MediaExtractor, MediaCodec und anderen ähnlichen Java APIs ähneln.

Bibliothek: libmediandk

Referenz: Media API-Referenz

OpenMAX AL

Die native Multimedia-Verarbeitung von Android basiert auf der OpenMAX AL 1.0.1 API der Khronos Group.

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

Die NDK-Distribution von OpenMAX AL bietet auch Android-spezifische Erweiterungen. 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 Android NDK API-Referenzdokumentation.

Beispiele für APIs:

• Asset
• Choreograf
• Konfiguration
• Eingang
• Looper
• Native Aktivität
• Native Hardware-Puffer
• Natives Fenster
• Arbeitsspeicher
• Networking
• Sensor
• Speicher
• SurfaceTexture

Bibliothek: libandroid

Bibliothek: libnativewindow für neuere native Fensterfunktionen

Vollständige Referenz: Android NDK API-Referenz

Binder APIs

Mit Binder APIs können Sie Kommunikationskanäle zwischen Prozessen erstellen. Dies ist die Low-Level-Implementierung der prozessübergreifenden Kommunikation in Android. Verwenden Sie nach Möglichkeit Komponenten auf höherer Ebene. Diese Bibliothek ist jedoch für erweiterte Anwendungsfälle verfügbar.

Bibliothek: libbinder_ndk

Referenz: Binder

Hardware-Buffer-APIs

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

Mit der nativen Hardware-Buffer-API <android/hardware_buffer.h> können Sie Buffers direkt zuweisen, um eigene Pipelines für die prozessübergreifende Bufferverwaltung zu erstellen. Sie können eine AHardwareBuffer zuweisen und damit über die eglGetNativeClientBufferANDROID-Erweiterung einen EGLClientBuffer-Ressourcentyp abrufen. Sie können diesen Puffer an eglCreateImageKHR übergeben, um einen EGLImage-Ressourcentyp zu erstellen, der dann auf unterstützten Geräten über glEGLImageTargetTexture2DOES an eine Textur gebunden werden kann. Das kann nützlich sein, um Texturen zu erstellen, die prozessübergreifend freigegeben werden können.

Mit der nativen Hardware-Buffer-JNI API (<android/hardware_buffer_jni.h>) können Sie ein HardwareBuffer-Objekt abrufen, das Parcelable ist und daher zwischen zwei verschiedenen Prozessen übertragen werden kann. Dadurch erhält Ihre App ähnliche Funktionen wie SurfaceFlinger, z. B. die Möglichkeit, eine eigene Pufferwarteschlange zwischen Prozessen zu erstellen, ohne auf interne Android-APIs zuzugreifen.

Audio

AAudio

AAudio ist die derzeit unterstützte native Audio-API. Es ersetzt OpenSL ES und bietet eine bessere Unterstützung für leistungsstarke Audio-Apps, die Audio mit geringer Latenz erfordern.

Verfügbar seit API-Level 26.

Bibliothek: libaaudio

Leitfaden: AAudio API-Leitfaden

Referenz: AAudio API-Referenz

OpenSL ES

OpenSL ES ist eine weitere native Audio-API, die ebenfalls unterstützt wird. Beachten Sie jedoch den Hinweis in der Anleitung unten.

Verfügbar seit API-Level 9. Mit API-Level 14 wurde die PCM-Unterstützung hinzugefügt.

Bibliothek: libOpenSLES

Leitfaden: OpenSL ES für Android

Neural Networks API

Die Neural Networks API (NNAPI) bietet Apps Hardwarebeschleunigung für On-Device-Vorgänge für maschinelles Lernen. Die API unterstützt das Erstellen, Kompilieren und Ausführen von Modellen auf dem Gerät. Apps verwenden die NNAPI in der Regel nicht direkt. Stattdessen soll die API von Bibliotheken, Frameworks und Tools für maschinelles Lernen aufgerufen werden, mit denen Entwickler ihre Modelle trainieren und auf Android-Geräten bereitstellen können.

Verfügbar seit API-Level 27.

Bibliothek: libneuralnetworks

Leitfaden: Leitfaden zu neuronalen Netzwerken

Referenz: Referenz zur Neural Networks API