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 vorhanden.

Native APIs verwenden

Für die Verwendung einer vom NDK bereitgestellten Bibliothek sind zwei Schritte erforderlich:

  1. Weisen Sie das Build-System an, die Bibliothek zu verknüpfen.

    • Wenn Sie ndk-build verwenden: Fügen Sie die Bibliothek in Ihrem Android.mk zu LOCAL_LDLIBS hinzu. Beachten Sie, dass Sie das führende lib entfernen und stattdessen -l sagen. Wenn Sie beispielsweise libfoo und libbar verlinken möchten, schreiben Sie: 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 unter NDK-APIs hinzufügen.

  2. #include die entsprechenden Headern aus Ihrem Code.

APIs, die neuer als das minSdkVersion Ihrer Anwendung 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.

Core C/C++

C-Bibliothek

Die Standard-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, sodass keine explizite Verknüpfung erforderlich ist.

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

Die Funktionen des dynamischen Linkers in <dlfcn.h> wie dlopen(3) und dlsym(3) sind verfügbar, aber Sie müssen explizit gegen libdl linken.

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 ab API-Level 3.

Mediathek: 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 nachverfolgen, 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 ab API-Level 23.

Mediathek: libandroid

Leitfaden: Native Tracing

zlib-Komprimierung

Sie können die Zlib-Komprimierungsbibliothek verwenden, indem Sie <zlib.h> einfügen und gegen libz verlinken.

Das NDK enthält zum Zeitpunkt der Veröffentlichung immer die neuesten zlib-Headerdateien. 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 kann eine beliebige Version sein, die auf diesem Gerät veröffentlicht wurde. Das bedeutet insbesondere, dass die Header, die Sie verwendet haben, nicht mit der Version von zlib auf dem Gerät übereinstimmen. Die üblichen Warnungen, keine Annahmen über Implementierungsdetails zu treffen, sind hier also besonders wichtig. Uns sind keine Probleme mit der öffentlichen API bekannt, aber insbesondere das Struktur-Layout hat sich im Laufe der Zeit geändert und wird sich wahrscheinlich auch weiterhin ändern. Beachten Sie, dass neue APIs in späteren zlib-Versionen natürlich nicht in Betriebssystemversionen verfügbar sind, die vor der API veröffentlicht wurden. Alle diese Probleme lassen sich vermeiden, wenn Sie immer die statische libz.a anstelle von libz.so verwenden. Das führt jedoch zu einer größeren APK-Datei.

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

Mediathek: 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>) sowie 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.

Nur Android-Geräte mit der erforderlichen GPU unterstützen neuere Versionen von OpenGL ES vollständig. Die Bibliotheken sind jedoch auf allen Geräten vorhanden, die das API-Level unterstützen, auf dem sie eingeführt wurden. Es ist sicher, die Bibliotheken zu verlinken. Eine App muss jedoch den OpenGL ES-Versionsstring und den 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 in Ihrer Manifestdatei ein <uses-feature>-Tag 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 ab API-Level 21 verfügbar.

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

EGL

EGL bietet über die Header <EGL/egl.h> und <EGL/eglext.h> eine native Plattform-Schnittstelle 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 zuweisen und freigeben.
  • OpenGL ES-Kontexte erstellen und zerstören
  • Oberflächen tauschen oder spiegeln

Mit API-Level 24 wurde 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 ab API-Level 9.

Mediathek: libEGL

Leitfaden: EGL Native Platform Interface

Vulkan

Vulkan ist eine plattformübergreifende API mit geringem Aufwand für das Rendern von leistungsstarken 3D-Grafiken. Vulkan ist ein offener Standard, der von der Khronos Group verwaltet wird. Die Standardheaderdatei <vulkan/vulkan.h> enthält die Deklarationen, die zum Ausführen von Vulkan-Rendering-Aufrufen aus Ihrem Code erforderlich sind.

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

