Na tej stronie znajdziesz przegląd bibliotek zawartych w NDK, a także linki do odpowiednich części dokumentacji interfejsu NDK API oraz do przewodników (jeśli istnieją).
Korzystanie z natywnych interfejsów API
Aby korzystać z biblioteki udostępnianej przez NDK, wykonaj 2 kroki:
Poinformuj system kompilacji o należytości od biblioteki.
Jeśli używasz ndk-build: dodaj bibliotekę do
LOCAL_LDLIBS
w pliku Android.mk. Pamiętaj, że usuwasz wiodący znaklib
i zamiast tego mówisz-l
. Aby na przykład utworzyć link dolibfoo
ilibbar
, wpisz:makefile LOCAL_LDLIBS := -lfoo -lbar
Więcej informacji o
LOCAL_LDLIBS
znajdziesz w dokumentacji Android.mk.Jeśli używasz CMake: wykonaj instrukcje w dokumentacji Studio dotyczącej dodawania interfejsów NDK API.
#include
odpowiednie nagłówki z kodu.
Pamiętaj, że interfejsy API, które są nowsze niż interfejs minSdkVersion
Twojej aplikacji, nie będą wywoływane domyślnie. Zamiast tego musisz używać ich za pomocą interfejsów dlopen()
i dlsym()
.
Aby ułatwić sobie pracę, przeczytaj artykuł Korzystanie z nowszych interfejsów API.
Podstawy C/C++
Biblioteka C
Standardowe nagłówki biblioteki C11, takie jak <stdlib.h>
i <stdio.h>
, są dostępne jak zwykle.
Pamiętaj, że w odróżnieniu od systemu Linux na Androidzie nie ma osobnych bibliotek libpthread
ani librt
. Ta funkcja jest zawarta bezpośrednio w libc
, więc nie trzeba jej wyraźnie łączyć.
Funkcja libm
jest oddzielna (zgodnie ze zwyczajową tradycją Unixa), ale podobnie jak libc
jest automatycznie powiązana przez systemy kompilacji.
Funkcje dynamicznego linkera w <dlfcn.h>
, takie jak dlopen(3) i dlsym(3), są dostępne, ale musisz wyraźnie połączyć się z libdl
.
Biblioteka: libc
/ libm
/ libdl
Biblioteka C++
Dostępna jest obsługa C++17. Więcej informacji o obsługiwanych bibliotekach C++ znajdziesz w artykule Obsługiwane biblioteki C++.
Logowanie
<android/log.h>
zawiera interfejsy API do rejestrowania w logcat.
Dostępne od poziomu API 3.
Biblioteka: liblog
Materiał referencyjny: Logowanie
Śledzenie
Natywna usługa ś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ń śledzonych w buforze śledczym systemu. Następnie możesz zbierać i analizować zdarzenia śladu za pomocą narzędzia Systrace.
Dostępne od poziomu API 23.
Biblioteka: libandroid
Przewodnik: śledzenie natywane
kompresja zlib
Możesz użyć biblioteki do kompresji Zlib, podając <zlib.h>
i linkując do libz
.
NDK zawsze zawiera najnowsze pliki nagłówka zlib w momencie wydania, a libz.a
zawarte w NDK na potrzeby statycznego linkowania to zawsze ta sama wersja, ale libz.so
na potrzeby dynamicznego linkowania pochodzi z urządzenia i jest to wersja, która została wydana na tym urządzeniu. W szczególności oznacza to, że nagłówki utworzone przez Ciebie nie pasują do wersji zlib na urządzeniu, więc w tym przypadku szczególnie ważne są ostrzeżenia dotyczące tworzenia założeń na temat szczegółów implementacji. Nie wiemy o żadnych problemach z publicznym interfejsem API, ale układ struktury zmienił się z czasem i prawdopodobnie będzie się zmieniał. Pamiętaj, że nowe interfejsy API w późniejszych wersjach zlib nie będą dostępne w wersjach systemu operacyjnego, które powstały przed tymi interfejsami. Można uniknąć wszystkich tych problemów (za cenę zwiększenia rozmiaru pliku APK), zawsze używając statycznej wartości libz.a
zamiast libz.so
.
Dostępna od poziomu API 3 (patrz jednak uwaga 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 swój natywny moduł z libGLESv1_CM
.
Aby używać OpenGL ES 2.0, połącz swój natywny moduł z elementem libGLESv2
.
Aby używać OpenGL ES 3.x, połącz swój natywny moduł z libGLESv3
.
Wszystkie urządzenia z Androidem obsługują OpenGL ES 1.0 i 2.0.
Nowsze wersje OpenGL ES są w pełni obsługiwane tylko na urządzeniach z Androidem, które mają odpowiedni procesor graficzny. Biblioteki są jednak dostępne na wszystkich urządzeniach, które obsługują poziom interfejsu API, w którym zostały wprowadzone. Łączenie z tymi bibliotekami jest bezpieczne, ale aplikacja musi zapytać o ciąg znaków wersji OpenGL ES i ciąg znaków rozszerzenia, aby ustalić, czy bieżące urządzenie obsługuje potrzebne funkcje. Informacje o sposobie wykonania tego zapytania znajdziesz w opisie funkcji glGetString()
w specyfikacji OpenGL.
Dodatkowo w pliku manifestu musisz umieścić tag <uses-feature>
, aby wskazać wymaganą wersję OpenGL ES.
Interfejs OpenGL ES 1.0 jest dostępny od poziomu API 4.
OpenGL ES 2.0 jest dostępny od poziomu interfejsu API 5.
OpenGL ES 3.0 jest dostępny od poziomu interfejsu API 18.
OpenGL ES 3.1 jest dostępny od poziomu API 21.
OpenGL ES 3.2 jest dostępny od poziomu API 24.
EGL
EGL udostępnia natywny interfejs platformy za pomocą nagłówków <EGL/egl.h>
i <EGL/eglext.h>
, które służą do przydzielania kontekstów i powierzchni OpenGL ES oraz do zarządzania nimi.
EGL umożliwia wykonywanie tych operacji z poziomu kodu natywnego:
- Lista obsługiwanych konfiguracji EGL.
- Przydzielanie i zwalnianie powierzchni OpenGL ES.
- Tworzenie i usuwanie kontekstów OpenGL ES.
- Zamieniać lub odwracać powierzchnie.
W poziomie API 24 dodano obsługę rozszerzeń 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: interfejs EGL Native Platform
Vulkan
Vulkan to interfejs API o niskim obciążeniu, który umożliwia wydajne renderowanie grafiki 3D na różnych platformach. Vulkan to otwarty standard obsługiwany przez Khronos Group. Standardowy plik nagłówka <vulkan/vulkan.h>
zawiera deklaracje potrzebne do wykonywania wywołań renderowania Vulkan z Twojego kodu.
Przykłady kodu znajdziesz w projektach VulkanSamples i android-vulkan-tutorials w GitHub.
Biblioteka Vulkan jest dostępna na wszystkich urządzeniach obsługujących interfejs API w wersji 24 lub nowszej, ale aplikacje muszą sprawdzać w czasie wykonywania, czy jest dostępna niezbędna obsługa sprzętowa GPU. Urządzenia bez obsługi Vulkana zwrócą 0 urządzeń z vkEnumeratePhysicalDevices
.
Dostępny od poziomu 24 interfejsu API.
Biblioteka: libvulkan
Przewodnik: przewodnik po interfejsie Vulkan Graphics API
Bitmapy
Biblioteka libjnigraphics
udostępnia interfejs API, który umożliwia dostęp do buforów pikseli obiektów Bitmap
w języku Java. Proces wygląda tak:
Wywołaj funkcję
AndroidBitmap_getInfo()
, aby pobrać informacje o danym identyfikatorze bitmapy, takie jak szerokość i wysokość.Wywołanie
AndroidBitmap_lockPixels()
służy do zablokowania bufora pikseli i odczytania wskaźnika do niego. Dzięki temu piksele nie będą się przemieszczać, dopóki aplikacja nie wywoła funkcjiAndroidBitmap_unlockPixels()
.Zmień bufor pikseli zgodnie z formatem pikseli, szerokością i innymi właściwościami.
Zadzwoń pod numer
AndroidBitmap_unlockPixels()
, aby odblokować bufor.
Dostępne od poziomu API 8.
Biblioteka: libjnigraphics
Dokumentacja: Dokumentacja interfejsu Bitmap API
Sync API
Dostępny od poziomu API 26.
Biblioteka: libsync
Dokumentacja: Dokumentacja interfejsu API Sync
Aparat
Natywna biblioteka interfejsów API aparatu umożliwia szczegółowe przechwytywanie i przetwarzanie zdjęć. W przeciwieństwie do interfejsu API camera2 w Javie natywny interfejs API aparatu nie obsługuje starszych implementacji interfejsu camera HAL 1.0 (czyli lista dostępnych aparatów w natywnym interfejsie API aparatu nie będzie zawierać urządzeń z starszym poziomem sprzętowym).
Dostępny od poziomu 24 interfejsu API.
Biblioteka: libcamera2ndk
Dokumentacja: Dokumentacja interfejsu Camera API
Multimedia
libmediandk
Interfejsy Media API udostępniają natywne interfejsy niskiego poziomu podobne do MediaExtractor
,
MediaCodec
i innych powiązanych interfejsów API w języku Java.
Biblioteka: libmediandk
Dokumentacja: Media API – dokumentacja
OpenMAX AL
Obsługa multimediów natywnej aplikacji na Androida opiera się na interfejsie API Khronos Group OpenMAX AL 1.0.1.
Standardowe nagłówki OpenMAX AL <OMXAL/OpenMAXAL.h>
i <OMXAL/OpenMAXAL_Platform.h>
zawierają deklaracje niezbędne do wykonania multimedialnego wyjścia z natywnej strony Androida.
Wersja NDK OpenMAX AL zawiera też rozszerzenia przeznaczone do Androida.
Informacje o tych rozszerzeniach znajdziesz w komentarzach w dokumentacji <OMXAL/OpenMAXAL_Android.h>
.
Dostępne od poziomu API 14.
Biblioteka: libOpenMAXAL
Interfejsy API aplikacji natywnych na Androida
Więcej informacji znajdziesz w dokumentacji interfejsu NDK API na Androida.
Interfejsy API:
- Zasób
- Choreograf
- Konfiguracja
- Wejście
- Looper
- Aktywność natywnych użytkowników
- Natywna pamięć podręczna
- Okno natywne
- Pamięć
- Networking
- Czujnik
- Miejsce na dane
- SurfaceTexture
Biblioteka: libandroid
Biblioteka: libnativewindow
, aby korzystać z najnowszych funkcji okna natywnego
Pełna dokumentacja: Dokumentacja interfejsu API Androida NDK
Interfejsy Binder API
Interfejsy Binder API umożliwiają tworzenie kanałów komunikacji między procesami. Jest to implementacja na niskim poziomie komunikacji między procesami na Androidzie. Jeśli to możliwe, używaj komponentów wyższego poziomu. Biblioteka ta jest jednak dostępna w zaawansowanych przypadkach użycia.
Biblioteka: libbinder_ndk
Odniesienie: Binder
Interfejsy API bufora sprzętowego
Dostępne są 2 rodzaje natywnych interfejsów API, które umożliwiają tworzenie własnych ścieżek do zarządzania buforem między procesami.
Natywna pamięć podręczna sprzętowa API
<android/hardware_buffer.h>
pozwala bezpośrednio przydzielać pamięci podręczne, aby tworzyć własne potoki do zarządzania pamięcią podręczną w ramach procesów.
Możesz przydzielić AHardwareBuffer
i użyć go do uzyskania typu zasobu EGLClientBuffer
za pomocą rozszerzenia eglGetNativeClientBufferANDROID
. Możesz przekazać ten bufor do eglCreateImageKHR
, aby utworzyć typ zasobu EGLImage
, który następnie można powiązać z teksturą za pomocą glEGLImageTargetTexture2DOES
na obsługiwanych urządzeniach. Może to być przydatne podczas tworzenia tekstur, które mogą być współdzielone w ramach procesów.
Natywna pamięć masowa sprzętowa interfejsu JNI API (<android/hardware_buffer_jni.h>
) umożliwia uzyskanie obiektu HardwareBuffer
, który jest Parcelable i może być przesyłany między 2 różnymi procesami. Dzięki temu aplikacja ma podobne możliwości do SurfaceFlinger, np. tworzenie własnej kolejki buforów między procesami bez dostępu do wewnętrznych interfejsów API Androida.
Audio
AAudio
AAudio to obecnie obsługiwany natywny interfejs API do obsługi dźwięku. Zastąpiło ono OpenSL ES i zapewnia lepszą obsługę wydajnych aplikacji audio, które wymagają dźwięku o małej latencji.
Dostępne od poziomu API 26.
Biblioteka: libaaudio
Przewodnik: przewodnik po interfejsie AAudio API
Dokumentacja: dokumentacja interfejsu AAudio API
OpenSL ES
OpenSL ES to kolejny natywny interfejs API do obsługi dźwięku, który jest również obsługiwany.
Dostępne od poziomu API 9. W poziomie API 14 dodano obsługę PCM.
Biblioteka: libOpenSLES
Przewodnik: OpenSL ES na Androida
Neural Networks API
Interfejs Neural Networks API (NNAPI) zapewnia aplikacjom akcelerację sprzętową operacji systemów 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, frameworki i narzędzia uczenia maszynowego, które umożliwiają deweloperom trenowanie modeli i ich wdrażanie na urządzeniach z Androidem.
Dostępny od poziomu API 27.
Biblioteka: libneuralnetworks
Przewodnik: Przewodnik po sieciach neuronowych
Dokumentacja: Dokumentacja interfejsu API sieci neuronowych