Na tej stronie znajduje się przegląd bibliotek wchodzących w skład pakietu NDK, a także linki do odpowiednich części materiałów referencyjnych oraz przewodników, w których miejscach się one znajdują.
Korzystanie z natywnych interfejsów API
Aby korzystać z biblioteki udostępnianej w pakiecie NDK, trzeba wykonać 2 czynności:
Powiedz systemowi kompilacji, aby łączył się z biblioteką.
Jeśli używasz ndk-build, dodaj bibliotekę do
LOCAL_LDLIBS
w pliku Android.mk. Zwróć uwagę, że początkowy fragmentlib
jest usuwany i zamiast niego wypowiadasz-l
. Aby na przykład utworzyć połączenie z elementamilibfoo
ilibbar
, wpisz:makefile LOCAL_LDLIBS := -lfoo -lbar
Więcej informacji na temat
LOCAL_LDLIBS
znajdziesz w dokumentacji Androida.mk.Jeśli używasz CMake: postępuj zgodnie z instrukcjami w dokumentacji dodawania interfejsów NDK API w Studio.
#include
odpowiednie nagłówki w kodzie.
Podstawowe funkcje 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 przeciwieństwie do systemu Linux na Androidzie nie ma osobnych bibliotek libpthread
ani librt
. Ta funkcja jest dostępna bezpośrednio w usłudze libc
i nie trzeba jej wyraźnie łączyć.
Istnieje osobny element libm
na potrzeby funkcji matematycznych (zgodnie ze standardową tradycją uniksową), ale tak jak w przypadku libc
ta opcja jest automatycznie łączona przez systemy kompilacji.
Funkcje dynamicznego tagu łączącego w <dlfcn.h>
, takie jak dlopen(3) i dlsym(3), są dostępne, ale musisz wyraźnie ustawić połączenie z libdl
.
Biblioteka: libc
/ libm
/ libdl
Biblioteka C++
Dostępna jest obsługa C++17. Więcej informacji o obsłudze bibliotek C++ znajdziesz w artykule na temat obsługi bibliotek C++.
Logowanie
<android/log.h>
zawiera interfejsy API do logowania do logcat.
Dostępne od poziomu interfejsu API 3.
Biblioteka: liblog
Materiały referencyjne: Logging
Ś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ń logu czasu w systemowym buforze śledzenia. Następnie możesz zbierać i analizować zdarzenia śledzenia za pomocą narzędzia Systrace.
Dostępne od poziomu API 23.
Biblioteka: libandroid
Przewodnik: śledzenie natywne
kompresja zlib
Możesz użyć biblioteki kompresji Zlib, dodając <zlib.h>
i łącząc ją z libz
.
Pakiet NDK zawsze zawiera najnowsze pliki nagłówka zlib w momencie publikacji, a libz.a
w pakiecie NDK na potrzeby połączeń statycznych zawsze ma tę samą wersję. Natomiast wartość libz.so
w przypadku linków dynamicznych pochodzi z urządzenia i odpowiada dowolnej wersji, która została na nim opublikowana. W szczególności oznacza to, że nagłówki, które tworzysz, nie pasują do wersji zlib na urządzeniu, więc w tym przypadku szczególnie ważne są standardowe ostrzeżenia przed wyciąganiem założeń dotyczących szczegółów implementacji. Nie wiemy o żadnych problemach z publicznym interfejsem API, ale układ struktury struktury zmienia się z biegiem czasu i prawdopodobnie będzie się powtarzał. Pamiętaj, że nowy interfejs API w późniejszych wersjach zlib oczywiście nie będzie dostępny w wersjach systemu operacyjnego starszych niż API. Można uniknąć wszystkich tych problemów (kosztem większego rozmiaru pliku APK), stosując zawsze statyczną wartość libz.a
zamiast libz.so
.
Dostępne od poziomu 3 interfejsu API (patrz 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>
), 3.0 (<GLES3/gl3.h>
i <GLES3/gl3ext.h>
), 3.1 (<GLES3/gl31.h>
i <GLES3/gl3ext.h>
) oraz 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 libGLESv1_CM
.
Aby używać OpenGL ES 2.0, połącz moduł natywny z libGLESv2
.
Aby używać OpenGL ES 3.x, połącz moduł natywny z libGLESv3
.
Wszystkie urządzenia z Androidem obsługują OpenGL ES 1.0 i 2.0.
Tylko urządzenia z Androidem wyposażone w odpowiednie GPU w pełni obsługują nowsze wersje OpenGL ES, ale biblioteki te są dostępne na wszystkich urządzeniach obsługujących ten poziom interfejsu API, na którym zostały wprowadzone. Połączenie z bibliotekami jest bezpieczne, ale aplikacja musi wysłać zapytanie do ciągu znaków wersji OpenGL ES i ciągu rozszerzenia, aby określić, czy bieżące urządzenie obsługuje wymagane funkcje. Informacje o sposobie wykonywania tego zapytania znajdziesz w opisie obiektu glGetString()
w specyfikacji OpenGL.
Dodatkowo musisz umieścić w pliku manifestu tag <uses-feature>
wskazujący wymaganą wersję OpenGL ES.
Interfejs OpenGL ES 1.0 jest dostępny od poziomu interfejsu API 4.
Interfejs OpenGL ES 2.0 jest dostępny od poziomu interfejsu API 5.
Interfejs OpenGL ES 3.0 jest dostępny od poziomu interfejsu API 18.
Interfejs OpenGL ES 3.1 jest dostępny od poziomu interfejsu API 21.
Interfejs OpenGL ES 3.2 jest dostępny od poziomu interfejsu API 24.
EGL
EGL udostępnia natywny interfejs platformy za pomocą nagłówków <EGL/egl.h>
i <EGL/eglext.h>
do przydzielania kontekstów i przestrzeni 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.
- Zamienianie i odwracanie powierzchni.
Interfejs API na poziomie 24 dodał 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: EGL Native Platform Interface
Wulkan
Vulkan to wieloplatformowy interfejs API umożliwiający pracę nad wydajnym renderowaniem grafiki 3D. Vulkan to otwarty standard
prowadzony przez organizację Khronos Group. Standardowy plik nagłówka <vulkan/vulkan.h>
zawiera deklaracje wymagane do wykonywania z Twojego kodu wywołań renderowania z interfejsu Vulkan.
Przykładowy kod 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ętowa GPU. Urządzenia nieobsługujące interfejsu Vulkan nie zwracają żadnego urządzenia z systemu vkEnumeratePhysicalDevices
.
Dostępne od poziomu API 24.
Biblioteka: libvulkan
Przewodnik: przewodnik po interfejsie Vulkan Graphic API
Mapy bitowe
Biblioteka libjnigraphics
udostępnia interfejs API, który umożliwia dostęp do buforów pikseli obiektów Java Bitmap
. Przepływ pracy wygląda tak:
Wywołaj
AndroidBitmap_getInfo()
, aby pobrać informacje o danym uchwytie bitmapy, takie jak szerokość i wysokość.Wywołaj
AndroidBitmap_lockPixels()
, aby zablokować bufor piksela i pobrać do niego wskaźnik. Dzięki temu piksele nie będą się poruszać, dopóki aplikacja nie wywołaAndroidBitmap_unlockPixels()
.Zmodyfikuj bufor pikseli, aby dostosować go do jego formatu piksela, szerokości i innych właściwości.
Wywołaj
AndroidBitmap_unlockPixels()
, aby odblokować bufor.
Dostępne od poziomu interfejsu API 8.
Biblioteka: libjnigraphics
Dokumentacja: dokumentacja interfejsu Bitmap API.
Interfejs API synchronizacji
Dostępne od poziomu API 26.
Biblioteka: libsync
Dokumentacja: dokumentacja interfejsu Sync API
Aparat
Natywne interfejsy API aparatu umożliwiają dokładną robienie i przetwarzanie zdjęć. W przeciwieństwie do interfejsu Java Camera2 API natywny interfejs aparatu nie obsługuje wycofanych implementacji HAL 1.0 kamer (oznacza to, że lista dostępnych kamer w interfejsie API aparatu natywnego nie zawiera danych o aparatach na poziomie LEGACY).
Dostępne od poziomu API 24.
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: dokumentacja interfejsu Media API.
OpenMAX AL
Natywna obsługa multimediów na Androidzie jest oparta 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 obsługi danych wyjściowych multimedialnych po natywnej stronie Androida.
Dystrybucja OpenMAX AL w pakiecie NDK obejmuje też rozszerzenia przeznaczone na Androida.
Informacje o tych rozszerzeniach znajdziesz w komentarzach na stronie <OMXAL/OpenMAXAL_Android.h>
.
Dostępne od poziomu API 14.
Biblioteka: libOpenMAXAL
Natywne interfejsy API aplikacji na Androida
Więcej informacji znajdziesz w dokumentacji interfejsu Android NDK API.
Interfejsy API to:
- Zasób
- Choreograf
- Konfiguracja
- Wejście
- Zapętlacz
- Aktywność związana z reklamami natywnymi
- Natywne bufory sprzętu
- Okno natywne
- Pamięć
- Sieci
- Czujnik
- Miejsce na dane
- faktura powierzchni;
Biblioteka: libandroid
Biblioteka: libnativewindow
dla nowszych funkcji okien natywnych
Pełne materiały: dokumentacja interfejsu API Android NDK
Interfejsy API buforów sprzętowych
Istnieją 2 natywne interfejsy API umożliwiające tworzenie własnych potoków do zarządzania buforem między procesami.
Natywny interfejs API bufora sprzętowego <android/hardware_buffer.h>
umożliwia bezpośrednie przydzielanie buforów w celu utworzenia własnych potoków na potrzeby zarządzania buforem w różnych procesach.
Możesz przydzielić zasób 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 na obsługiwanych urządzeniach może zostać powiązany z teksturą za pomocą glEGLImageTargetTexture2DOES
. Jest to przydatne przy tworzeniu tekstur, które mogą być współużytkowane w ramach różnych procesów.
Interfejs JNI API (<android/hardware_buffer_jni.h>
) natywnego bufora sprzętowego umożliwia uzyskanie obiektu HardwareBuffer
, który jest obiektem Parcelable i może być przenoszony między 2 różnymi procesami. Dzięki temu aplikacja ma uprawnienia podobne do SurfaceFlinger, na przykład tworzy własną kolejkę buforów między procesami bez dostępu do wewnętrznych interfejsów API Androida.
Audio
Audio
AAudio to obecnie obsługiwany interfejs API do obsługi natywnych reklam audio. Zastąpił on OpenSL ES i zapewniał lepszą obsługę aplikacji audio o wysokiej wydajności, które wymagają dźwięku o małym czasie oczekiwania.
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 interfejs API reklam natywnych, który również jest obsługiwany. Zapoznaj się jednak z uwagami w przewodniku poniżej.
Dostępne od poziomu API 9. Do interfejsu API na poziomie 14 dodano obsługę PCM.
Biblioteka: libOpenSLES
Przewodnik: przewodnik po OpenSL ES na Androida
Interfejs API sieci neuronowych
Neural Networks API (NNAPI) udostępnia aplikacjom akcelerację sprzętową na potrzeby operacji systemów uczących się na urządzeniu. Interfejs API obsługuje tworzenie, kompilowanie i wykonywanie modeli na urządzeniu. Aplikacje zwykle nie używają bezpośrednio NNAPI. Interfejs API powinien być wywoływany przez biblioteki, platformy i narzędzia systemów uczących się, które pozwalają programistom trenować modele i wdrażać je na urządzeniach z Androidem.
Funkcja dostępna od poziomu API 27.
Biblioteka: libneuralnetworks
Przewodnik: przewodnik po sieciach neuronowych
Dokumentacja: dokumentacja interfejsu Neural Networks API.