Android Studio stable channel is serving the NDK beta

[Zingam]

I don't know if that is relevant to NDK but after Android Studio offered me to upgrade from r12 to r13 a simple JNI project created with the default template fails to compile now. I created a fresh project with the same settings (if I recall correctly) and it compiles.
Or should I complain about that in the Android Studio section?

Error while executing 'C:\SDKs\Android\sdk\cmake\3.6.3155560\bin\cmake.exe' with arguments {-HX:\Android\MyApplication\app -BX:\Android\MyApplication\app\.externalNativeBuild\cmake\debug\armeabi -GAndroid Gradle - Ninja -DANDROID_ABI=armeabi -DANDROID_NDK=C:\SDKs\Android\sdk\ndk-bundle -DCMAKE_LIBRARY_OUTPUT_DIRECTORY=X:\Android\MyApplication\app\.externalNativeBuild\cmake\debug\obj\armeabi -DCMAKE_BUILD_TYPE=Debug -DCMAKE_MAKE_PROGRAM=C:\SDKs\Android\sdk\cmake\3.6.3155560\bin\ninja.exe -DCMAKE_TOOLCHAIN_FILE=C:\SDKs\Android\sdk\ndk-bundle\build\cmake\android.toolchain.cmake -DANDROID_NATIVE_API_LEVEL=23 -DCMAKE_CXX_FLAGS=-std=c++11 -frtti -fexceptions} -- Configuring incomplete, errors occurred! See also "X:/Android/MyApplication/app/.externalNativeBuild/cmake/debug/armeabi/CMakeFiles/CMakeOutput.log". CMake Error at C:/SDKs/Android/sdk/cmake/3.6.3155560/android.toolchain.cmake:356 (message): Invalid Android NDK revision (should be 12): 13.0.3214847-beta2. Call Stack (most recent call first): .externalNativeBuild/cmake/debug/armeabi/CMakeFiles/3.6.0-rc2/CMakeSystem.cmake:6 (include) CMakeLists.txt CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage Error:executing external native build for cmake X:\Android\MyApplication\app\CMakeLists.txt Build command failed. Error while executing 'C:\SDKs\Android\sdk\cmake\3.6.3155560\bin\cmake.exe' with arguments {-HX:\Android\MyApplication\app -BX:\Android\MyApplication\app\.externalNativeBuild\cmake\release\armeabi -GAndroid Gradle - Ninja -DANDROID_ABI=armeabi -DANDROID_NDK=C:\SDKs\Android\sdk\ndk-bundle -DCMAKE_LIBRARY_OUTPUT_DIRECTORY=X:\Android\MyApplication\app\.externalNativeBuild\cmake\release\obj\armeabi -DCMAKE_BUILD_TYPE=Release -DCMAKE_MAKE_PROGRAM=C:\SDKs\Android\sdk\cmake\3.6.3155560\bin\ninja.exe -DCMAKE_TOOLCHAIN_FILE=C:\SDKs\Android\sdk\ndk-bundle\build\cmake\android.toolchain.cmake -DANDROID_NATIVE_API_LEVEL=23 -DCMAKE_CXX_FLAGS=-std=c++11 -frtti -fexceptions} -- Configuring incomplete, errors occurred! See also "X:/Android/MyApplication/app/.externalNativeBuild/cmake/release/armeabi/CMakeFiles/CMakeOutput.log". CMake Error at C:/SDKs/Android/sdk/cmake/3.6.3155560/android.toolchain.cmake:356 (message): Invalid Android NDK revision (should be 12): 13.0.3214847-beta2. Call Stack (most recent call first): .externalNativeBuild/cmake/release/armeabi/CMakeFiles/3.6.0-rc2/CMakeSystem.cmake:6 (include) CMakeLists.txt CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage Error:executing external native build for cmake X:\Android\MyApplication\app\CMakeLists.txt

[fornwall]

Hm, is it intentional that Android Studio on the stable channel offered to update the NDK to r13? I thought r13 was still in a beta version?

[Zingam]

It does it every time.

[DanAlbert]

Hm, is it intentional that Android Studio on the stable channel offered to update the NDK to r13? I thought r13 was still in a beta version?

Definitely not :\

I'll go talk to some people and see what went wrong there. That's likely the problem with cmake here.

[DanAlbert]

Okay, we've pulled the update from the SDK manager for now.

