Natywne interfejsy API

Ta strona zawiera przegląd bibliotek uwzględnionych w NDK, wraz z linkami do odpowiednich części dokumentacji API NDK, a także do przewodników, gdzie one istnieją.

Korzystanie z natywnych interfejsów API

Aby korzystać z biblioteki udostępnianej przez NDK, trzeba wykonać 2 kroki:

  1. Poleć systemowi kompilacji, aby połączyć go z biblioteką.

    • Jeśli używasz ndk-build: dodaj bibliotekę do LOCAL_LDLIBS w Android.mk. Pamiętaj, że usuwasz początkowe lib i widzisz -l. Aby na przykład utworzyć link do witryn libfoo i libbar, wpisz: makefile LOCAL_LDLIBS := -lfoo -lbar

      Więcej informacji na temat LOCAL_LDLIBS znajdziesz w dokumentacji Android.mk.

    • Jeśli używasz CMake: postępuj zgodnie z instrukcjami w dokumentacji Dodaj interfejsy NDK API w Studio.

  2. #include wybierz odpowiednie nagłówki w kodzie.

Pamiętaj, że interfejsy API nowsze niż minSdkVersion aplikacji nie będą domyślnie wywoływane. Należy ich używać w dlopen() i dlsym(). Aby ułatwić sobie zadanie, przeczytaj artykuł Korzystanie z nowszych interfejsów API.

Core C/C++

Biblioteka C

Standardowe nagłówki biblioteki C11, takie jak <stdlib.h> i <stdio.h>, są dostępne w zwykły sposób.

Pamiętaj, że w przeciwieństwie do Linuksa na Androidzie nie ma osobnych bibliotek libpthread ani librt. Ta funkcja jest dostępna bezpośrednio w libc, z którym nie trzeba łączyć się bezpośrednio.

Dla funkcji matematycznych jest dostępny osobny element libm (zgodnie ze zwykłą tradycją Unix), ale tak jak w przypadku libc jest on automatycznie połączony przez systemy kompilacji.

Funkcje dynamicznego tagu łączącego w <dlfcn.h>, takie jak dlopen(3) i dlsym(3), są dostępne, ale należy jednoznacznie połączyć je z zasadą libdl.

Biblioteka: libc / libm / libdl

Biblioteka C++

Dostępna jest obsługa języka C++17. Więcej informacji o obsłudze bibliotek C++ znajdziesz w artykule o obsłudze bibliotek C++.

Logowanie

<android/log.h> zawiera interfejsy API do logowania w logcat.

Dostępne od poziomu 3 interfejsu API.

Biblioteka: liblog

Materiały dodatkowe: Logowanie

Śledzenie

Natywny interfejs API śledzenia <android/trace.h> zapewnia natywny odpowiednik klasy android.os.Trace w języku programowania Java. Ten interfejs API umożliwia śledzenie nazwanych jednostek pracy w kodzie przez zapisywanie zdarzeń śledzenia w buforze śledzenia systemu. Zdarzenia śledzenia będzie można zbierać i analizować za pomocą narzędzia Systrace.

Dostępne od poziomu interfejsu API 23.

Biblioteka: libandroid

Przewodnik: Śledzenie natywne

kompresja zlib

Możesz użyć biblioteki kompresji Zlib, dodając <zlib.h> i łącząc z libz.

NDK zawsze zawiera najnowsze pliki nagłówkowe zlib w chwili premiery, a libz.a w pliku NDK służącym do łączenia statycznych to zawsze ta sama wersja, ale libz.so (na potrzeby linków dynamicznych) pochodzi z urządzenia i niezależnie od tego, jaka wersja została wydana na danym urządzeniu. W szczególności oznacza to, że nagłówki tworzone na podstawie kompilacji nie są zgodne z wersją zlib na urządzeniu, więc szczególnie ważne są tu typowe ostrzeżenia przed przyjmowaniem założeń dotyczących szczegółów implementacji. Nie wiemy o żadnych problemach z publicznymi interfejsami API, ale w szczególności układ struct zmieniał się z czasem i prawdopodobnie tak się nie zmieni. Pamiętaj, że nowe interfejsy API w późniejszych wersjach zlib oczywiście nie będą dostępne w wersjach systemu operacyjnego starszych niż API. Można uniknąć wszystkich tych problemów (kosztem zwiększonego rozmiaru pliku APK) można zawsze uniknąć, używając statycznego parametru libz.a zamiast libz.so.

Dostępne od poziomu 3 interfejsu API (zobacz uwagę powyżej).

Biblioteka: libz

Grafika

OpenGL ES 1.0–3.2

Standardowe nagłówki OpenGL ES 1.x (<GLES/gl.h> i <GLES/glext.h>), nagłówki 2.0 (<GLES2/gl2.h> i <GLES2/gl2ext.h>), nagłówki 3.0 (<GLES3/gl3.h> i <GLES3/gl3ext.h>), nagłówki 3.1 (<GLES3/gl31.h> i <GLES3/gl3ext.h>) oraz nagłówki 3.2 (<GLES3/gl32.h> i <GLES3/gl3ext.h>) zawierają deklaracje niezbędne dla OpenGL ES.

