This page gives an overview of the libraries included in the NDK, with links to the relevant parts of the NDK API reference, and to guides where they exist.
Use native APIs
There are two steps to using a library that the NDK provides:
Tell the build system to link against the library.
If you are using ndk-build: Add the library to
LOCAL_LDLIBSin your Android.mk. Note that you strip the leading
-linstead. For example, to link against
libbar, you'd write:
makefile LOCAL_LDLIBS := -lfoo -lbar
For more about
LOCAL_LDLIBS, see the Android.mk docs documentation.
#includethe appropriate headers from your code.
The standard C11 library headers such as
available as usual.
Note that on Android, unlike Linux, there are no separate
librt libraries. That functionality is included directly in
which does not need to be explicitly linked against.
There is a separate
libm for math functions (following the usual Unix
tradition), but like
libc this is automatically linked by the build systems.
Dynamic linker functionality in
<dlfcn.h> such as dlopen(3) and dlsym(3) is
available, but you must explicitly link against
C++17 support is available. For more information on C++ library support, see C++ library support.
<android/log.h> contains APIs for logging to logcat.
Available since API level 3.
The native tracing API
<android/trace.h> provides the native equivalent of
android.os.Trace class in the Java programming language. This API lets
you trace named units of work in your code by writing trace events to the
system trace buffer. You can then collect and analyze the trace events using
the Systrace tool.
Available since API level 23.
Guide: Native Tracing
You can use the Zlib compression library
<zlib.h> and linking against
The NDK always includes the latest zlib header files at the time of release,
libz.a included in the NDK for static linking is always that
same version, but the
libz.so for dynamic linking comes from the device,
and be whatever version happened to be released on that device. In particular,
this means that the headers you built against do not match the version of
zlib on the device, so the usual warnings against making assumptions about
implementation details are especially valid here. We are not aware of any
issues with public API, but struct layout in particular has changed over time
and will likely continue to do so. Note that new API in later zlib versions
will obviously not be available on OS versions that predate the API. It is
possible to avoid all these problems (at the cost of increased APK size) by
always using the static
libz.a instead of
Available since API level 3 (but see note above).
OpenGL ES 1.0 - 3.2
The standard OpenGL ES 1.x headers (
2.0 headers (
<GLES2/gl2ext.h>), 3.0 headers
<GLES3/gl3ext.h>), 3.1 headers (
<GLES3/gl3ext.h>), and 3.2 headers (
<GLES3/gl3ext.h>) contain the declarations necessary for OpenGL ES.
To use OpenGL ES 1.x, link your native module to
To use OpenGL ES 2.0, link your native module to
To use OpenGL ES 3.x, link your native module to
All Android-based devices support OpenGL ES 1.0 and 2.0.
Only Android devices that have the necessary GPU fully support later versions
of OpenGL ES, but the libraries are present on all devices that support the API
level where they were introduced. It's safe to link against the libraries,
but an app must query the OpenGL ES version string and extension string
to determine whether the current device supports the features it needs. For
information on how to perform this query, see the description of
in the OpenGL specification.
OpenGL ES 1.0 is available since API level 4.
OpenGL ES 2.0 is available since API level 5.
OpenGL ES 3.0 is available since API level 18.
OpenGL ES 3.1 is available since API level 21.
OpenGL ES 3.2 is available since API level 24.
EGL provides a native platform interface via the
<EGL/eglext.h> headers for allocating and managing OpenGL ES contexts and
EGL allows you to perform the following operations from native code:
- List supported EGL configurations.
- Allocate and release OpenGL ES surfaces.
- Create and destroy OpenGL ES contexts.
- Swap or flip surfaces.
Available since API level 9.
Vulkan is a low-overhead, cross-platform API for high-performance 3D graphics
rendering. Vulkan is an open standard
maintained by the Khronos Group. The standard
<vulkan/vulkan.h> header file
contains the declarations needed to perform Vulkan rendering calls from your
The Vulkan library is present on all devices supporting API level 24 or later,
but apps must check at runtime that the necessary GPU hardware support is
available. Devices without Vulkan support will return zero devices from
Available since API level 24.
Guide: Vulkan graphics API guide
libjnigraphics library exposes API that allows access to the pixel buffers
Bitmap objects. The workflow is as follows:
AndroidBitmap_getInfo()to retrieve information, such as width and height, about a given bitmap handle.
AndroidBitmap_lockPixels()to lock the pixel buffer and retrieve a pointer to it. Doing so ensures that the pixels do not move until the app calls
Modify the pixel buffer as appropriate for its pixel format, width, and other characteristics.
AndroidBitmap_unlockPixels()to unlock the buffer.
Available since API level 8.
Reference: Bitmap API reference
Available since API level 26.
Reference: Sync API reference
The native camera APIs perform fine-grained photo capture and processing. Unlike the Java camera2 API, the native camera API does not support deprecated camera HAL 1.0 implementations (that is, the available camera list in the native camera API won’t list camera devices that have the LEGACY hardware level).
Available since API level 24.
Reference: Camera API reference
The Media APIs provide low-level native interfaces similar to
MediaCodec and other related Java APIs.
Reference: Media API reference
Android native multimedia handling is based on Khronos Group OpenMAX AL 1.0.1 API.
The standard OpenMAX AL headers
<OMXAL/OpenMAXAL_Platform.h> contain the declarations necessary for performing
multimedia output from the native side of Android.
The NDK distribution of OpenMAX AL also provides Android-specific extensions.
For information about these extensions, see the comments in
Available since API level 14.
Android native application APIs
For more information, see the Android NDK API reference documentation.
- Native Activity
- Native Hardware Buffers
- Native Window
libnativewindow for more recent Native Window functionality
Full reference: Android NDK API reference
Hardware Buffer APIs
There are two native APIs that let you create your own pipelines for cross-process buffer management.
The native hardware buffer API
lets you directly allocate buffers to create your own pipelines for cross-process buffer management.
You can allocate an
AHardwareBuffer and use it to obtain an
resource type via the
eglGetNativeClientBufferANDROID extension. You can pass
that buffer to
to create an
resource type, which may then be bound to a texture via
on supported devices. This can be useful for creating textures that may be
The native hardware buffer JNI API (
<android/hardware_buffer_jni.h>) lets you
object, which is a Parcelable and thus
may be transported between two different processes. This gives your app similar
such as creating your own queue of buffers between processes without accessing
internal Android APIs.
AAudio is the currently-supported native audio API. It replaced OpenSL ES, and provides better support for high-performance audio apps that require low-latency audio.
Available since API level 26.
Guide: AAudio API guide
Reference: AAudio API reference
OpenSL ES is another native audio API which is also supported, but see the note at the Guide below.
Available since API level 9. API level 14 added PCM support.
Guide: OpenSL ES for Android guide
Neural Networks API
The Neural Networks API (NNAPI) provides apps with hardware acceleration for on-device machine learning operations. The API supports on-device model creation, compilation, and execution. Apps typically do not use NNAPI directly; instead, the API is meant to be called by machine learning libraries, frameworks, and tools that let developers train their models and deploy them on Android devices.
Available since API level 27.
Guide: Neural Networks guide
Reference: Neural Networks API reference