Natywne interfejsy API

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:

  1. 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 znak lib i zamiast tego mówisz -l. Aby na przykład utworzyć link do libfoolibbar, 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.

  2. #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()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><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><GLES/glext.h>), nagłówki 2.0 (<GLES2/gl2.h><GLES2/gl2ext.h>), nagłówki 3.0 (<GLES3/gl3.h><GLES3/gl3ext.h>), nagłówki 3.1 (<GLES3/gl31.h><GLES3/gl3ext.h>) oraz nagłówki 3.2 (<GLES3/gl32.h><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><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_bufferANDROID_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 VulkanSamplesandroid-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:

  1. Wywołaj funkcję AndroidBitmap_getInfo(), aby pobrać informacje o danym identyfikatorze bitmapy, takie jak szerokość i wysokość.

  2. 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 funkcji AndroidBitmap_unlockPixels().

  3. Zmień bufor pikseli zgodnie z formatem pikseli, szerokością i innymi właściwościami.

  4. 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><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:

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