APIs nativas

En esta página, hay una descripción general de las bibliotecas incluidas en el NDK, con vínculos a las partes relevantes de la referencia de la API del NDK, y a las guías en las que se encuentran.

Cómo usar API nativas

Para usar una biblioteca proporcionada por el NDK, se deben realizar dos pasos:

  1. Indicarle al sistema de compilación que se vincule con la biblioteca.

    • Si usas ndk-build: agrega la biblioteca a LOCAL_LDLIBS en tu Android.mk. Ten en cuenta que, en su lugar, desvinculas el lib inicial y dices -l. Por ejemplo, para vincularlo con libfoo y libbar, tendrías que escribir: makefile LOCAL_LDLIBS := -lfoo -lbar

      Para obtener más información sobre LOCAL_LDLIBS, consulta la documentación de documentos de Android.mk.

    • Si usas CMake: sigue las instrucciones de la documentación Cómo agregar API del NDK de Studio.

  2. #include los encabezados correspondientes de tu código.

C/C++ del núcleo

Biblioteca C

Los encabezados de la biblioteca C11 estándar como <stdlib.h> y <stdio.h> están disponibles como siempre.

Ten en cuenta que en Android, a diferencia de Linux, no hay bibliotecas libpthread o librt separadas. Esa función se incluye directamente en libc, con el que no es necesario vincularse de forma explícita.

Hay un libm separado para funciones matemáticas (según la tradición habitual de Unix) pero, como ocurre con libc, los sistemas de compilación lo vinculan de manera automática.

Está disponible la función de vinculador dinámico en <dlfcn.h>, como dlopen(3) y dlsym(3), pero debes vincularte explícitamente con libdl.

Biblioteca: libc/libm/libdl

Biblioteca C++

La compatibilidad con C++17 está disponible. Para obtener más información, consulta Compatibilidad con la biblioteca C++.

Registro

<android/log.h> contiene las API para el registro en logcat.

Disponible a partir de la API nivel 3.

Biblioteca: liblog

Referencia: Registro

Registro

La API nativa de seguimiento <android/trace.h> proporciona el equivalente nativo de la clase android.os.Trace en el lenguaje de programación Java. La API te permite escribir eventos de seguimiento en el búfer de seguimiento del sistema para realizar el seguimiento de unidades de trabajo con nombre en tu código. Luego, puedes recopilar y analizar los eventos de seguimiento mediante la herramienta Systrace.

Disponible a partir de la API nivel 23.

Biblioteca: libandroid

Guía: Seguimiento nativo

Compresión zlib

Para usar la biblioteca de compresión Zlib, tienes que incluir <zlib.h> y vincularlo con libz.

El NDK siempre incluye los archivos de encabezado zlib más recientes en el momento del lanzamiento. El libz.a incluido en el NDK para la vinculación estática también es siempre esa misma versión, pero el libz.so de la vinculación dinámica proviene del dispositivo y es la versión que se lanzó en ese dispositivo. En particular, esto significa que los encabezados que compilaste no coinciden con la versión de zlib en el dispositivo, por lo que las advertencias habituales contra hacer suposiciones sobre los detalles de implementación son especialmente válidas aquí. No estamos al tanto de ningún problema con la API pública, pero el diseño de la estructura en particular cambió con el tiempo y es probable que continúe haciéndolo. Ten en cuenta que la API nueva en versiones posteriores de zlib no estará disponible en las versiones de SO anteriores a la API. Para evitar todos estos problemas (a costa de un aumento del tamaño del APK), siempre usa el objeto libz.a estático en lugar de libz.so.

Disponible a partir de la API nivel 3 (pero consulta la nota anterior).

Biblioteca: libz

Gráficos

OpenGL ES 1.0-3.2

Los encabezados estándar de OpenGL ES 1.x (<GLES/gl.h> y <GLES/glext.h>), 2.0 (<GLES2/gl2.h> y <GLES2/gl2ext.h>), 3.0 (<GLES3/gl3.h> y <GLES3/gl3ext.h>), 3.1 (<GLES3/gl31.h> y <GLES3/gl3ext.h>) y 3.2 (<GLES3/gl32.h> y <GLES3/gl3ext.h>) contienen las declaraciones necesarias para OpenGL ES.

