New Gradle build system for Android platform


#41

I could not reproduce the issue on my rusty Samsung Galaxy Tab 7 running Jelly Bean 4.1. Tested launching a number C++ native samples, and also a number of AS and Lua scripts (via Urho3DPlayer) . It actually works better than I expected, much better than the previous launcher. The back button works now and a different selection can be made in the launcher without forcing to exit it first, like in the past.

BTW, I have just tested building the project via IntelliJ IDEA Ultimate 2018.2 and installed the dev APK to my Galaxy Tab using IDEA. It works as well as Android Studio, IMHO.

In case it makes any difference, I am using SHARED Urho3D lib type.


#42

I was using circleci/android:api-28-alpha docker image to do builds. Nothing unusual appeared in the log files. I think the docker image itself might cause this problem, since there’s the alpha tag on it. Will test out using different image.

Also is there any way how I can reduce the build directory size? When doing ./gradlew build it takes >20GB of HDD space. I found a workaround using ./gradlew assembleRelease -P URHO3D_LUA=0 -P ANDROID_ABI=armeabi-v7a command, but it still took a lot of space. This also might be caused by the faulty docker image tho.


#43

It depends on what you want to build. If you just need the AAR for your own project then just build the lib module and then publish it locally. By default though, it will build both the lib and launcher app (and by that it will include all the 50+ samples). The default uses STATIC lib type so it’s 50+ *.so that all contain the same bits from the STATIC lib. To reduce the size, you can use the SHARED lib type. So it becomes 50+ much smaller *.so, plus “libUrho3D.so”. Note the STATIC lib is not shipped in the APK, while the SHARED lib does.


#44

Come to think about it, I believe it would be worthwhile to rename the “libUrho3D.so” to “libUrho3D_shared.so”, i.e. using the same naming convention as the shared STL runtime lib.

EDIT: after finished making the necessary changes, I have a second thought on this and decided not to commit it. Although I could simplify to remove a pair of Regex with normal string comparison on the Kotlin/JVM side, the changes would slightly complicate things on the CMake side in order to get the desired library output name.


#45

There will be one more way to reduce the APK size for testing, if I have carried out my full plan. I have chosen to setup a multi-modules Gradle build for a few reasons. I have not mentioned it in the https://github.com/urho3d/Urho3D/issues/743 because at that time I was not even sure I could finish the initial work. One of the reason is to be able to have each sample being setup as a module in itself. I imagine user can just choose one of many sample apps in the IDE and be able to build and run the individual APK. This will be similar to how iOS sample apps are being setup currently.


#46

I named my directory path as short as can be but still it complains that the command line is too long. I ask, won’t it be better to break the long command into size-able ones since, as I noticed, that its just a concatenation of commands. Or is there a reason why it must be a whole monolithic chunk.


#47

Sorry to hear that. What is the fully qualified path to Urho3D project in your system and what is the path to Android SDK?

When using CMake, we don’t have the full control of what would be generated by its generator. We can only influence the outcome by configuring some CMake variables, and one of them is to tell it to generate all the command arguments into external response files. But we have already discussed that. There are no other ways I could think of, aside from disabling the IK subsystem if that is the only lib that caused your issue or just graduate from PC and move on to Mac or something better.


#48

Fully qualified path to Urho3D project on my system is

C:\U

and that of my Android SDK is

C:\aSDK

I had to make them as short as possible :expressionless:


#49

Then it is beyond saving… :slight_smile:
Still wondering how my Windows 7 can survive it though. I only disable Lua subsystem, the rest is as per default. And my project path and SDK path are way longer.


#50

:joy:

Can you tell me the exact config file that ninja uses, I’ll like to make some tweaking locally to see if it can work for me


#51

There is no specific config file for ninja, but you can get the inspiration from here to tweak some CMake variables.

Copy those lines and modify them as necessary to a top level CMakeLists.txt or UrhoCommon.cmake. Change the condition to become if (ANDROID AND CMAKE_HOST_WIN32) or something like that. Good luck.


#52

I compiled it successfully on my MacBook Pro (armeabi-v7a only ) .
Installed it successfully on one of my low-cost Android devices.

Launcher
C++ - crashed for every second example (start first example successful , press back , start second example crashed)
AngelScript - works fine , switching successfully between the examples
Lua - works fine , switching successfully between the examples

