NDK Roadmap

Note: If there‘s anything you want to see done in the NDK, file a bug! Nothing here is set in stone, and if there’s something that we haven‘t thought of that would be of more use, we’d be happy to adjust our plans for that.

Disclaimer: Everything here is subject to change. The further the plans are in the future, the less stable they will be. Things in the upcoming release are fairly certain, and the second release is quite likely. Beyond that, anything written here is what we would like to accomplish in that release assuming things have gone according to plan until then.

Note: For release timing, see our release schedule on our wiki.

NDK r17

Estimated release: Q4 2017

Default to libc++

If NDK r16 shows that libc++ with the refreshed libandroid_support is working well, the NDK will begin defaulting to using libc++. This means ndk-build, CMake, the Gradle plugin, and standalone toolchains. We don't have any control over other build systems :)

Bugfix Release

With all the systemic NDK issues now solved (or at least pending feedback on the attempted fixes), we should take a look through our bug backlog and start fixing all the non-critical and nice-to-have issues.

NDK r18

Estimated release: Q1 2018

Remove non-libc++ STLs

libc++ has been the default for a release and has proven to be stable. It is a strict improvement over the other STLs (more features, better Clang compatibility, Apache licensed, most reliable). The fact that the NDK supports multiple STLs is a common pain point for users (it's confusing for newcomers, and it makes sharing libraries difficult because they must all use the same STL).

Now that we have a good choice for a single STL, we‘ll remove the others. We’ll most likely move the source we have for these along with building instructions to a separate project so that people that need these for ABI compatibility reasons can continue using them, but support for these will end completely.

Remove GCC

GCC is still in the NDK today because some of gnustl's C++11 features were written such that they do not work with Clang (threading and atomics, mostly). Now that libc++ is the best choice of STL, this is no longer blocking, so GCC can be removed.

Bugfix Release

The r17 release cycle alone probably won't be enough to burn down enough of these issues.

NDK r19

Estimated release: Q2 2018

Make standalone toolchains obsolete

Now that the NDK is down to a single compiler and STL, if we just taught the Clang driver to emit -D__ANDROID_API__=foo and to link libc.so.18 instead of libc.so, standalone toolchains would be obsolete because the compiler would already be a standalone toolchain. The NDK toolchain would Just Work regardless of build system, and the logic contained in each build system could be greatly reduced.

Historical releases

Full history is available, but this section summarizes major changes in recent releases.

NDK r16

Fixed libandroid_support, libc++ now the recommended STL (but still not the default).

Removed non-unified headers.

NDK r15

Defaulted to unified headers (opt-out).

Removed support for API levels lower than 14 (Android 4.0).

NDK r14

Added unified headers (opt-in).

NDK r13

Added simpleperf.

NDK r12

Removed armeabi-v7a-hard.

Removed support for API levels lower than 9 (Android 2.3).