Para usar OpenGL ES 1.x, vincula tu módulo nativo a libGLESv1_CM.

Para usar OpenGL ES 2.0, vincula tu módulo nativo a libGLESv2.

Para usar OpenGL ES 3.x, vincula tu módulo nativo a libGLESv3.

Todos los dispositivos basados en Android admiten OpenGL ES 1.0 y 2.0.

Solo los dispositivos Android que tienen la GPU necesaria son totalmente compatibles con las versiones posteriores de OpenGL ES, pero las bibliotecas están en todos los dispositivos que admiten el nivel de API en el que se introdujeron. Es seguro vincular con las bibliotecas, pero la app debe consultar la string de versión y la string de extensión de OpenGL ES para determinar si el dispositivo actual admite las funciones que necesita. Para obtener información sobre cómo realizar esta búsqueda, lee la descripción de glGetString() en la especificación de OpenGL.

Además, debes colocar una etiqueta <uses-feature> en el archivo de manifiesto para indicar la versión de OpenGL ES que necesitas.

OpenGL ES 1.0 está disponible a partir de la API nivel 4.

OpenGL ES 2.0 está disponible a partir de la API nivel 5.

OpenGL ES 3.0 está disponible a partir de la API nivel 18.

OpenGL ES 3.1 está disponible a partir de la API nivel 21.

OpenGL ES 3.2 está disponible a partir de la API nivel 24.

EGL

EGL proporciona una interfaz de plataforma nativa mediante los encabezados <EGL/egl.h> y <EGL/eglext.h> para asignar y administrar contextos y plataformas de OpenGL ES.

EGL te permite realizar las siguientes operaciones a partir de código nativo:

  • Enumerar las configuraciones de EGL que se admiten
  • Asignar y retirar superficies de OpenGL ES
  • Crear y destruir contextos de OpenGL ES
  • Intercambiar o girar superficies

En el nivel de API 24, se agregó compatibilidad con las extensiones EGL_KHR_mutable_render_buffer, ANDROID_create_native_client_buffer y ANDROID_front_buffer_auto_refresh.

Disponible a partir de la API nivel 9.

Biblioteca: libEGL

Guía: Interfaz de plataforma nativa de EGL

Vulkan

Vulkan es una API multiplataforma de bajo costo para procesamiento de gráficos 3D de alto rendimiento. Vulkan es un estándar abierto a cargo de Khronos Group. El archivo de encabezado <vulkan/vulkan.h> estándar contiene las declaraciones necesarias para hacer llamadas de renderización de Vulkan a partir de tu código.

Para obtener muestras de código, consulta los proyectos VulkanSamples y android-vulkan-tutorials de LunarG en GitHub.

La biblioteca de Vulkan está presente en todos los dispositivos compatibles con nivel de API 24 o versiones posteriores, pero las apps deben verificar que la compatibilidad con el hardware de la GPU esté disponible en el entorno de ejecución. Los dispositivos no compatibles con Vulkan devolverán cero dispositivos desde vkEnumeratePhysicalDevices.

Disponible a partir de la API nivel 24.

Biblioteca: libvulkan

Guía: Guía de la API de gráficos de Vulkan

Mapas de bits

La biblioteca libjnigraphics expone la API que permite el acceso a los búferes de píxeles de objetos Bitmap de Java. El flujo de trabajo es el siguiente:

  1. Llama a AndroidBitmap_getInfo() para obtener información, como el ancho y la altura, acerca de un controlador de mapa de bits determinado.

  2. Llama a AndroidBitmap_lockPixels() para bloquear el búfer de píxeles y recuperar un puntero. Esto garantiza que los píxeles no se muevan hasta que la app llame a AndroidBitmap_unlockPixels().

  3. Modifica el búfer de píxeles según corresponda para el formato de píxeles, el ancho y otras características.

  4. Llama a AndroidBitmap_unlockPixels() para desbloquear el búfer.

Disponible a partir de la API nivel 8.

Biblioteca: libjnigraphics

Referencia: Referencia de la API de mapa de bits

API de sincronización

Disponible a partir de la API nivel 26.

Biblioteca: libsync

Referencia: Referencia de la API de sincronización