Stable versions of Android Studio seem to be using an outdated version of the SDK manager that doesn't understand stable/beta channels, so the stable Android Studio is pulling the beta NDK (since it's a newer version), which isn't compatible with the stable Android Studio. If you've already picked up the beta NDK with a stable Studio, you'll need to uninstall and reinstall the NDK via the SDK manager.

The downloads will continue to be hosted on the wiki, so if you want to use r13-beta2 with the Android Studio beta you should be able to install it manually to $SDK_LOCATION/ndk-bundle. If you choose to do this, I'd recommend changing the SDK install directory to be separate from the one you use for Android Studio stable so both continue to work (by default they share an SDK).

I'll post updates here as we learn more.

[DanAlbert]

FYI, we've found the issue. It was in the release infrastructure rather than any of the deployed tools, so the fix has already been made. We're going to be pushing r13 beta 2 back into the beta channel (but not the stable one this time!) very soon.

[DanAlbert]

Okay, r13 beta 2 is back in the SDK manager's beta channel.

[Zingam]

Just a side question. In future when a new version of NDK is release will with be supported by Android Studio right away or we'll have to wait for a new Android Studio too?

[DanAlbert]

If the new release of the NDK updates to gradle, yes, you'll need to wait for a new version of gradle. This doesn't necessarily mean it will require a full stable release of Studio. I think their release schedules allow for point releases to the gradle plugin for this sort of thing, but I'm really not all that familiar with how they handle releases.

New NDK releases requiring updates to the gradle plugin is is going to be the case fairly often right now since we've been doing a lot of much needed cleanup with libc++ that unfortunately has caused things to move around and required that things be built differently. I'm hoping this will stabilize in the next few releases, but there is definitely at least one more breaking change that we'll need to make to really make libc++ ready for production use.

[garrytrue]

Today install NDK update to 13.0.3315539 from AndroidStudio
(Android Studio 2.2
Build #AI-145.3276617, built on September 15, 2016
JRE: 1.8.0_76-release-b03 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o) and get same error

CMake Error at C:/Users/tiv/AppData/Local/Android/sdk/cmake/3.6.3155560/android.toolchain.cmake:356 (message):
-- Configuring incomplete, errors occurred!
See also "C:/StudioProjects/NativePlasma/app/.externalNativeBuild/cmake/release/armeabi-v7a/CMakeFiles/CMakeOutput.log".
Error while executing 'C:\Users\tiv\AppData\Local\Android\sdk\cmake\3.6.3155560\bin\cmake.exe' with arguments {-HC:\StudioProjects\NativePlasma\app\src\main\cpp -BC:\StudioProjects\NativePlasma\app.externalNativeBuild\cmake\release\armeabi-v7a -GAndroid Gradle - Ninja -DANDROID_ABI=armeabi-v7a -DANDROID_NDK=C:\Users\tiv\AppData\Local\Android\sdk\ndk-bundle -DCMAKE_LIBRARY_OUTPUT_DIRECTORY=C:\StudioProjects\NativePlasma\app.externalNativeBuild\cmake\release\obj\armeabi-v7a -DCMAKE_BUILD_TYPE=Release -DCMAKE_MAKE_PROGRAM=C:\Users\tiv\AppData\Local\Android\sdk\cmake\3.6.3155560\bin\ninja.exe -DCMAKE_TOOLCHAIN_FILE=C:\Users\tiv\AppData\Local\Android\sdk\ndk-bundle\build\cmake\android.toolchain.cmake -DANDROID_NATIVE_API_LEVEL=9 -DANDROID_PLATFORM=android-9 -DANDROID_TOOLCHAIN=clang}
Invalid Android NDK revision (should be 12): 13.0.3315539.

[simonracz]

Same for me as @garrytrue

[MeteC]

Me too.

Got a step closer to compilation by editing .../Library/Android/sdk/cmake/android.toolchain.cmake and changing the line set(ANDROID_NDK_REVISION 12) to set(ANDROID_NDK_REVISION 13).

Having no real idea what I'm doing.. it seems fine so far?.. (I tried putting set(ANDROID_NDK_REVISION 13) in my cmake file but no cigar.) Disclaimer - actually changing to NDK v13 is messing with everything else in my project since I have to move to clang, and change my STL library, and I'm still not getting compilation - god I've wasted a lot of time on these build tools..

Anyway can anyone tell me if I've just done something terrible? Should I just turn around and somehow downgrade to NDK 12??

[simonracz]

deleting the .externalNativeLibraries folder did the trick to me.

I found this here : https://code.google.com/p/android/issues/detail?id=222068

[MeteC]

