Natywne interfejsy API

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:

1. 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 fragment lib jest usuwany i zamiast niego wypowiadasz -l. Aby na przykład utworzyć połączenie z elementami libfoo i libbar, 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.

2. #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.

na Androidzie.

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:

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

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

3. Zmodyfikuj bufor pikseli, aby dostosować go do jego formatu piksela, szerokości i innych właściwości.

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