New Gradle build system for Android platform

I have pushed the initial Gradle build system for Android to gradle-kotlin-dsl development branch. It is still WIP. I haven’t finished clean up the CMake build script to remove now old and redundant fixtures for Android build. I have only tested it on Linux host system with symlink workaround I mentioned in The workaround only works when invoking gradle wrapper from the CLI (Still haven’t figured out how to prevent the Android plugin bug to manifest itself during Android Studio “gradle sync”). However, if you don’t modify the gradle build script in Android Studio editor then you should not see the problem at all. Please test the build system on Urho3D project only, or if you want to try it on your own project then make sure you have a proper backup plan due to symlink bug. You have been warned.

For CLI user, after checking out the development branch, cd to the Urho3D project root and run:

./gradlew build

For Android Studio user, open the project using the IDE. It should prompt you to auto-import the Gradle project. Before building the project, press Ctrl+Alt+S and type “configure on demand” in the search box, locate the option and deselect it.


Just managed to get the Android CI build run successfully this morning. In the process I found out one more thing user need to do in order to build successfully. The Android plugin has opinionated to use “ninja” build (not surprising as it was created by Google too) instead of the usual GNU Make. However, it is done by specifying a hard-coded path to the SDK embedded “ninja” command. This is fine for CMakeLists.txt file that the plugin invokes directly. It does not cater for any “external” invocation indirectly done by our CMake scripts and therefore the overall CMake configuration ends up with a failure because of “ninja” command is not found. So, user needs to either:

a) install ninja-build globally, or b) adjust the PATH env var to include the path to SDK embedded “ninja” command, or c) change the default make program to GNU Make, this require modifying the provided build.gradle.kts though.

Edit: this prerequisite is not needed anymore as the new build script will automatically pass along the path to embedded “ninja” when invoking CMake in external child process.

Should we not simply use gradle all the time?

Not sure I understand you. Gradle by itself has nothing to do with Android build. It is the Android plugin for Gradle does. But the standard Android plugin does not cater for all our needs. How it trips up on handling symlink is just one example.

I guess i am not sure what that means. Project i am working on - i never touch cmake directly in android builds. Always use gradle (either from android studio or cli) and it takes care of calling cmake. Is that not an option?

I am sorry if I cannot make it clearer. English is not my primary language. The Android plugin does not scan the root CMakeLists.txt and all its children, so it does not know when somewhere in the script it spawns child processes that calls external CMake to load other CMakeLists.txt files. The latter is the problem because the plugin could not inject the hard-coded path to “ninja” for those external invocation as it could do for root CMakeLists.txt.

Ah i see. Build system overhere does not do any of that so that is why i had no issues. Sorry for the noise :wink:

The external invocation are mainly for host tool building.

I have made another push to the dev branch. Our new Gradle build system is almost ready for general use now. The earlier issues with Gradle sync and “configuration on demand” in Android Studio should now be resolved. It should work out of the box as it can be. Feedback is most welcome, especially for those testing it on Windows host system.

Due to yet another bug in Android plugin, I am forced to use a symlink to configure the asset directory. Check the github comment if you want more detail. So for Windows users, after checking out the branch, you may have to perform a manual copy to prep the asset dir for now.


Sounds good! Will check this out!

Fails on my Windows machine

Partial log

