Natywne interfejsy API

Na tej stronie znajdziesz omówienie bibliotek zawartych w NDK wraz z linkami do odpowiednich części dokumentacji interfejsu NDK API i przewodników (jeśli są dostępne).

Korzystanie z natywnych interfejsów API

Korzystanie z biblioteki udostępnianej przez NDK składa się z 2 etapów:

1. Poinformuj system kompilacji, że ma połączyć bibliotekę.

   • Jeśli używasz narzędzia ndk-build: dodaj bibliotekę do LOCAL_LDLIBS w pliku Android.mk. Pamiętaj, aby usunąć znak lib z przodu i powiedzieć -l. Aby na przykład utworzyć link do libfoo i libbar, wpisz:makefile LOCAL_LDLIBS := -lfoo -lbar

     Więcej informacji o LOCAL_LDLIBS znajdziesz w dokumentacji Android.mk.

   • Jeśli używasz CMake: postępuj zgodnie z instrukcjami w dokumentacji Studia dotyczącymi dodawania interfejsów NDK API.

2. #include odpowiednie nagłówki z kodu.

Pamiętaj, że interfejsy API nowsze niż minSdkVersion Twojej aplikacji nie będą domyślnie wywoływane. Musisz zamiast tego używać ich za pomocą dlopen() i dlsym(). Łatwiejsze podejście znajdziesz w artykule Korzystanie z nowszych interfejsów API.

Core C/C++

Biblioteka C

Standardowe pliki nagłówkowe biblioteki C11, takie jak <stdlib.h> i <stdio.h>, są dostępne jak zwykle.

Pamiętaj, że w Androidzie, w przeciwieństwie do systemu Linux, nie ma oddzielnych bibliotek libpthread ani librt. Ta funkcja jest zawarta bezpośrednio w libc, więc nie trzeba jej jawnie łączyć.

Istnieje osobny plik libm dla funkcji matematycznych (zgodnie z tradycją systemu Unix), ale podobnie jak libc jest on automatycznie łączony przez systemy kompilacji.

Funkcje dynamicznego linkera w <dlfcn.h>, takie jak dlopen(3) i dlsym(3), są dostępne, ale musisz jawnie połączyć się 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 sekcji Obsługa bibliotek C++.

Logowanie

<android/log.h> zawiera interfejsy API do logowania w logcat.

.

Dostępne od poziomu API 3.

Biblioteka: liblog

Odniesienie: 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. 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 się z libz.

NDK zawsze zawiera najnowsze pliki nagłówkowe zlib w momencie wydania, a libz.a dołączony do NDK na potrzeby statycznego linkowania jest zawsze w tej samej wersji, ale libz.so na potrzeby dynamicznego linkowania pochodzi z urządzenia i może być w dowolnej wersji, która została wydana na tym urządzeniu. Oznacza to w szczególności, że nagłówki, na podstawie których utworzono kod, nie pasują do wersji biblioteki zlib na urządzeniu, więc zwykłe ostrzeżenia przed przyjmowaniem założeń dotyczących szczegółów implementacji są w tym przypadku szczególnie ważne. Nie mamy informacji o żadnych problemach z publicznym interfejsem API, ale układ struktur zmieniał się z czasem i prawdopodobnie będzie się zmieniać nadal. Pamiętaj, że nowy interfejs API w późniejszych wersjach zlib nie będzie oczywiście dostępny w wersjach systemu operacyjnego, które są starsze niż ten interfejs. Można uniknąć wszystkich tych problemów (kosztem zwiększenia rozmiaru pliku APK), zawsze używając statycznej wartości libz.a zamiast libz.so.

Dostępne od poziomu API 3 (ale patrz uwaga powyżej).

Biblioteka: libz

Grafika

OpenGL ES 1.0–3.2

Standardowe pliki nagłówkowe OpenGL ES 1.x (<GLES/gl.h> i <GLES/glext.h>), 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 do korzystania z 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, które mają odpowiedni procesor graficzny, w pełni obsługują nowsze wersje OpenGL ES, ale biblioteki są dostępne na wszystkich urządzeniach obsługujących poziom interfejsu API, w którym zostały wprowadzone. Łączenie z bibliotekami jest bezpieczne, ale aplikacja musi wysyłać zapytania o ciąg wersji OpenGL ES i ciąg rozszerzenia, aby określić, czy bieżące urządzenie obsługuje potrzebne jej funkcje. Informacje o tym, jak wykonać to zapytanie, znajdziesz w opisie 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 API 5.

OpenGL ES 3.0 jest dostępny od poziomu 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> do przydzielania kontekstów i powierzchni OpenGL ES oraz zarządzania nimi.

EGL umożliwia wykonywanie tych operacji z kodu natywnego:

• Wyświetla listę obsługiwanych konfiguracji EGL.
• Przydzielanie i zwalnianie powierzchni OpenGL ES.
• tworzyć i usuwać konteksty OpenGL ES,
• Zamień lub odwróć powierzchnie.

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

Vulkan

Vulkan to wieloplatformowy interfejs API o niskim narzucie, który służy do renderowania grafiki 3D o wysokiej wydajności. Vulkan to otwarty standard utrzymywany przez Khronos Group. Standardowy plik nagłówkowy <vulkan/vulkan.h> zawiera deklaracje potrzebne do wykonywania wywołań renderowania Vulkan z poziomu kodu.

Przykłady kodu znajdziesz w projektach LunarG VulkanSamples i android-vulkan-tutorials na GitHubie.