Cámara

Las API nativas de cámara realizan captura y procesamiento detallado de fotos. A diferencia de la API de camera2 de Java, la API de cámara nativa no admite implementaciones de cámara HAL 1.0 obsoletas (es decir, la lista de cámaras disponibles en la API de cámara nativa no mostrará dispositivos de cámara con nivel de hardware LEGACY).

Disponible a partir de la API nivel 24.

Biblioteca: libcamera2ndk

Referencia: Referencia de la API de cámara

Contenido multimedia

libmediandk

Las API de medios proporcionan interfaces nativas de bajo nivel similares a MediaExtractor, MediaCodec y otras API de Java relacionadas.

Biblioteca: libmediandk

Referencia: Referencia de la API de medios

OpenMAX AL

El control multimedia nativo de Android se basa en la API OpenMAX AL 1.0.1 de Khronos Group.

Los encabezados <OMXAL/OpenMAXAL.h> y <OMXAL/OpenMAXAL_Platform.h> estándar de OpenMAX AL contienen las declaraciones necesarias para obtener salidas multimedia del lado nativo de Android.

La distribución de OpenMAX AL en el NDK también proporciona extensiones específicas de Android. Para obtener información sobre estas extensiones, consulta los comentarios en <OMXAL/OpenMAXAL_Android.h>.

Disponible a partir de la API nivel 14.

Biblioteca: libOpenMAXAL

API de aplicaciones nativas de Android

Para obtener más información, consulta la documentación de la Referencia de la API de NDK de Android.

Las API incluyen:

Biblioteca: libandroid

Biblioteca: libnativewindow para funciones de Native Window más recientes

Referencia completa: Referencia de la API de NDK de Android

API de búfer de hardware

Hay dos API nativas que te permiten crear tus propias canalizaciones para la administración de búfer en procesos cruzados.

La API de búfer de hardware nativa <android/hardware_buffer.h> te permite asignar búferes directamente a fin de crear tus propias canalizaciones para la administración de búfer en procesos cruzados. Puedes asignar un AHardwareBuffer y usarlo para obtener un tipo de recurso EGLClientBuffer mediante la extensión eglGetNativeClientBufferANDROID. Puedes pasar ese búfer a eglCreateImageKHR para crear un tipo de recurso EGLImage, que luego puede unirse a una textura a través de glEGLImageTargetTexture2DOES en dispositivos compatibles. Esto puede ser útil para crear texturas que podrían compartirse en procesos cruzados.

La API de JNI de búfer de hardware nativa (<android/hardware_buffer_jni.h>) te permite obtener un objeto HardwareBuffer, que es un Parcelable y, por lo tanto, puede transportarse entre dos procesos diferentes. Esto le brinda a tu app funciones similares a SurfaceFlinger, como crear tu propia cola de búferes entre procesos sin acceder a las API internas de Android.

Audio

AAudio

AAudio es la API de audio nativa compatible actualmente. Reemplazó a OpenSL ES y ofrece mejor compatibilidad con apps de audio de alto rendimiento que requieren audio de baja latencia.

Disponible a partir de la API nivel 26.

Biblioteca: libaaudio

Guía: Guía de la API de AAudio

Referencia: Referencia de la API de AAudio

OpenSL ES

OpenSL ES es otra API de audio nativa que también es compatible, pero consulta la nota en la Guía que se incluye a continuación.

Disponible a partir de la API nivel 9. En la API nivel 14, se agregó compatibilidad con PCM.

Biblioteca: libOpenSLES

Guía: Guía de OpenSL ES para Android

API de redes neuronales

La API de redes neuronales (NNAPI) ofrece a las apps aceleración de hardware para las operaciones de aprendizaje automático en el dispositivo. La API permite crear, compilar y ejecutar modelos en el dispositivo. En general, las apps no usan NNAPI directamente; en su lugar, las bibliotecas, los framework y las herramientas de aprendizaje automático que permiten a los desarrolladores preparar sus modelos e implementarlos en dispositivos Android deben llamar la API.

Disponible a partir de la API nivel 27.

Biblioteca: libneuralnetworks

Guía: Guía sobre redes neuronales

Referencia: Referencia de la API de redes neuronales