Questa pagina fornisce una panoramica delle librerie incluse nell'NDK, con link alle parti pertinenti della documentazione di riferimento dell'API NDK e alle guide, se esistenti.
Utilizzare le API native
Per utilizzare una libreria fornita dall'NDK, devi completare due passaggi:
Comunica al sistema di build di eseguire il collegamento alla libreria.
Se utilizzi ndk-build: aggiungi la libreria a
LOCAL_LDLIBS
in Android.mk. Tieni presente che devi rimuovere il prefissolib
e dire-l
. Ad esempio, per collegarelibfoo
elibbar
, devi scrivere:makefile LOCAL_LDLIBS := -lfoo -lbar
Per saperne di più su
LOCAL_LDLIBS
, consulta la documentazione Android.mk.Se utilizzi CMake: segui le istruzioni nella documentazione Aggiungere API NDK di Studio.
#include
le intestazioni appropriate dal tuo codice.
Tieni presente che le API più recenti della minSdkVersion
della tua applicazione non saranno
richiamabili per impostazione predefinita e dovrai utilizzarle tramite
dlopen()
e dlsym()
.
Per un approccio più semplice, vedi Utilizzare API più recenti.
C/C++ di base
Libreria C
Le intestazioni della libreria C11 standard, come <stdlib.h>
e <stdio.h>
, sono
disponibili come di consueto.
Tieni presente che su Android, a differenza di Linux, non esistono librerie libpthread
o librt
separate. Questa funzionalità è inclusa direttamente in libc
,
che non deve essere collegata esplicitamente.
Esiste una libm
separata per le funzioni matematiche (secondo la consueta tradizione Unix), ma come libc
viene collegata automaticamente dai sistemi di compilazione.
La funzionalità di collegamento dinamico in <dlfcn.h>
, ad esempio dlopen(3) e dlsym(3), è
disponibile, ma devi collegarti esplicitamente a libdl
.
Libreria: libc
/ libm
/ libdl
Libreria C++
È disponibile il supporto di C++17. Per ulteriori informazioni sul supporto della libreria C++, vedi Supporto della libreria C++.
Logging
<android/log.h>
contiene API per la registrazione in logcat.
Disponibile a partire dal livello API 3.
Libreria: liblog
Riferimento: Logging
Traccia
L'API di tracciamento nativa <android/trace.h>
fornisce l'equivalente nativo della
classe android.os.Trace
nel linguaggio di programmazione Java. Questa API ti consente
di tracciare unità di lavoro denominate nel tuo codice scrivendo eventi di tracciamento nel
buffer di tracciamento del sistema. Puoi quindi raccogliere e analizzare gli eventi di traccia utilizzando
lo strumento Systrace.
Disponibile dal livello API 23.
Libreria: libandroid
Guida: Native Tracing
Compressione zlib
Puoi utilizzare la libreria di compressione Zlib
includendo <zlib.h>
e collegandoti a libz
.
L'NDK include sempre i file di intestazione zlib più recenti al momento del rilascio
e la libz.a
inclusa nell'NDK per il collegamento statico è sempre la stessa versione, ma la libz.so
per il collegamento dinamico proviene dal dispositivo
e può essere qualsiasi versione rilasciata su quel dispositivo. In particolare,
ciò significa che le intestazioni che hai creato non corrispondono alla versione di
zlib sul dispositivo, quindi i soliti avvisi contro le ipotesi sui
dettagli di implementazione sono particolarmente validi in questo caso. Non siamo a conoscenza di problemi con l'API pubblica, ma il layout della struttura in particolare è cambiato nel tempo e probabilmente continuerà a farlo. Tieni presente che la nuova API nelle versioni successive di zlib ovviamente non sarà disponibile nelle versioni del sistema operativo precedenti all'API. È
possibile evitare tutti questi problemi (a costo di un aumento delle dimensioni dell'APK) utilizzando
sempre libz.a
statico anziché libz.so
.
Disponibile a partire dal livello API 3 (ma vedi la nota sopra).
Libreria: libz
Grafica
OpenGL ES 1.0 - 3.2
Le intestazioni standard OpenGL ES 1.x (<GLES/gl.h>
e <GLES/glext.h>
),
2.0 (<GLES2/gl2.h>
e <GLES2/gl2ext.h>
), 3.0 (<GLES3/gl3.h>
e <GLES3/gl3ext.h>
), 3.1 (<GLES3/gl31.h>
e <GLES3/gl3ext.h>
) e 3.2 (<GLES3/gl32.h>
e
<GLES3/gl3ext.h>
) contengono le dichiarazioni necessarie per OpenGL ES.
Per utilizzare OpenGL ES 1.x, collega il modulo nativo a libGLESv1_CM
.
Per utilizzare OpenGL ES 2.0, collega il modulo nativo a libGLESv2
.
Per utilizzare OpenGL ES 3.x, collega il modulo nativo a libGLESv3
.
Tutti i dispositivi basati su Android supportano OpenGL ES 1.0 e 2.0.
Solo i dispositivi Android con la GPU necessaria supportano completamente le versioni successive
di OpenGL ES, ma le librerie sono presenti su tutti i dispositivi che supportano il livello API
in cui sono state introdotte. È sicuro collegarsi alle librerie,
ma un'app deve eseguire query sulla stringa della versione e sulla stringa dell'estensione OpenGL ES
per determinare se il dispositivo corrente supporta le funzionalità di cui ha bisogno. Per
informazioni su come eseguire questa query, consulta la descrizione di
glGetString()
nella specifica OpenGL.
Inoltre, devi inserire un tag
<uses-feature>
nel file
manifest per indicare la versione di
OpenGL ES che ti serve.
OpenGL ES 1.0 è disponibile a partire dal livello API 4.
OpenGL ES 2.0 è disponibile a partire dal livello API 5.
OpenGL ES 3.0 è disponibile a partire dal livello API 18.
OpenGL ES 3.1 è disponibile a partire dal livello API 21.
OpenGL ES 3.2 è disponibile a partire dal livello API 24.
EGL
EGL fornisce un'interfaccia della piattaforma nativa tramite le intestazioni <EGL/egl.h>
e
<EGL/eglext.h>
per allocare e gestire contesti e
superfici OpenGL ES.
EGL ti consente di eseguire le seguenti operazioni dal codice nativo:
- Elenca le configurazioni EGL supportate.
- Allocazione e rilascio delle superfici OpenGL ES.
- Crea ed elimina contesti OpenGL ES.
- Scambia o capovolgi le superfici.
Il livello API 24 ha aggiunto il supporto per le estensioni
EGL_KHR_mutable_render_buffer
,
ANDROID_create_native_client_buffer
,
e
ANDROID_front_buffer_auto_refresh
.
Disponibile dal livello API 9.
Libreria: libEGL
Guida: interfaccia della piattaforma nativa EGL
Vulkan
Vulkan è un'API multipiattaforma a basso overhead per il rendering di grafica 3D ad alte prestazioni. Vulkan è uno standard aperto
gestito dal Khronos Group. Il file di intestazione standard <vulkan/vulkan.h>
contiene le dichiarazioni necessarie per eseguire chiamate di rendering Vulkan dal tuo
codice.
Per esempi di codice, consulta i progetti LunarG VulkanSamples e android-vulkan-tutorials su GitHub.
La libreria Vulkan è presente su tutti i dispositivi che supportano il livello API 24 o versioni successive,
ma le app devono verificare in fase di runtime che sia disponibile il supporto hardware GPU necessario. I dispositivi che non supportano Vulkan restituiranno zero dispositivi da
vkEnumeratePhysicalDevices
.
Disponibile a partire dal livello API 24.
Libreria: libvulkan
Guida: Guida all'API grafica Vulkan
Bitmap
La libreria libjnigraphics
espone un'API che consente l'accesso ai buffer di pixel
degli oggetti Java Bitmap
. Il flusso di lavoro è il seguente:
Chiama
AndroidBitmap_getInfo()
per recuperare informazioni, ad esempio larghezza e altezza, su un determinato handle bitmap.Chiama
AndroidBitmap_lockPixels()
per bloccare il buffer dei pixel e recuperare un puntatore. In questo modo, i pixel non si spostano finché l'app non chiamaAndroidBitmap_unlockPixels()
.Modifica il buffer dei pixel in base al formato, alla larghezza e ad altre caratteristiche dei pixel.
Chiama
AndroidBitmap_unlockPixels()
per sbloccare il buffer.
Disponibile a partire dal livello API 8.
Libreria: libjnigraphics
Riferimento: Riferimento API Bitmap
API Sync
Disponibile a partire dal livello API 26.
Libreria: libsync
Riferimento: Riferimento API Sync
Fotocamera
Le API della fotocamera native eseguono l'acquisizione e l'elaborazione delle foto in modo granulare. A differenza dell'API Java camera2, l'API nativa della fotocamera non supporta le implementazioni HAL della fotocamera 1.0 deprecate (ovvero, l'elenco delle fotocamere disponibili nell'API nativa della fotocamera non elencherà i dispositivi della fotocamera con il livello hardware LEGACY).
Disponibile a partire dal livello API 24.
Libreria: libcamera2ndk
Riferimento: Riferimento API Camera
Contenuti multimediali
libmediandk
Le API Media forniscono interfacce native di basso livello simili a MediaExtractor
,
MediaCodec
e altre API Java correlate.
Libreria: libmediandk
Riferimento: Riferimento API Media
OpenMAX AL
La gestione nativa dei contenuti multimediali di Android si basa sull'API OpenMAX AL 1.0.1 di Khronos Group.
Le intestazioni OpenMAX AL standard <OMXAL/OpenMAXAL.h>
e
<OMXAL/OpenMAXAL_Platform.h>
contengono le dichiarazioni necessarie per eseguire
l'output multimediale dal lato nativo di Android.
La distribuzione NDK di OpenMAX AL fornisce anche estensioni specifiche per Android.
Per informazioni su queste estensioni, consulta i commenti in
<OMXAL/OpenMAXAL_Android.h>
.
Disponibile a partire dal livello API 14.
Libreria: libOpenMAXAL
API per applicazioni native per Android
Per saperne di più, consulta la documentazione di riferimento dell'API Android NDK.
Le API includono:
- Asset
- Coreografo
- Configurazione
- Ingresso
- Looper
- Attività nativa
- Buffer hardware nativi
- Finestra nativa
- Memoria
- Networking
- Sensore
- Spazio di archiviazione
- SurfaceTexture
Libreria: libandroid
Libreria: libnativewindow
per funzionalità Native Window più recenti
Riferimento completo: Riferimento API Android NDK
API Binder
Le API Binder consentono di creare canali di comunicazione tra i processi. Si tratta dell'implementazione di basso livello della comunicazione interprocesso di Android. Se possibile, preferisci i componenti di livello superiore. Tuttavia, questa libreria è disponibile per casi d'uso avanzati.
Libreria: libbinder_ndk
Riferimento: Binder
API Hardware Buffer
Esistono due API native che ti consentono di creare pipeline personalizzate per la gestione dei buffer tra processi.
L'API buffer hardware nativa
<android/hardware_buffer.h>
ti consente di allocare direttamente i buffer per creare pipeline personalizzate per la gestione dei buffer tra processi.
Puoi allocare un AHardwareBuffer
e utilizzarlo per ottenere un tipo di risorsa
EGLClientBuffer
tramite l'estensione eglGetNativeClientBufferANDROID
. Puoi passare
questo buffer a
eglCreateImageKHR
per creare un
tipo di risorsa
EGLImage
, che può essere associato a una texture tramite
glEGLImageTargetTexture2DOES
sui dispositivi supportati. Ciò può essere utile per creare texture che possono essere
condivise tra processi diversi.
L'API JNI del buffer hardware nativo (<android/hardware_buffer_jni.h>
) consente di ottenere un oggetto HardwareBuffer
, che è un Parcelable e quindi può essere trasportato tra due processi diversi. In questo modo, la tua app ha funzionalità simili a SurfaceFlinger, come la creazione di una coda di buffer tra i processi senza accedere alle API Android interne.
Audio
AAudio
AAudio è l'API audio nativa attualmente supportata. Ha sostituito OpenSL ES e offre un supporto migliore per le app audio ad alte prestazioni che richiedono audio a bassa latenza.
Disponibile a partire dal livello API 26.
Libreria: libaaudio
Guida: Guida all'API AAudio
Riferimento: Riferimento API AAudio
OpenSL ES
OpenSL ES è un'altra API audio nativa supportata, ma consulta la nota nella guida riportata di seguito.
Disponibile dal livello API 9. Il livello API 14 ha aggiunto il supporto PCM.
Libreria: libOpenSLES
Guida: OpenSL ES per Android
API Neural Networks
L'API Neural Networks (NNAPI) fornisce alle app l'accelerazione hardware per le operazioni di machine learning sul dispositivo. L'API supporta la creazione, la compilazione e l'esecuzione di modelli sul dispositivo. In genere, le app non utilizzano direttamente NNAPI; l'API è pensata per essere chiamata da librerie, framework e strumenti di machine learning che consentono agli sviluppatori di addestrare i propri modelli e distribuirli su dispositivi Android.
Disponibile dal livello API 27.
Libreria: libneuralnetworks
Guida: Guida alle reti neurali
Riferimento: Riferimento API Neural Networks