This release of the NDK includes new features to support the Android 4.0 platform as well as many other additions and improvements:

New features

• Added official NDK APIs for Android 4.0 (API level 14), which adds the following native features to the platform:
  • Added native multimedia API based on the Khronos Group OpenMAX AL™ 1.0.1 standard. The new<OMXAL/OpenMAXAL.h> and <OMXAL/OpenMAXAL_Android.h> headers allow applications targeting API level 14 to perform multimedia output directly from native code by using a new Android-specific buffer queue interface. For more details, see docs/openmaxal/index.html and http://www.khronos.org/openmax/.
  • Updated the native audio API based on the Khronos Group OpenSL ES 1.0.1™ standard. With API Level 14, you can now decode compressed audio (e.g. MP3, AAC, Vorbis) to PCM. For more details, see docs/opensles/index.html andhttp://www.khronos.org/opensles/.
• Added CCache support. To speed up large rebuilds, define the NDK_CCACHE environment variable to ccache (or the path to your ccache binary). When declared, the NDK build system automatically uses CCache when compiling any source file. For example:

  export NDK_CCACHE=ccache

  Note: CCache is not included in the NDK release so you must have it installed prior to using it. For more information about CCache, see http://ccache.samba.org.

• Added support for setting APP_ABI to all to indicate that you want to build your NDK modules for all the ABIs supported by your given NDK release. This means that either one of the following two lines in your Application.mk are equivalent with this release:

  APP_ABI := all
  APP_ABI := armeabi armeabi-v7a x86

  This also works if you define APP_ABI when calling ndk-build from the command-line, which is a quick way to check that your project builds for all supported ABIs without changing the project’s Application.mk file. For example:

  ndk-build APP_ABI=all

• Added a LOCAL_CPP_FEATURES variable in Android.mk that allows you to declare which C++ features (RTTI or Exceptions) your module uses. This ensures that the final linking works correctly if you have prebuilt modules that depend on these features. See docs/ANDROID-MK.html and docs/CPLUSPLUS-SUPPORT.html for more details.
• Shortened paths to source and object files that are used in build commands. When invoking $NDK/ndk-build from your project path, the paths to the source, object, and binary files that are passed to the build commands are significantly shorter now, because they are passed relative to the current directory. This is useful when building projects with a lot of source files, to avoid limits on the maximum command line length supported by your host operating system. The behavior is unchanged if you invoke ndk-build from a sub-directory of your project tree, or if you define NDK_PROJECT_PATH to point to a specific directory.

Experimental features

You can now build your NDK source files on Windows without Cygwin by calling the ndk-build.cmd script from the command line from your project path. The script takes exactly the same arguments as the original ndk-build script. The Windows NDK package comes with its own prebuilt binaries for GNU Make, Awk and other tools required by the build. You should not need to install anything else to get a working build system.Important: ndk-gdb does not work on Windows, so you still need Cygwin to debug.This feature is still experimental, so feel free to try it and report issues on the public bug database or public forum. All samples and unit tests shipped with the NDK succesfully compile with this feature.

Important bug fixes

• Imported shared libraries are now installed by default to the target installation location (libs/<abi>) if APP_MODULES is not defined in your Application.mk. For example, if a top-level module foo imports a module bar, then both libfoo.so andlibbar.so are copied to the install location. Previously, only libfoo.so was copied, unless you listed bar in yourAPP_MODULES too. If you define APP_MODULES explicitly, the behavior is unchanged.
• ndk-gdb now works correctly for activities with multiple categories in their MAIN intent filters.
• Static library imports are now properly transitive. For example, if a top-level module foo imports static library bar that imports static library zoo, the libfoo.so will now be linked against both libbar.a and libzoo.a.

Other changes