Die Vulkan-Bibliothek ist auf allen Geräten mit API-Level 24 oder höher vorhanden. Apps müssen jedoch zur Laufzeit prüfen, ob die erforderliche GPU-Hardwareunterstützung verfügbar ist. Bei Geräten ohne Vulkan-Unterstützung wird bei vkEnumeratePhysicalDevices „0“ zurückgegeben.

Verfügbar ab API-Level 24.

Mediathek: libvulkan

Leitfaden: Vulkan-Leitfaden zur Grafik-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 für ein bestimmtes Bitmap-Handle abzurufen.

  2. Rufen Sie AndroidBitmap_lockPixels() auf, um den Pixelpuffer zu sperren und einen Zeiger darauf abzurufen. So wird dafür gesorgt, dass sich die Pixel erst bewegen, wenn die App AndroidBitmap_unlockPixels() aufruft.

  3. Ändern Sie den Pixelpuffer entsprechend seinem Pixelformat, seiner Breite und anderen Merkmalen.

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

Verfügbar seit API-Level 8.

Mediathek: libjnigraphics

Referenz: Bitmap API-Referenz

Sync API

Verfügbar ab API-Level 26.

Mediathek: libsync

Referenz: Sync API-Referenz

Kamera

Die nativen Kamera-APIs ermöglichen eine detaillierte Fotoaufnahme und ‑verarbeitung. Im Gegensatz zur Java Camera2 API werden in der nativen Kamera-API keine eingestellten Camera HAL 1.0-Implementierungen unterstützt. Das bedeutet, dass in der Liste der verfügbaren Kameras in der nativen Kamera-API keine Kamerageräte mit dem Hardware-Level LEGACY aufgeführt werden.

Verfügbar ab API-Level 24.

Mediathek: libcamera2ndk

Referenz: Camera API-Referenz

Medien

libmediandk

Die Media APIs bieten native Schnittstellen auf niedriger Ebene, die MediaExtractor, MediaCodec und anderen zugehörigen Java APIs ähneln.

Mediathek: libmediandk

Referenz: Media API-Referenz

OpenMAX AL

Die systemeigene Android-Multimedia-Verarbeitung 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 Multimedia-Ausgabe von der nativen Seite von Android aus erforderlich sind.

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

Verfügbar ab API-Level 14.

Mediathek: libOpenMAXAL

APIs für native Android-Anwendungen

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

Dazu gehören:

Mediathek: libandroid

Mediathek: libnativewindow für neuere Native Window-Funktionen

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 Android-Prozesskommunikation. Verwenden Sie nach Möglichkeit Komponenten auf höherer Ebene. Diese Bibliothek ist jedoch für erweiterte Anwendungsfälle verfügbar.

Mediathek: 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 Hardwarepuffer-API <android/hardware_buffer.h> können Sie Puffer direkt zuweisen, um eigene Pipelines für die prozessübergreifende Pufferverwaltung zu erstellen. Sie können ein AHardwareBuffer zuweisen und damit über die eglGetNativeClientBufferANDROID-Erweiterung den Ressourcentyp EGLClientBuffer 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. Dies kann nützlich sein, um Texturen zu erstellen, die prozessübergreifend freigegeben 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 daher zwischen zwei verschiedenen Prozessen übertragen werden kann. Dadurch erhält Ihre App ähnliche Funktionen wie SurfaceFlinger, z. B. die Möglichkeit, eine eigene Warteschlange von Puffern zwischen Prozessen zu erstellen, ohne auf interne Android-APIs zuzugreifen.

Audio

AAudio

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

Verfügbar ab API-Level 26.

Mediathek: libaaudio

Anleitung: 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 im Leitfaden unten.

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

Mediathek: 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 die Erstellung, Kompilierung und Ausführung von On-Device-Modellen. Apps verwenden NNAPI in der Regel nicht direkt. Stattdessen soll die API von Machine-Learning-Bibliotheken, ‑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.

Mediathek: libneuralnetworks

Leitfaden: Leitfaden für neuronale Netzwerke

Referenz: Neural Networks API-Referenz