Task :android:urho3d-lib:generateJsonModelDebug
Variant=debug ABI=armeabi-v7a :-- Check for working C compiler: C:/Users/bea034/AppData/Local/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
Variant=debug ABI=armeabi-v7a :-- Check for working C compiler: C:/Users/bea034/AppData/Local/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe – broken
Variant=debug ABI=armeabi-v7a :CMake Error at C:/Users/bea034/AppData/Local/Android/sdk/cmake/3.6.3155560/share/cmake-3.6/Modules/CMakeTestCCompiler.cmake:61 (message):
Variant=debug ABI=armeabi-v7a : The C compiler
Variant=debug ABI=armeabi-v7a : “C:/Users/bea034/AppData/Local/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe”
Variant=debug ABI=armeabi-v7a : is not able to compile a simple test program.
Variant=debug ABI=armeabi-v7a : It fails with the following output:
Variant=debug ABI=armeabi-v7a : Change Dir: C:/GAME-ENGINES/Urho3D-gradle-kotlin/android/urho3d-lib/.externalNativeBuild/cmake/debug/armeabi-v7a/CMakeFiles/CMakeTmp
Variant=debug ABI=armeabi-v7a :
Variant=debug ABI=armeabi-v7a : Run Build
Variant=debug ABI=armeabi-v7a : Command:“C:\Users\bea034\AppData\Local\Android\sdk\cmake\3.6.3155560\bin\ninja.exe”
Variant=debug ABI=armeabi-v7a : “cmTC_127a9”
Variant=debug ABI=armeabi-v7a : [1/2] Building C object CMakeFiles/cmTC_127a9.dir/testCCompiler.c.o
Variant=debug ABI=armeabi-v7a : FAILED: null
Variant=debug ABI=armeabi-v7a : C:\Users\bea034\AppData\Local\Android\sdk\ndk-bundle\toolchains\llvm\prebuilt\windows-x86_64\bin\clang.exe
Variant=debug ABI=armeabi-v7a : --target=armv7-none-linux-androideabi
Variant=debug ABI=armeabi-v7a : --gcc-toolchain=C:/Users/bea034/AppData/Local/Android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64
Variant=debug ABI=armeabi-v7a : --sysroot=C:/Users/bea034/AppData/Local/Android/sdk/ndk-bundle/sysroot
Variant=debug ABI=armeabi-v7a : -isystem
Variant=debug ABI=armeabi-v7a : C:/Users/bea034/AppData/Local/Android/sdk/ndk-bundle/sysroot/usr/include/arm-linux-androideabi
Variant=debug ABI=armeabi-v7a : -D__ANDROID_API__=17 -g -DANDROID -ffunction-sections -funwind-tables
Variant=debug ABI=armeabi-v7a : -fstack-protector-strong -no-canonical-prefixes -march=armv7-a
Variant=debug ABI=armeabi-v7a : -mfloat-abi=softfp -mfpu=vfpv3-d16 -mthumb -Wa,–noexecstack -Wformat
Variant=debug ABI=armeabi-v7a : -Werror=format-security -fPIE -o
Variant=debug ABI=armeabi-v7a : CMakeFiles/cmTC_127a9.dir/testCCompiler.c.o -c
Variant=debug ABI=armeabi-v7a : C:\GAME-ENGINES\Urho3D-gradle-kotlin\android\urho3d-lib.externalNativeBuild\cmake\debug\armeabi-v7a\CMakeFiles\CMakeTmp\testCCompiler.c
Variant=debug ABI=armeabi-v7a : CreateProcess failed: The system cannot find the file specified.
Variant=debug ABI=armeabi-v7a : ninja: build stopped: subcommand failed.

Do you have “Android SDK Platform 17” package installed? I believe you need API level 17 for 32-bit ABI and level 21 for 64-bit ABI. Alternatively, if you have other higher API level installed in your system then you may try to reconfigure the “minSdkVersion” setting in the build.gradle.kts.

Yes I have them all installed from API level 10 till API level 28 .

I guess it has todo with the CMake compiler check option , it tries to compile “testCCompiler.c”
I guess this option should be disabled

That test is part of how CMake perform the initial configuration. I don’t think it should be skipped. Have you checked the CMakeFiles/CMakeError.log located inside the .externalNativeBuild dirctory? or Have you tested your Android SDK installation to build other things successfully?

Yes I have tested it On Godot just now , compiled Godot for Android successfully, followed the instructions in this link .

C:\godot> scons platform=android target=release
C:\godot> cd platform/android/java
C:\godot\platform\android\java> gradlew build

I think you misunderstood me. You have to test the Android SDK + Android NDK with the CMake as the build system for the native library. Godot uses SCons as the build system for the native library, so it does not prove anything here.

Can you post to somewhere the content of your CMakeError.log? It might give some clues why the initial compiler detection failed in your case.

Scons in Godot = CMake in Urho3D .
Both are using the same SDK + NDK underneath .

I will upload CMakeError.log by tomorrow (going home now).
In addition I will try later today at my home on another laptop .

If your error happened somewhere else and not at the CMake initial configuration then your comparison with Godot could make sense. However in your case, the failure you had is with CMake and that is one thing Godot does not have. So, your Godot build success does not mean your Android SDK/NDK/CMake installation on Windows is good or bad. It does not prove anything at all for the problem you faced.

I agree.
I am sorry I will provide you more information by tomorrow .