• docs/NATIVE-ACTIVITY.HTML: Fixed typo. The minimum API level should be 9, not 8 for native activities.
• docs/STABLE-APIS.html: Added missing documentation listing EGL as a supported stable API, starting from API level 9.
• download-toolchain-sources.sh: Updated to download the toolchain sources from android.googlesource.com, which is the new location for the AOSP servers.
• Added a new C++ support runtime named gabi++. More details about it are available in the updated docs/CPLUSPLUS-SUPPORT.html.
• Added a new C++ support runtime named gnustl_shared that corresponds to the shared library version of GNU libstdc++ v3 (GPLv3 license). See more info at docs/CPLUSPLUS-SUPPORT.html
• Added support for RTTI in the STLport C++ runtimes (no support for exceptions).
• Added support for multiple file extensions in LOCAL_CPP_EXTENSION. For example, to compile both foo.cpp and bar.cxxas C++ sources, declare the following:

  LOCAL_CPP_EXTENSION := .cpp .cxx

• Removed many unwanted exported symbols from the link-time shared system libraries provided by the NDK. This ensures that code generated with the standalone toolchain doesn’t risk to accidentally depend on a non-stable ABI symbol (e.g. any libgcc.a symbol that changes each time the toolchain used to build the platform is changed)
• Refreshed the EGL and OpenGLES Khronos headers to support more extensions. Note that this does not change the NDK ABIs for the corresponding libraries, because each extension must be probed at runtime by the client application.The extensions that are available depend on your actual device and GPU drivers, not the platform version the device runs on. The header changes simply add new constants and types to make it easier to use the extensions when they have been probed with eglGetProcAddress() or glGetProcAddress(). The following list describes the newly supported extensions:

  GLES 1.x

  • GL_OES_vertex_array_object
  • GL_OES_EGL_image_external
  • GL_APPLE_texture_2D_limited_npot
  • GL_EXT_blend_minmax
  • GL_EXT_discard_framebuffer
  • GL_EXT_multi_draw_arrays
  • GL_EXT_read_format_bgra
  • GL_EXT_texture_filter_anisotropic
  • GL_EXT_texture_format_BGRA8888
  • GL_EXT_texture_lod_bias
  • GL_IMG_read_format
  • GL_IMG_texture_compression_pvrtc
  • GL_IMG_texture_env_enhanced_fixed_function
  • GL_IMG_user_clip_plane
  • GL_IMG_multisampled_render_to_texture
  • GL_NV_fence
  • GL_QCOM_driver_control
  • GL_QCOM_extended_get
  • GL_QCOM_extended_get2
  • GL_QCOM_perfmon_global_mode
  • GL_QCOM_writeonly_rendering
  • GL_QCOM_tiled_rendering

  GLES 2.0

  • GL_OES_element_index_uint
  • GL_OES_get_program_binary
  • GL_OES_mapbuffer
  • GL_OES_packed_depth_stencil
  • GL_OES_texture_3D
  • GL_OES_texture_float
  • GL_OES_texture_float_linear
  • GL_OES_texture_half_float_linear
  • GL_OES_texture_npot
  • GL_OES_vertex_array_object
  • GL_OES_EGL_image_external
  • GL_AMD_program_binary_Z400
  • GL_EXT_blend_minmax
  • GL_EXT_discard_framebuffer
  • GL_EXT_multi_draw_arrays
  • GL_EXT_read_format_bgra
  • GL_EXT_texture_format_BGRA8888
  • GL_EXT_texture_compression_dxt1
  • GL_IMG_program_binary
  • GL_IMG_read_format
  • GL_IMG_shader_binary
  • GL_IMG_texture_compression_pvrtc
  • GL_IMG_multisampled_render_to_texture
  • GL_NV_coverage_sample
  • GL_NV_depth_nonlinear
  • GL_QCOM_extended_get
  • GL_QCOM_extended_get2
  • GL_QCOM_writeonly_rendering
  • GL_QCOM_tiled_rendering

  EGL

  • EGL_ANDROID_recordable
  • EGL_NV_system_time