weitjong thank you for your time and contribution making the build system up to date .

I will try to debug the C++ examples crash issue during the weekend.

Thanks


#54

Did you use STATIC or SHARED lib type? I have only tried SHARED during my testing and the launcher works fine in both an AVD and a real device.


#55

STATIC , real device , Android version 4.4.4
I will collect some logs during the week , once I will have some spare time


#56

I had some time now , before going to work.
Built the shared version (libUrho3D.so) , everything works with no crashing.

SHARED library type , real device , Android version 4.4.4

C++ - works fine , switching successfully between the examples
AngelScript - works fine , switching successfully between the examples
Lua - works fine , switching successfully between the examples

STATIC library type , real device , Android version 4.4.4

C++ - crashed for every second example (start first example successful , press back , start second example crashed)
AngelScript - works fine , switching successfully between the examples
Lua - works fine , switching successfully between the examples


#57

Any update on the debug log or stack trace on the crash? I haven’t got time to reproduce this myself. I am more interested to spend my free time in getting the build script works for downstream project in one form or another, perhaps by creating a custom Gradle plugin.


#58

Sorry , so far I didn’t have much time to debug it thoroughly , can’t find the spare time .

I verified it on additional 3 real devices running Android Marshmallow , Nougat and Pie.
Reproducible 100%

I cherry picked some logs (starting an example , pressing back , starting example)

Running script examples , doesn’t crash

05-29 11:00:02.895 4899 4899 V SDL : onCreate(): com.github.urho3d.launcher
05-29 11:00:03.038 4899 4899 V SDL : nativeSetupJNI(): com.github.urho3d.launcher
05-29 11:00:03.392 4899 5230 V SDL : Running main function SDL_main from library libUrho3DPlayer.so: com.github.urho3d.launcher
05-29 11:00:08.405 4899 4899 V SDL : onDestroy(): com.github.urho3d.launcher
05-29 11:00:08.406 4899 4899 V SDL : nativeQuit(): com.github.urho3d.launcher


05-29 11:00:13.801 4899 4899 V SDL : onCreate(): com.github.urho3d.launcher
05-29 11:00:13.812 4899 4899 V SDL : nativeSetupJNI(): com.github.urho3d.launcher
05-29 11:00:13.966 4899 5308 V SDL : Running main function SDL_main from library libUrho3DPlayer.so: com.github.urho3d.launcher
05-29 11:00:19.941 4899 4899 V SDL : onDestroy(): com.github.urho3d.launcher
05-29 11:00:19.941 4899 4899 V SDL : nativeQuit(): com.github.urho3d.launcher

STATIC library type , 100% crash on the second example

05-29 10:52:02.564 4229 4229 V SDL : onCreate(): com.github.urho3d.launcher
05-29 10:52:02.623 4229 4229 V SDL : nativeSetupJNI(): com.github.urho3d.launcher
05-29 10:52:02.870 4229 4295 V SDL : Running main function SDL_main from library lib06_SkeletalAnimation.so: com.github.urho3d.launcher
05-29 10:52:14.550 4229 4229 V SDL : onDestroy(): com.github.urho3d.launcher
05-29 10:52:14.550 4229 4229 V SDL : nativeQuit(): com.github.urho3d.launcher


