Native APIs

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:

  1. 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 vorangestellte lib und sagen stattdessen -l. Um beispielsweise eine Verknüpfung mit libfoo und libbar 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.

  2. #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:

  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 Pixelzwischenspeicher zu sperren und einen Zeiger darauf abzurufen. Dadurch wird sichergestellt, dass sich die Pixel erst verschieben, wenn die App AndroidBitmap_unlockPixels() aufruft.

  3. Passen Sie den Pixelzwischenspeicher entsprechend dem Pixelformat, der 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

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:

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