Aby używać OpenGL ES 1.x, połącz moduł natywny z funkcją libGLESv1_CM.

Aby używać OpenGL ES 2.0, połącz moduł natywny z funkcją libGLESv2.

Aby używać OpenGL ES 3.x, połącz moduł natywny z funkcją libGLESv3.

Wszystkie urządzenia z Androidem obsługują standard OpenGL ES 1.0 i 2.0.

Tylko urządzenia z Androidem, które mają niezbędny układ GPU, w pełni obsługują późniejsze wersje OpenGL ES. Te biblioteki są jednak dostępne na wszystkich urządzeniach obsługujących poziom API, na którym zostały wprowadzone. Linki można bezpiecznie łączyć z bibliotekami, ale aplikacja musi wysyłać zapytania o ciąg znaków wersji OpenGL ES i ciąg rozszerzenia, aby określić, czy bieżące urządzenie obsługuje funkcje, których potrzebuje. Aby dowiedzieć się, jak wykonać to zapytanie, zapoznaj się z opisem obiektu glGetString() w specyfikacji OpenGL.

Dodatkowo musisz umieścić w pliku manifestu tag <uses-feature>, aby wskazać potrzebną wersję OpenGL ES.

Interfejs OpenGL ES 1.0 jest dostępny od poziomu API 4.

Interfejs OpenGL ES 2.0 jest dostępny od poziomu API 5.

Interfejs OpenGL ES 3.0 jest dostępny od poziomu API 18.

Interfejs OpenGL ES 3.1 jest dostępny od poziomu API 21.

Interfejs OpenGL ES 3.2 jest dostępny od poziomu API 24.

EGL

EGL zapewnia natywny interfejs platformy za pomocą nagłówków <EGL/egl.h> i <EGL/eglext.h> do przydzielania kontekstów i płaszczyzn OpenGL ES oraz zarządzania nimi.

EGL umożliwia wykonywanie tych operacji na kodzie natywnym:

  • Wyświetl listę obsługiwanych konfiguracji EGL.
  • Przydziel i zwolnij platformy OpenGL ES.
  • Tworzenie i niszczenie kontekstów OpenGL ES.
  • Zamień lub odwróć powierzchnie.

Interfejs API na poziomie 24 obsługuje rozszerzenia EGL_KHR_mutable_render_buffer, ANDROID_create_native_client_buffer i ANDROID_front_buffer_auto_refresh.

Dostępne od poziomu API 9.

Biblioteka: libEGL

Przewodnik: EGL Native Platform Interface

Wulkan

Vulkan to wieloplatformowy interfejs API niskobudżetowy do wysokiej wydajności renderowania grafiki 3D. Vulkan to otwarty standard utrzymywany przez grupę Khronos Group. Standardowy plik nagłówka <vulkan/vulkan.h> zawiera deklaracje potrzebne do wykonywania wywołań interfejsu Vulkan w Twoim kodzie.

Przykładowe fragmenty kodu znajdziesz w projektach LunarG VulkanSamples i android-vulkan-tutorials na GitHubie.

Biblioteka Vulkan jest dostępna na wszystkich urządzeniach obsługujących interfejs API na poziomie 24 lub nowszym, ale aplikacje muszą w czasie działania sprawdzać, czy dostępna jest niezbędna obsługa sprzętu GPU. Urządzenia bez obsługi interfejsu Vulkan nie zwrócą żadnych urządzeń z vkEnumeratePhysicalDevices.

Dostępne od poziomu 24 interfejsu API.

Biblioteka: libvulkan

Przewodnik: przewodnik po interfejsie VulkanGraphic API

Bitmapy

Biblioteka libjnigraphics udostępnia interfejs API, który umożliwia dostęp do buforów pikseli obiektów Bitmap w Javie. Przepływ pracy wygląda tak:

  1. Wywołaj AndroidBitmap_getInfo(), aby pobrać informacje dotyczące danego uchwytu mapy bitowej, takie jak szerokość i wysokość.

  2. Wywołaj AndroidBitmap_lockPixels(), by zablokować bufor pikseli i pobrać do niego wskaźnik. Dzięki temu piksele nie będą przesuwane, dopóki aplikacja nie wywoła funkcji AndroidBitmap_unlockPixels().

  3. Zmień bufor pikseli według formatu, szerokości i innych parametrów.

  4. Zadzwoń pod numer AndroidBitmap_unlockPixels(), by odblokować bufor.

Dostępne od poziomu API 8.

Biblioteka: libjnigraphics

Materiały dodatkowe: dokumentacja interfejsu Bitmap API.

Interfejs API synchronizacji

Dostępne od poziomu interfejsu API 26.

Biblioteka: libsync

Materiały dodatkowe: Dokumentacja API synchronizacji

