No way of detecting the exact version of the NDK programmatically

[munsie]

There is no way of detecting the exact version of the NDK programmatically for r11b. You can parse the source.properties file for the Pkg.Revision, but this is set to 11 for all of the r11 releases so far.

In previous NDK versions, there was a single RELEASE.TXT file that contained the full version of the NDK (for example, "r10e (64-bit)").

Having a way of detecting which version is useful for me because I have a script that configures the toolchains automatically for my project. If there is a problem with a particular NDK version, I want to be able to abort and put up an error message right away.

[DanAlbert]

One of the fields in source.properties is 11.1.$BUILD_NUMBER for r11b.

[munsie]

I am not seeing that on my end. Here is the content of the source.properties for my copy of r11b (obtained using the auto-update feature in Android Studio) -- I removed the License lines to keep things compact in here:

$ cat source.properties | grep -v License
### Android Tool: Source of this archive.
#Tue Mar 22 11:04:54 EDT 2016
Archive.HostBits=64
Archive.HostOs=macosx
Pkg.Desc=Android NDK
Pkg.Revision=11
Pkg.SourceUrl=https\://dl.google.com/android/repository/repository-12.xml

[DanAlbert]

Ugh.

That's not the source.properties I ship in the NDK. Apparently the SDK manager clobbers the one I ship, and the old versions of the SDK manager (anything pre-2.0) for some reason thinks the NDK only has integral releases. As such, the SDK manager is giving you a bad source.properties.

So, the first thing to note is that the 2.0 track of AS will be releasing to stable very soon (I'm told ~weeks), so this problem won't exist for long.

Second, when it comes to "where are the toolchains in this release", just the major revision will be sufficient. The lettered releases are just bug fixes. If I were you I'd just assume that all r11 NDKs are actually r11b, and anything else is user error.