Publish documentation of command line android build of SDK and Samples #42
Comments
|
Android build system is very poorly set up at the moment, but unfortunately we now have no bandwidth to improve it and any help would be greatly appreciated. |
|
Command-line build will also enable running Android build on CI servers as right now it is the only platform that is skipped by CI |
|
Ok, so yeah, that's something I'd like to make sure we can automate. I feel like Android Studio makes some things easier (recommending fixes for missing components), but when it fails, it can be puzzling. In most cases one can get better information from the command line build with gradle. I'll see what I find. |
|
Will look into this over the weekend. |
|
First problem I ran into was related to Error:Could not find com.android.support.constraint:constraint-layout:1.0.1 required by AntTweakBar. I did a search on this in the mvn repositories (it is a support library), and it is not in mvnrepository, oddly, so is probably packaged by the Android Studio version, but not determined what version. Lots of people have hit this problem on other projects. The best thing to do is change all versions of this support lib from 1.0.1 to 1.1.0, as that is in the mvnrepository. |
|
I'll propose a fix for the above, on to the next issue: Task :Common:generateJsonModelDebug fails with a cmake error (probably NDK related). Need to investigate. |
Where is it specified? Can't find it in Gradle files or in the project generally. BTW, do you have the latest code? I recently made few changes/fixes on Android |
|
Oh, let me pull the latest. All of these constraint things are in the samples: |
|
Yeah, I double checked the history and these were indeed removed recently |
|
Ok, that was a good update, fixed that last problem. Hit a new one: Probably something I'm missing in my support libraries or SDK version. Looking into that. |
|
I'll revisit this later in the week (SDK updating right now), and I have to jump onto something else. |
|
Thanks for looking into this. |
|
As an aside, since I am only building with gradlew + a standalone Android SDK, I have to go through this trial and error. The Android Studio will usually suggest/recommend fixes that will often work. However, I have to sort out the meaning of the errors. There are a lot of moving parts (platform/os, SDK tool version, support libs, ndk tool version, cmake version, and probably a few other things I forgot). I'll keep digging. Those errors are probably some library version or tools version that I am missing. |
|
You are right. Android studio indeed suggests installing a number of components. Maybe if you install it and open the project, you will know what components are missing. |
|
So as far as this error: it appears that this can be fixed by adding: compileSdkVersion 28 to the build.gradle in the offending project AntTweakBar. |
|
I'm getting another error after fixing the last one in the cmake section of building AntTweakBar |
|
So this above issue is a problem with the changes to the NDK. @DiligentGraphics unfortunately for maintainers, SDK tools, OS versions, and support tools provided by the Android SDK toolchains don't stand still, and stuff that might build perfectly in your configuration might not on another system due to the variety of differences that might exist. It is sometims necessary to save off versions of tools in case things aren't being archived by Google (I think for the most part they do archive things, but they've moved away from the standalone SDK tools to Android Studio, which pushes the burden of maintaining Studio also. The ideal strategy that I use is to lock down configuration and make sure that I document what I'm using, such that anyone else picking up my project will be able to use the same versions and be guaranteed success in the build. Use something different and the guarantees are completely thrown off. I think that's where this is at, unless you are telling me that you've got other people building on other systems for you to validate and that maybe it's my configuration that's crazy. In any case, I'll keep plugging away here until I nail down a configuration that works. My team is sufficiently motivated to get the samples working and making builds reproducible. |
|
So the above C++ / cmake issue mentioned is down in the guts of the NDK. Probably with NDK 19 or sometime earlier, they no longer support gnustl_static. To fix this requires a change to: Common/NativeApp/Android/build.gradle and change the line for the cmake and just don't specify the STL That fixes the other bug I hit. |
|
In the midst of building [19/65] Linking CXX static library DiligentTools/TextureLoader/libTextureLoader.a I get about 20 errors, starting with: |
|
I'm going to try on an older setup with an older sdk / ndk. These problems maybe are due to the change away from the gnustl-static. |
|
Do you get this error after removing |
|
In Android Studio, the build succeeds with the following build settings: I can't understand why it causes so many errors in a standalone toolchain. |
|
BTW, are you able to build the teapot sample from android ndk samples (which is where I copied the settings from)? |
|
So not sure as far as why the standalone toolchain is having an issue, but as I said, I'm on Mac OS X, exactly same errors with Android Studio as with building from the command line. I'm using the same toolchain, just that Android Studio manages the tools that get installed. My belief is these Android build issues are 95% of the time configuration issues, not necessarily a bug in the settings per se or code issues. In other words, something in my environment, tools versions, or other binary that might be in my path that doesn't match the settings or api version. |
|
In terms of the gnustl static issue, described in this error message below, that's just an NDK version issue. If you are still on an older NDK that won't affect your build. So the first question is, what NDK version do you have installed? I'll separately confirm that the teapot builds. gnustl_static is no longer supported. Please switch to either c++_shared |
I do use c++_static, but you said it generates an error. I'm little confused now. |
|
@DiligentGraphics so if you don't mind, can you state which version the Android NDK you are using? A second point, that I forgot was that this project has submodules, and to keep everything working together, I have to remember to do the git submodule update step. I'm setting up a windows system with a pure command line set up (Google has un-hidden the Android Command Line SDK tools). I'll keep the mac with the Android studio. About to retest |
|
So after resetting my workspace back to a clean state and doing a submodule update --recursive, I get an error I've seen before on other projects. Ran a ./gradlew after setting the gradlew to be executable. So on a non-linux platform, we aren't going to have mips64el-linux-android cross compiler under the toolchains. That affects windows and mac. The solutions are numerous, but I'll refer to the Google Filament issue as somewhat authoratative: The second to last solution worked for me. Continuing to build. |
|
I currently have NDK 19.1 |
|
running: gradlew build hits the same problem seen in comment: #42 (comment) Before I repeat the entire sequence of errors that I found previously, what tag or branch should I be building from, if not tag v2.4.b? |
|
The head right now is in a good shape and everything should work fine. v2.4.b is quite old. |
|
Let me switch to do that. I was going off the instructions on the project https://github.com/DiligentGraphics/DiligentEngine#cloning-the-repository I'll switch to HEAD if that's working. Yes, it looks like that tag is from way back in Jan or Feb. |
|
Switching to head. Numerous problems gone away. |
|
The above picture of the Android "config" might be enough to help support documentation of the Android build. I'd suggest embedding that into the Android section of the docs. |
So did you manage to build it or some issues still remain?
I can add Android NDK and build tools version to the section. |
|
It's building now from HEAD, not from the documented tag. I'd suggest that the Android section should recommend a particular tag that works for android, or tell people to gamble on the HEAD. And when I say it's building now, I think it will build overnight. It's been cranking for an hour, so I think it will finish, but it's only at 8%. Blame gradle and an artificially slow mac. |
|
Also confirmed I can build teapot. So this was all completely because I followed the instructions (the problems found). In any case, I'll document the gradlew commands that people can use, and this should allow you to cut over to a CI server type environment for builds and maybe testing. |
|
As far as making this build as an included library or something in an external project, I think that's a different effort. If my team is going to use this, I have to figure that part out too. I want to be able to distribute the code we are working on without having to also include the SDK in our repository. I'll try to figure that out on a different issue once I see this running on a phone or whatever. |
|
Darn ... I spoke to soon, build fails during linting: |
|
I think I can force it to skip linting. I'm assuming those are things that don't matter. It claims to have found an error: Some methods, such as View#onDetachedFromWindow, require that you also call the super implementation as part of your method. |
|
I'll let this run again, not sure but I may have to suppress the lint warnings within each occurrence. |
|
Will check in on this tomorrow. |
|
Probably the Android Studio has some built in settings to ignore these warnings or errors. |
|
I updated all tools to the most recent versions and everything builds fine (though there are some clang warnings). |
|
No, I don't explicitly ask for a lint , however, the default ./gradlew build will end up running a lint target. I am able to disable it with: ./gradlew build -x lint I think the effort is different here. I'm building from the command line with gradle. The configurations will be different as Android studio has defaults that it may enforce, as well as user defaults per project. When you finally hook up your project to a nightly CI build, you will probably have times where the CI will fail but you will be looking at Android Studio and you will think "works for me". So with the lint ignored, the build completes. I will see about the commands to install on device, and just verify these final steps of actually getting it running on a real device. |
|
I am wondering why Android is such a headache. Other 5 platforms were very straightforward to set up. |
|
I've been dealing with it since 2007. The tools are not bad, and I can't complain that they are free. However, sometime back Google decided Gradle was better, because ... ? I guess because that's what Jetbrains/Android Studio was built on as a build tool, and this caused years of difficulty, probably 8 years to get the tools to the point where it just worked pretty well, but native NDK integration was still a challenge. Android had traditionally used these Android.mk files which is sort of a specialized GNU Makefile. It was goofy but it worked. Google had a few years where it seemed like they didn't know how to deal with the native integrations via gradle. But then they moved to the cmake plugin for gradle. That's been a mixed bag, but I think mostly good long term. As for the weird errors that are on the java side, that's mostly compatibility stuff and api issues. Google releases a lot of new code every year. It's a mess to keep up with. I recommend maintaining as low an api compatibility support level as possible, as it will ensure the code runs on the most devices. Avoid the temptation to lock on to new Android features. Android users typically aren't able to upgrade to the latest Android without buying a new device, so many will be stuck on an old OS for 2-3 years, or the duration of owning a particular device. |
|
Yeah, I originally used NDK build, and it wasn't always very easy. Besides, the project was much smaller and only supported couple of platforms. The fact that they made CMake their native build system simplified the problem dramatically. At least with the native part I have very few problems and when I do they are most of the time very clear and easy to fix. It is the Gradle part that I dont fully understand and that causes all wierd issues. I'm targeting API level 21 I guess which should be pretty ok |
|
Yeah, I guess the point is with Android, unlike with iOS, Google doesn't have a good scheme to push people forward onto the latest OS. That's really up to carriers and or 1st tier phone manufacturers to determine if they want the newer OSs. And in large part, people stay on older OSs for a long time. Great that you guys are sticking with API 21 actually. |
|
do you still need help? if so i think i could help a lot with getting this to build on android :) |
|
We now have the command-line build set up. The build runs on every commit as part of CI |
Ideally, users of Android could build from the command line, assuming necessary components are installed from the SDk. It would be great to have the gradle commands documented to build specific projects and also necessary commands install install/run/debug. Possibly related to #41. I've done this for other projects, specifically figured it out for the messy Oculus Android SDK (a monolithic Android SDK/examplewad that cannot be separated). I'll poke around around on this to see if I can tease out the commands from the ./gradlew step to bootstrap and the available commands. This assumes too a few pre-reqs: NDK, android SDK tools, android SDK API versions (what is min needed, what is target), any hardware support needed (I think this is posted somewhere in the root level docs), and Java tools that should be in place (openjdk version).
The text was updated successfully, but these errors were encountered: