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:
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ątkowelib
i widzisz-l
. Aby na przykład utworzyć link do witrynlibfoo
ilibbar
, 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.
#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:
Wywołaj
AndroidBitmap_getInfo()
, aby pobrać informacje dotyczące danego uchwytu mapy bitowej, takie jak szerokość i wysokość.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 funkcjiAndroidBitmap_unlockPixels()
.Zmień bufor pikseli według formatu, szerokości i innych parametrów.
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ą:
- Zasób
- Choreograf
- Konfiguracja
- Wejście
- Pętla danych
- Aktywność związana z ruchem natywnym
- Natywne bufory sprzętowe
- Natywne okno
- Pamięć
- Sieć
- Czujnik
- Miejsce na dane
- Tekst powierzchni
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