Diese Seite bietet einen Überblick über die im NDK enthaltenen Bibliotheken sowie Links zu den relevanten Teilen der NDK API-Referenz und Anleitungen, wo sie sich befinden.
Native APIs verwenden
Die Verwendung einer vom NDK bereitgestellten Bibliothek erfolgt in zwei Schritten:
Bitten Sie das Build-System, eine Verknüpfung mit der Bibliothek herzustellen.
Wenn du ndk-build verwendest: Füge die Bibliothek zu
LOCAL_LDLIBS
in deiner Android.mk-Datei hinzu. Sie entfernen das vorangestelltelib
und sagen stattdessen-l
. Um beispielsweise eine Verknüpfung mitlibfoo
undlibbar
herzustellen, würden Sie so schreiben:makefile LOCAL_LDLIBS := -lfoo -lbar
Weitere Informationen zu
LOCAL_LDLIBS
findest du in der Dokumentation zu Android.mk.Wenn Sie CMake verwenden: Folgen Sie der Anleitung in der Studio-Dokumentation NDK APIs hinzufügen.
#include
die entsprechenden Header aus Ihrem Code.
Kern-C/C++
C-Bibliothek
Die standardmäßigen C11-Bibliotheksheader wie <stdlib.h>
und <stdio.h>
sind wie gewohnt verfügbar.
Unter Android gibt es im Gegensatz zu Linux 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 (nach der üblichen Unix-Tradition), die jedoch wie libc
automatisch von den Build-Systemen verknüpft wird.
Funktionen zur dynamischen Verknüpfung in <dlfcn.h>
wie dlopen(3) und dlsym(3) sind verfügbar, Sie müssen jedoch explizit eine Verknüpfung zu libdl
erstellen.
Bibliothek: libc
/ libm
/ libdl
C++-Bibliothek
C++17-Unterstützung 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. Dazu werden Trace-Ereignisse in den System-Trace-Zwischenspeicher geschrieben. 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 Tracing
zlib-Komprimierung
Sie können die Zlib-Komprimierungsbibliothek verwenden. Fügen Sie dazu <zlib.h>
ein und verknüpfen Sie es mit libz
.
Der NDK enthält immer die neuesten zlib-Header-Dateien zum Zeitpunkt der Veröffentlichung und 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, für die Sie erstellt haben, nicht mit der zlib-Version auf dem Gerät übereinstimmen. 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 API in späteren zlib-Versionen offensichtlich nicht in Betriebssystemversionen vor der API verfügbar sein wird. Es ist möglich, alle diese Probleme (auf Kosten der erhöhten APK-Größe) zu vermeiden, indem Sie immer das statische libz.a
anstelle von libz.so
verwenden.
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, verknüpfe dein natives Modul mit libGLESv1_CM
.
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, verknüpfe dein natives Modul mit libGLESv3
.
Alle Android-basierten Geräte unterstützen OpenGL ES 1.0 und 2.0.
Spätere Versionen von OpenGL ES 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. Eine App muss jedoch 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 Beschreibung von glGetString()
in der OpenGL-Spezifikation.
Außerdem musst du ein <uses-feature>
-Tag in deine Manifestdatei einfügen, um anzugeben, welche Version von OpenGL ES du benötigst.
OpenGL ES 1.0 ist seit API-Level 4 verfügbar.
OpenGL ES 2.0 ist ab 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 für die Zuordnung und Verwaltung von OpenGL ES-Kontexten und -Oberflächen.
Mit EGL können Sie die folgenden Vorgänge aus nativem 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 umdrehen
API-Level 24 unterstützt jetzt 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: EGL Native Platform Interface
Vulkan
Vulkan ist eine plattformübergreifende API mit geringem Aufwand für hochleistungsfähiges 3D-Grafikrendering. Vulkan ist ein offener Standard, der von der Khronos Group verwaltet wird. Die Standard-Header-Datei <vulkan/vulkan.h>
enthält die Deklarationen, die erforderlich sind, um Vulkan-Renderingaufrufe über Ihren Code auszuführen.
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 zur Laufzeit prüfen, ob die erforderliche GPU-Hardwareunterstützung verfügbar ist. Bei Geräten ohne Vulkan-Unterstützung werden keine Geräte von vkEnumeratePhysicalDevices
zurückgegeben.
Verfügbar seit API-Level 24.
Bibliothek: libvulkan
Anleitung: Leitfaden zur Vulkan Graphics API
Bitmaps
Die libjnigraphics
-Bibliothek enthält eine API, die den Zugriff auf die Pixelzwischenspeicher von Java-Bitmap
-Objekten ermöglicht. Der Workflow sieht so aus:
Rufen Sie
AndroidBitmap_getInfo()
auf, um Informationen wie Breite und Höhe zu einem bestimmten Bitmap-Handle abzurufen.Rufen Sie
AndroidBitmap_lockPixels()
auf, um den Pixelzwischenspeicher zu sperren und einen Zeiger darauf abzurufen. Dadurch wird sichergestellt, dass sich die Pixel erst verschieben, wenn die AppAndroidBitmap_unlockPixels()
aufruft.Passen Sie den Pixelzwischenspeicher entsprechend dem Pixelformat, der Breite und anderen Eigenschaften an.
Rufen Sie
AndroidBitmap_unlockPixels()
auf, um den Zwischenspeicher 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: Referenz zur Sync API
Kamera
Die nativen Kamera-APIs sorgen für eine detailgenaue Aufnahme und Verarbeitung von Fotos. Im Gegensatz zur Java Camera2 API unterstützt die native Kamera-API keine verworfenen Kamera-HAL 1.0-Implementierungen. Das heißt, in der Liste der verfügbaren Kamera in der nativen Kamera-API werden keine Kamerageräte mit dem Hardware-Level LEGACY aufgeführt.
Verfügbar seit API-Level 24.
Bibliothek: libcamera2ndk
Referenz: Referenz zur Kamera API
Medien
Libmediandk
Die Media APIs bieten native Low-Level-Schnittstellen ähnlich wie MediaExtractor
, MediaCodec
und andere verwandte Java APIs.
Bibliothek: libmediandk
Referenz: Media API-Referenz
OpenMAX AL
Die native Multimedia-Verarbeitung von Android basiert auf der Khronos Group OpenMAX AL 1.0.1 API.
Die standardmäßigen OpenMAX AL-Header <OMXAL/OpenMAXAL.h>
und <OMXAL/OpenMAXAL_Platform.h>
enthalten die Deklarationen, die für die Multimedia-Ausgabe von 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-Apps
Weitere Informationen finden Sie in der Referenzdokumentation zur Android NDK API.
Zu den APIs gehören:
- Asset
- Choreograf
- Konfiguration
- Eingang
- Looper
- Native Aktivitäten
- Native Hardware-Zwischenspeicher
- Natives Fenster
- Arbeitsspeicher
- Networking
- Sensor
- Speicher
- Oberflächentextur
Bibliothek: libandroid
Bibliothek: libnativewindow
für neuere native Fensterfunktionen
Vollständige Referenz: Referenz zur Android NDK API
Hardware Buffer APIs
Es gibt zwei native APIs, mit denen Sie eigene Pipelines für die prozessübergreifende Zwischenspeicherverwaltung erstellen können.
Mit der nativen Hardware buffer API <android/hardware_buffer.h>
können Sie Puffer direkt zuweisen, um Ihre eigenen Pipelines für die prozessübergreifende Zwischenspeicherverwaltung zu erstellen.
Sie können eine AHardwareBuffer
zuweisen und sie verwenden, um über die Erweiterung eglGetNativeClientBufferANDROID
den Ressourcentyp EGLClientBuffer
abzurufen. Sie können diesen Zwischenspeicher an eglCreateImageKHR
übergeben, um einen EGLImage
-Ressourcentyp zu erstellen, der dann auf unterstützten Geräten über glEGLImageTargetTexture2DOES
an eine Textur gebunden werden kann. Dies kann nützlich sein, um Texturen zu erstellen, die übergreifend verarbeitet werden können.
Mit der nativen Hardwarepuffer-JNI API (<android/hardware_buffer_jni.h>
) können Sie ein HardwareBuffer
-Objekt abrufen, das ein Parcelable ist und somit zwischen zwei verschiedenen Prozessen übertragen werden kann. Ihre App hat damit ähnliche Möglichkeiten wie SurfaceFlinger. Sie können beispielsweise eine eigene Warteschlange von Puffern zwischen Prozessen erstellen, ohne auf interne Android APIs zuzugreifen.
Audio
A-Audio
AAudio ist die derzeit unterstützte native Audio API. Er ersetzte OpenSL ES und bietet eine bessere Unterstützung für leistungsstarke Audioanwendungen, die Audiodaten mit niedriger Latenz erfordern.
Verfügbar seit API-Level 26.
Bibliothek: libaaudio
Leitfaden: AAudio API-Leitfaden
Referenz: AAudio API-Referenz
OpenSL Spanien
OpenSL ES ist eine weitere native Audio-API, die ebenfalls unterstützt wird. Weitere Informationen dazu finden Sie im Hinweis in der Anleitung unten.
Verfügbar seit API-Level 9. Mit API-Level 14 wurde PCM-Unterstützung hinzugefügt.
Bibliothek: libOpenSLES
Leitfaden: Leitfaden zu OpenSL ES für Android
API für neuronale Netzwerke
Die Neural Networks API (NNAPI) bietet Anwendungen mit Hardwarebeschleunigung für ML-Vorgänge auf dem Gerät. Die API unterstützt das Erstellen, Kompilieren und Ausführen von Modellen auf dem Gerät. NNAPI wird in der Regel nicht direkt von Anwendungen verwendet. Stattdessen wird die API von Bibliotheken, Frameworks und Tools für maschinelles Lernen aufgerufen, mit denen Entwickler ihre Modelle trainieren und auf Android-Geräten bereitstellen können.
Verfügbar seit API-Level 27.
Bibliothek: libneuralnetworks
Leitfaden: Leitfaden für neuronale Netzwerke
Referenz: Referenz der Neural Networks API