oh wow.. you're right. So I went back and undid my hack, brought my cmake back over to gcc from the utterly unhelpful clang-side, and then deleted that hidden folder.

Having to mysteriously delete a hidden folder after a semi-automated tool update is kind of the definition of not user friendly. Losing half a day's work kind of sucks. But I'm happy now at least I'm compiling, thanks @simonracz !

[garrytrue]

many tnx to @simonracz

[DanAlbert]

Apologies for the bad UX here. I checked with the Studio team and it sounds like this issue is already fixed, but it's not in any released Studio version yet (is in 2.2.1).

@MeteC:

brought my cmake back over to gcc from the utterly unhelpful clang-side

Could you elaborate? We can't fix the issues if we don't know about them.

[MeteC]

Right, yes, sorry. So after hacking the android.toolchain.cmake file, my problems were more of a std library kind - I switched over to clang from gcc and immediately couldn't compile lines like

#import <istream> // / <ostream> / <string> / <memory> / <thread> etc etc. 

My ANDROID_STL was c++_shared.

I changed this a bunch of times (gnu_static, gnu_shared, etc) trying to find an stl setup that would give me access to those, which ultimately just left me failing compilation thanks to the std::to_string() method (I have an almost-3rd-party library of code I can't really hack too extensively) - eventually implemented that myself in a shared header.

I then started getting errors like aarch64-linux-android-g++ error unrecognized command line option -Qunused-arguments - so I disabled arm64 compilation and then promptly got arm-linux-androideabi error unrecognized command line option -fno-integrated-as.. and went and had lunch.

At which point I got the word to delete .externalNativeLibraries, and all was well with my old gcc / c++_shared setup.

Wouldn't mind switching to clang already, as it sounds like gcc is being left behind, but at present I can't seem to find access to enough standard libraries with clang.

Anyway hope that's useful somehow...

[DanAlbert]

#import <istream>

Ugh. Why did GCC ever think supporting #import as an alternative to #include was a good idea? This is a deprecated GCC extension, and will probably never be supported in Clang (I have no say in this, but given that GCC has deprecated it I don't see why Clang would want to add it).

failing compilation thanks to the std::to_string method

This is #82. This is going to be fixed as part of the much larger "make libc++ reliable" bug. It's been my primary focus for a while, but it's a large task. This shouldn't be affected by GCC vs Clang though. It's a gnustl vs libc++ issue.

I then started getting errors like aarch64-linux-android-g++ error unrecognized command line option -Qunused-arguments - so I disabled arm64 compilation and then promptly got arm-linux-androideabi error unrecognized command line option -fno-integrated-as.. and went and had lunch.

That's odd. Does this repro after having deleted your .externalNativeLibraries directory? Those flags are guarded behind a check for clang, but the nature of cmake is that it is pretty unforgiving if you change compilers without deleting your configuration (which is what 2.2.1 will do for you). If this is happening even from a clean build, could you file a bug for this with repro steps? It definitely shouldn't happen.

[MeteC]

#import... is a deprecated GCC extension

Oh - sorry, too much Objective-C programming - I meant #include <istream>. It wasn't failing because of #import, it was failing because it couldn't find <istream>.

This is #82... This shouldn't be affected by GCC vs Clang though. It's a gnustl vs libc++ issue.

Odd that I wasn't getting access to to_string() then if it shouldn't be affected by Clang vs GCC? You're saying I should be able to just swap out GCC for Clang and compile just fine?

Does this repro after having deleted your .externalNativeLibraries directory?

Sorry I didn't try - was too delighted that my old setup was working again and too far behind in my day's work to try - but I'm willing to bet you're right, deleting the old configuration would've solved many of those odd headaches.

[DanAlbert]

Oh - sorry, too much Objective-C programming - I meant #include <istream>. It wasn't failing because of #import, it was failing because it couldn't find <istream>.

Oh, that's completely different then. This is something you saw break with Clang? I'd expect this to happen upgrading from r12 to r13 without clearing .externalNativeLibraries because the include paths for libc++ changed, but this shouldn't be something that's just broken in Clang (we have tests that should have caught it). If I'm wrong, please file a bug.

Odd that I wasn't getting access to to_string() then if it shouldn't be affected by Clang vs GCC? You're saying I should be able to just swap out GCC for Clang and compile just fine?

Yeah. The core of that issue is an overly general autoconf check in gnustl that blocks some C++11 features on having a full C99 trig implementation (which we didn't have in gingerbread).

[Keshava11]

Updating ndk from SDK Manager resolved issue in my case.