Biblioteka Vulkan jest dostępna na wszystkich urządzeniach obsługujących poziom API 24 lub nowszy, ale aplikacje muszą sprawdzać w czasie działania, czy dostępne jest niezbędne wsparcie sprzętowe GPU. Urządzenia bez obsługi interfejsu Vulkan zwrócą zero urządzeń z vkEnumeratePhysicalDevices.

Dostępne od poziomu API 24.

Biblioteka: libvulkan

Przewodnik: przewodnik po interfejsie graficznym Vulkan

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 następująco:

1. Wywołaj funkcję AndroidBitmap_getInfo(), aby pobrać informacje, takie jak szerokość i wysokość, dotyczące danego uchwytu mapy bitowej.

2. Wywołaj funkcję AndroidBitmap_lockPixels(), aby zablokować bufor pikseli i pobrać do niego wskaźnik. Dzięki temu piksele nie będą się przesuwać, dopóki aplikacja nie wywoła funkcji AndroidBitmap_unlockPixels().

3. Zmodyfikuj bufor pikseli odpowiednio do jego formatu, szerokości i innych cech.

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ępne od poziomu API 26.

Biblioteka: libsync

Dokumentacja: Dokumentacja interfejsu Sync API

Aparat

Natywne interfejsy API aparatu umożliwiają precyzyjne robienie i przetwarzanie zdjęć. W przeciwieństwie do interfejsu Java camera2 API natywny interfejs API kamery nie obsługuje wycofanych implementacji interfejsu HAL kamery w wersji 1.0 (czyli lista dostępnych kamer w natywnym interfejsie API kamery nie będzie zawierać urządzeń z kamerą o poziomie sprzętowym LEGACY).

Dostępne od poziomu API 24.

Biblioteka: libcamera2ndk

Dokumentacja: Dokumentacja interfejsu Camera API

Multimedia

libmediandk

Interfejsy Media API udostępniają interfejsy natywne niskiego poziomu podobne do MediaExtractor,MediaCodec i innych powiązanych interfejsów API Java.

Biblioteka: libmediandk

Dokumentacja: dokumentacja interfejsu Media API

OpenMAX AL

Natywna obsługa multimediów na Androidzie 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 wykonywania wyjścia multimedialnego po stronie natywnej Androida.

Dystrybucja OpenMAX AL w NDK zawiera też rozszerzenia specyficzne dla Androida. Informacje o tych rozszerzeniach znajdziesz w komentarzach w <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 API NDK na Androida.

Interfejsy API obejmują:

• Zasób
• Choreograf
• Konfiguracja
• Wejście
• Looper
• Aktywność natywna
• Natywne bufory sprzętowe
• Natywne okno
• Pamięć
• Nawiązywanie kontaktów
• Czujnik
• Miejsce na dane
• SurfaceTexture

Biblioteka: libandroid

Biblioteka: libnativewindow, aby korzystać z najnowszych funkcji okien natywnych

Pełna dokumentacja: Android NDK API reference

Interfejsy API Binder

Interfejsy API Binder umożliwiają tworzenie kanałów komunikacji między procesami. Jest to niskopoziomowa implementacja komunikacji międzyprocesowej na Androidzie. W miarę możliwości preferuj komponenty wyższego poziomu. Ta biblioteka jest jednak dostępna w zaawansowanych przypadkach użycia.

Biblioteka: libbinder_ndk

Patrz: Binder

Interfejsy Hardware Buffer API

Istnieją 2 natywne interfejsy API, które umożliwiają tworzenie własnych potoków do zarządzania buforami w różnych procesach.

Interfejs API natywnego bufora sprzętowego<android/hardware_buffer.h> umożliwia bezpośrednie przydzielanie buforów w celu tworzenia własnych ścieżek zarządzania buforami w różnych procesach. Możesz przydzielić AHardwareBuffer i użyć go do uzyskania typu zasobu EGLClientBuffer za pomocą rozszerzenia eglGetNativeClientBufferANDROID. Możesz przekazać ten bufor do funkcji eglCreateImageKHR, aby utworzyć typ zasobu EGLImage, który można następnie powiązać z teksturą za pomocą funkcji glEGLImageTargetTexture2DOES na obsługiwanych urządzeniach. Może to być przydatne do tworzenia tekstur, które mogą być współdzielone między procesami.

Natywny interfejs JNI bufora sprzętowego (<android/hardware_buffer_jni.h>) umożliwia uzyskanie obiektu HardwareBuffer, który jest obiektem Parcelable, a tym samym może być przesyłany między dwoma różnymi procesami. Dzięki temu Twoja aplikacja będzie miała podobne możliwości do SurfaceFlingera, takie jak 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 audio. Zastąpił on OpenSL ES i zapewnia lepszą obsługę aplikacji audio o wysokiej wydajności, które wymagają dźwięku o niskim opóźnieniu.

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 dźwięku, który jest również obsługiwany. Zapoznaj się jednak z uwagą w przewodniku poniżej.

Dostępne od poziomu API 9. W API na poziomie 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ą na potrzeby operacji uczenia maszynowego na urządzeniu. Interfejs API obsługuje tworzenie, kompilowanie i wykonywanie modeli na urządzeniu. Aplikacje zwykle nie korzystają bezpośrednio z NNAPI. Zamiast tego interfejs API jest przeznaczony do wywoływania przez biblioteki, platformy i narzędzia uczenia maszynowego, które umożliwiają programistom trenowanie modeli i wdrażanie ich na urządzeniach z Androidem.

Dostępne od poziomu API 27.

Biblioteka: libneuralnetworks

Przewodnik: przewodnik po sieciach neuronowych

Dokumentacja: Dokumentacja API sieci neuronowych