05-29 10:52:16.661 4229 4229 V SDL : onCreate(): com.github.urho3d.launcher
05-29 10:52:16.738 4229 4229 V SDL : nativeSetupJNI(): com.github.urho3d.launcher
05-29 10:52:16.954 4229 4363 V SDL : Running main function SDL_main from library lib07_Billboards.so: com.github.urho3d.launcher
05-29 10:52:16.954 4229 4363 V SDL : nativeRunMain(): com.github.urho3d.launcher
05-29 10:52:16.962 4229 4363 E Urho3D : Failed to initialise SDL: Application didn’t initialize properly, did you include SDL_main.h in the file containing your main() function?: com.github.urho3d.launcher
05-29 10:52:16.962 4229 4363 E Urho3D : Failed to initialise SDL subsystem: Application didn’t initialize properly, did you include SDL_main.h in the file containing your main() function?: com.github.urho3d.launcher
05-29 10:52:16.998 4229 4229 V SDL : onWindowFocusChanged(): true: com.github.urho3d.launcher
05-29 10:52:17.037 4229 4363 F urho3d.launche: java_vm_ext.cc:542] from int org.libsdl.app.SDLActivity.nativeRunMain(java.lang.String, java.lang.String, java.lang.Object): com.github.urho3d.launcher
05-29 10:52:17.037 4229 4363 F urho3d.launche: java_vm_ext.cc:542] “SDLThread” prio=5 tid=16 Runnable: com.github.urho3d.launcher
05-29 10:52:17.037 4229 4363 F urho3d.launche: java_vm_ext.cc:542] native: #12 pc 005172b3 /data/app/com.github.urho3d.launcher-JdHf8rw-C4QWZI0dx2k58g==/lib/arm/lib07_Billboards.so (SDL_AndroidGetInternalStoragePath+110): com.github.urho3d.launcher
05-29 10:52:17.037 4229 4363 F urho3d.launche: java_vm_ext.cc:542] native: #13 pc 00512c8f /data/app/com.github.urho3d.launcher-JdHf8rw-C4QWZI0dx2k58g==/lib/arm/lib07_Billboards.so (SDL_GetPrefPath+18): com.github.urho3d.launcher
05-29 10:52:17.037 4229 4363 F urho3d.launche: java_vm_ext.cc:542] native: #18 pc 00324155 /data/app/com.github.urho3d.launcher-JdHf8rw-C4QWZI0dx2k58g==/lib/arm/lib07_Billboards.so (SDL_main+28): com.github.urho3d.launcher
05-29 10:52:17.038 4229 4363 F urho3d.launche: java_vm_ext.cc:542] native: #19 pc 00517035 /data/app/com.github.urho3d.launcher-JdHf8rw-C4QWZI0dx2k58g==/lib/arm/lib06_SkeletalAnimation.so (Java_org_libsdl_app_SDLActivity_nativeRunMain+1028): com.github.urho3d.launcher
05-29 10:52:17.038 4229 4363 F urho3d.launche: java_vm_ext.cc:542] native: #20 pc 00006411 /data/app/com.github.urho3d.launcher-JdHf8rw-C4QWZI0dx2k58g==/oat/arm/base.odex (offset 6000) (org.libsdl.app.SDLActivity.nativeRunMain+160): com.github.urho3d.launcher
05-29 10:52:17.038 4229 4363 F urho3d.launche: java_vm_ext.cc:542] native: #28 pc 0007f2d8 /data/app/com.github.urho3d.launcher-JdHf8rw-C4QWZI0dx2k58g==/oat/arm/base.vdex (org.libsdl.app.SDLMain.run+96): com.github.urho3d.launcher
05-29 10:52:17.038 4229 4363 F urho3d.launche: java_vm_ext.cc:542] at org.libsdl.app.SDLActivity.nativeRunMain(Native method): com.github.urho3d.launcher
05-29 10:52:17.038 4229 4363 F urho3d.launche: java_vm_ext.cc:542] at org.libsdl.app.SDLMain.run(SDLActivity.java:1004): com.github.urho3d.launcher
05-29 10:52:17.214 4229 4363 F urho3d.launche: runtime.cc:558] “SDLThread” prio=5 tid=16 Runnable: com.github.urho3d.launcher
05-29 10:52:17.214 4229 4363 F urho3d.launche: runtime.cc:558] native: #17 pc 005172b3 /data/app/com.github.urho3d.launcher-JdHf8rw-C4QWZI0dx2k58g==/lib/arm/lib07_Billboards.so (SDL_AndroidGetInternalStoragePath+110): com.github.urho3d.launcher
05-29 10:52:17.214 4229 4363 F urho3d.launche: runtime.cc:558] native: #18 pc 00512c8f /data/app/com.github.urho3d.launcher-JdHf8rw-C4QWZI0dx2k58g==/lib/arm/lib07_Billboards.so (SDL_GetPrefPath+18): com.github.urho3d.launcher
05-29 10:52:17.214 4229 4363 F urho3d.launche: runtime.cc:558] native: #23 pc 00324155 /data/app/com.github.urho3d.launcher-JdHf8rw-C4QWZI0dx2k58g==/lib/arm/lib07_Billboards.so (SDL_main+28): com.github.urho3d.launcher
05-29 10:52:17.214 4229 4363 F urho3d.launche: runtime.cc:558] native: #24 pc 00517035 /data/app/com.github.urho3d.launcher-JdHf8rw-C4QWZI0dx2k58g==/lib/arm/lib06_SkeletalAnimation.so (Java_org_libsdl_app_SDLActivity_nativeRunMain+1028): com.github.urho3d.launcher
05-29 10:52:17.214 4229 4363 F urho3d.launche: runtime.cc:558] at org.libsdl.app.SDLActivity.nativeRunMain(Native method): com.github.urho3d.launcher
05-29 10:52:17.214 4229 4363 F urho3d.launche: runtime.cc:558] at org.libsdl.app.SDLMain.run(SDLActivity.java:1004): com.github.urho3d.launcher


