Within my android app, gradle build job taking so much time to get complete. By making single line change in code, taking around 2 hours to run the app and see the changes in app behavior. Following are the actual setup in my project:
Gradle version: 4.1.3
Gradle wrapper version: 6.5.1
Compile SDK: 30
Number of modules in app: 72
Any input or suggestions will be welcomed.
Related
So I was building out a test APK in Android Studio tonight that had to be signed. It failed and said my Gradle was out of date. So I upgraded my gradle from 7.3.3 to the newest 7.5.1
I changed the wrapper setting to distributionUrl=https\://services.gradle.org/distributions/gradle-7.5.1-all.zip
and then I changed my build.gradle dependency to classpath 'com.android.tools.build:gradle:7.5.1'
Note that after doing the changes, and restarting Android Studio, it did upgrade the version in the app directory.
Here's the error getting thrown below:
* What went wrong:
A problem occurred configuring root project 'android'.
> Could not resolve all files for configuration ':classpath'.
> Could not find com.android.tools.build:gradle:7.5.1.
Searched in the following locations:
- https://dl.google.com/dl/android/maven2/com/android/tools/build/gradle/7.5.1/gradle-7.5.1.pom
- https://repo.maven.apache.org/maven2/com/android/tools/build/gradle/7.5.1/gradle-7.5.1.pom
Required by:
project :
Note that this was a project from a client, and I did not write this originally. These dependencies were in place, but fairly recent, and the app would build fine with it using 7.3.3. However it wouldn't let me sign my app.
I suppose I could use some wisdom on both of these issues. What I'm going to do is go back to version 7.3.3, build the signed APK again, and copy that exact error to report back here with. It was a gradle version error.
For any any Flutter noobs like myself passing through, this error occured because the Android Tools Plugin version DOES NOT match the Gradle Version:
https://developer.android.com/studio/releases/gradle-plugin#groovy
They match up just vaguely enough in number, that you would think that my line com.android.tools.build:gradle:7.5.1. uses gradle 7.5.1, but instead, Android Tools for Gradle is actually a separate entity, and at 7.3.3 as of typing this reply.
So you CAN set your Gradle to the newest version somewhere else in your project, but it has to match the compatible Android Tools version, which is set here. Its silly and confusing at first, and can easily trip up newcomers. Hopefully the versions diverge enough, or the code syntax changes for some better clarity, but as of now, this is it.
When building my android project via a github action, it always fails when the server hosting the action updates it's NDK plugin versions. This requires me to update my versions as well. However, it never seems to be simple.
For example, in a recent update I just made I noticed the NDK version was behind the server. So I downloaded the new version it's using to my local machine and updated the build files (including the local NDK path). After ensuring it builds fine on my local machine, I push to my branch. However, the server still thinks it's trying to build on the old version and fails the build (even though I told the gradle script to use the new version.).
I can successfully make this update on master, is there some reason actions/checkout#v2 doesn't recognize build file updates to non-master branches?
Welcome to Gradle 6.1.1!
Here are the highlights of this release:
- Reusable dependency cache
- Configurable compilation order between Groovy/Kotlin/Java/Scala
- New sample projects in Gradle's documentation
For more details see https://docs.gradle.org/6.1.1/release-notes.html
Starting a Gradle Daemon (subsequent builds will be faster)
> Configure project :app
WARNING: Support for ANDROID_NDK_HOME is deprecated and will be removed in the future. Use android.ndkVersion in build.gradle instead.
Support for ANDROID_NDK_HOME is deprecated and will be removed in the future. Use android.ndkVersion in build.gradle instead.
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring project ':app'.
> No version of NDK matched the requested version 21.3.6528147. Versions available locally: 21.4.7075529, 21.4.7075529, 21.4.7075529, 22.1.7171670
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 24s
Error: Process completed with exit code 1.
I have an Android Studio NDK module with about 200 small C files I'm trying to build as a native library. When I do a build either from within Android Studio or from the command line with gradlew, the build process hangs part way thru compiling one of the files. Which file it hangs on is random from build to build. When the build hangs the only recourse is to kill the clang process(es) and try again. On rare occasions it will actually complete.
One guess I have is that there is some windows issue with multiple simultaneous compiles for the module. Is there a way to force make to use -j1 to test this?
Are there other reasons the build would hang?
Environment - Windows 10, Android Studio 2.3.3, Gradle 3.4.1
Lately, I encounter a lot of problems using Android Studio.
I'm using Android Studio 1.5.1, with gradle plugin 1.5.0 (corresponding to Gradle 2.2.1, I think), on Windows 7.
There is no update for Android Studio for now, and neither in standalone SDK manager.
Sometimes when I try to launch my app on an emulator, the builing process wont stop (I waited for 1 hour once...). Even after I quit the emulator and just build project on sync gradle, it launch a process that never ends. The log file is not writing and there is no error message anywhere.
For the process to end, I have to go to the taskmanager and stop every java.exe process I see, and it then shows this message :
Error:Unable to start the daemon process. This problem might be caused
by incorrect configuration of the daemon. For example, an unrecognized
jvm option is used. Please refer to the user guide chapter on the
daemon at https://docs.gradle.org/2.8/userguide/gradle_daemon.html
Please read the following process output to find out more:
-----------------------
After that, not any build will succeed, and the only way for my project to successfuly build is to reboot my OS ! (even after taskkilling every known related task, like android64.exe, adb.exe, java.exe)
Is the bug known ? Is there any workaround ? Am I doing something wrong ?
Further details
When it bugs, the gradle console is writing
Executing tasks: [:app:generateDebugSources, :app:generateDebugAndroidTestSources, :app:compileDebugSources, :app:compileDebugAndroidTestSources]`.
, but then nothing. It's more that gradle is not working than it's stroking on one point. But there still is that java.exe process with its 66Mb of memory...
It bugs after approximately 8 successful runs.
Last updates
I know now the real troublemaker ! It is C:\Users\Me\.gradle\daemon\2.8\registry.bin
I can't even right click on it without crashing Windows Explorer !
I have been facing the same problem. However, I had a previous project which had been successfully built. What I did was - changed the location of Service Directory Path(the one pointing to the '.gradle' folder) of my new app to the Service Directory Path of the successfully built app, i.e from
C:/Users/YOUR USERNAME/AndroidStudioProjects/CURRENT APP/.gradle
to
C:/Users/YOUR USERNAME/AndroidStudioProjects/SUCCESSFULLY BUILT APP/.gradle
To change the service directory path-
go to settings --> Build, Execution, Deployment --> Build Tools --> Gradle --> service directory path
I am trying to upgrade a library from vs2010 to vs2012. It is a single sln file with 35 projects. I use devenv.com to build it. The example command to do this looks something like:
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools..\IDE\devenv.com" /rebuild "Release|x64" singlesolution.vc12.sln
The behavior is intermittent. It would fail with 2 succeeded projects and 33 failed projects on first invocation. On 2nd invocation it would pass with all 35 successfully built. And on 3rd invocation it would fail. I have switched off the number of parallel builds by setting maximum parallel builds to 1.
Could you please suggest me where i am going wrong? Is this a known behavior with vs2012?