Aparat

Natywne interfejsy API aparatu wykonują szczegółowe zdjęcia i przetwarzają je. W przeciwieństwie do interfejsu Java Camera2 API interfejs natywny Camera API nie obsługuje wycofanych implementacji HAL 1.0 kamery (oznacza to, że lista dostępnych kamer w natywnym interfejsie Camera API nie zawiera listy urządzeń z poziomem sprzętowym LEGACY).

Dostępne od poziomu 24 interfejsu API.

Biblioteka: libcamera2ndk

Materiały dodatkowe: Dokumentacja interfejsu Camera API

Multimedia

Libmediandk

Media API zapewniają niskopoziomowe, natywne interfejsy podobne do MediaExtractor, MediaCodec i innych powiązanych interfejsów API w języku Java.

Biblioteka: libmediandk

Materiały dodatkowe: dokumentacja interfejsu Media API.

OpenMAX, Alabama

Natywna obsługa multimediów na Androidzie opiera się na interfejsie API Khronos Group OpenMAX AL 1.0.1.

Standardowe nagłówki AL OpenMAX <OMXAL/OpenMAXAL.h> i <OMXAL/OpenMAXAL_Platform.h> zawierają deklaracje niezbędne do obsługi danych wyjściowych multimedialnych z natywnej strony Androida.

W dystrybucji NDK OpenMAX AL dostępne są też rozszerzenia przeznaczone dla Androida. Informacje o tych rozszerzeniach znajdziesz w komentarzach na stronie <OMXAL/OpenMAXAL_Android.h>.

Dostępne od poziomu API 14.

Biblioteka: libOpenMAXAL

Interfejsy API natywnych aplikacji na Androida

Więcej informacji znajdziesz w dokumentacji interfejsu Android NDK API.

Interfejsy API obejmują:

Biblioteka: libandroid

Biblioteka: libnativewindow na potrzeby nowszych funkcji okna natywnego

Pełne materiały: dokumentacja interfejsu Android NDK API.

Interfejsy API buforów sprzętowych

Istnieją 2 natywne interfejsy API, które umożliwiają tworzenie własnych potoków do zarządzania buforem między procesami.

Natywny interfejs API bufora sprzętu <android/hardware_buffer.h> umożliwia bezpośrednie przydzielanie buforów w celu tworzenia własnych potoków do zarządzania buforami między procesami. Możesz przydzielić AHardwareBuffer i użyć go, aby uzyskać typ zasobu EGLClientBuffer za pomocą rozszerzenia eglGetNativeClientBufferANDROID. Możesz przekazać ten bufor do eglCreateImageKHR, aby utworzyć typ zasobu EGLImage, który następnie może być powiązany z teksturą przez glEGLImageTargetTexture2DOES na obsługiwanych urządzeniach. Jest to przydatne przy tworzeniu tekstur, które można współdzielić między procesami.

Natywny interfejs JNI API (<android/hardware_buffer_jni.h>) bufora sprzętowego umożliwia uzyskanie obiektu HardwareBuffer będącego obiektem typu Parcelable, który może być przenoszony między 2 różnymi procesami. Dzięki temu aplikacja ma uprawnienia podobne do aplikacji SurfaceFlinger, np. może tworzyć własną kolejkę buforów między procesami bez dostępu do wewnętrznych interfejsów API Androida.

Dźwięk

AAudio

AAudio to obecnie obsługiwany natywny interfejs API audio. Zastąpiły OpenSL ES i zapewniały lepszą obsługę wysokiej wydajności aplikacji audio, które wymagają dźwięku z małym opóźnieniem.

Dostępne od poziomu interfejsu API 26.

Biblioteka: libaaudio

Przewodnik: przewodnik po interfejsie AAudio API

Więcej informacji: dokumentacja interfejsu AAudio API.

OpenSL ES

OpenSL ES to kolejny natywny interfejs API audio, który również jest obsługiwany. Więcej informacji znajdziesz w poniższym przewodniku.

Dostępne od poziomu API 9. Interfejs API na poziomie 14 dodał obsługę PCM.

Biblioteka: libOpenSLES

Przewodnik: przewodnik po OpenSL ES na Androida

Neural Networks API

Neural Networks API (NNAPI) zapewnia aplikacjom akcelerację sprzętową podczas operacji na systemach uczących się na urządzeniu. Interfejs API obsługuje tworzenie, kompilację i wykonywanie modeli na urządzeniu. Aplikacje zwykle nie korzystają bezpośrednio z NNAPI. Zamiast tego interfejs API jest wywoływany przez biblioteki systemów uczących się, platformy i narzędzia umożliwiające programistom trenowanie modeli i wdrażanie ich na urządzeniach z Androidem.

Dostępne od poziomu interfejsu API 27.

Biblioteka: libneuralnetworks

Przewodnik: przewodnik po sieciach neuronowych

Materiały dodatkowe: Dokumentacja interfejsu Neural Networks API