#59

Hi,

I tested the new gradle build in my Ubuntu 16.04 machine. It works quite well except a few issues / questions I have. Maybe specific to my machine setup and configuration though.

  1. java heap out of memory error
    I got java heapspace out of memory exception. The problem is gone after I increased the heap size to 8G in the gradle.properties file.

  2. ccache permission error.
    I got ccache permission error as my g++ during the initial build process. The issue is caused by improper setup oft he ccache. The which g++ command shows the g++ is pointed to /usr/bin/g++ instead of /usr/lib/ccache/g++. Resolved the issue after fixing this help (https://askubuntu.com/questions/470545/how-do-i-set-up-ccache)

  3. The build process took quite a while (maybe my machine is not that fast). It seems the build process compile the source files multiple times. Is it correct it has to do with the number of android API installed in the system, meaning each file will be compiled for each API level?

  4. At the end, I am able to deploy all the launcher with all sample applications to my Nexus 7 device. The issue I have here is, the apks created are quite big (the debug apk is around 1.35G)
    and take a while to deploy to the device.
    How do I deploy my application only in this new process? I basically added my application as a new application in the samples folder and re-use everything for building the app.

  5. Intermittent runtime exception when launching a sample application in the android device. It seems this problem apply for all sample applications. The application can run successfully the second time you launch it though.


#60

Thanks for the feedback. As you aware our Gradle build system is still very new and still in active development in the master branch, you should expect things not working and things being drastically changed during the process. So at this moment, I actually do not recommend it to be used for your own project just yet, unless you are a technically inclined person. I will try to address/answer your issues/questions below though.

Initially when I started the development of this new Gradle build system, I also had a memory issue. But it was caused by my host system memory really not having enough RAM. After upgrading from 8GB to 16GB then I have not encountered any memory issues again. I notice that Android Studio (or IntelliJ IDEA) is quite a memory hog by itself, so for those who don’t have enough RAM then trying the Gradle build system using CLI may be a better option. The Travis-CI has a low CPU and memory specs and yet it runs our Gradle build system just fine with the default JVM heap size.

This is a common pitfall for Ubuntu distro. Fedora, the distro that I use, will setup the PATH environment variable correctly after the ccache package is installed. You probably need the following line as well as in our CI (which also uses Ubuntu) to fix the mistake of the Ubuntu ccache package.

No, it is not due to the API level. By default the Android plugin for Gradle will build for 4 ABIs (x86, x86_64, armeabi-v7a, and arm64-v8a) and it will also build for 2 build-configs (Debug and Release). Thus, by default there will be 8 build trees being generated. You can, however, limit the number of ABIs by specifying the ANDROID_ABI property. See the documentation for more detail:

By default our build system uses STATIC library type. This has been discussed and commented before in this thread so I won’t repeat myself again. If you want smaller APK size, use the SHARED library type; OR don’t build the sample at all (URHO3D_SAMPLES=0) and just keep the URHO3D_PLAYER=1, so the launcher only contains the Urho3DPlayer app which is more than enough to demonstrate the launcher capability for playing the AngelScript and Lua scripts.

The build system is not designed to be used in this way.

This is a known issue and has been reported by @elix22. I/we don’t have time to debug it yet. You are welcome to contribute the fix.


#61

Hi, thank you for the clear and detail responses to all my questions. Fully understood this new build process is quite complex and would take time to streamline. I think it is pretty smooth already at this stage. It is almost a one tick process from start to complete :slight_smile:
I don’t have much experience in Android platform but if I find something I can contribute in the future, I definitely will. Thank you again.