Taking a lot of time to build gradle - android

I'm doing a project in my office in Android Studio, it was working fine there.
But when I open the same project in my personal laptop in Android Studio it's taking a lot of time to build gradle.
Please, does anyone have a solution?

I have also face same problem, actually your personal laptop not compatible to run android studio, in the documentation of android they mentioned that 4 GB RAM is sufficient but my personal experience said that RAM should be 8 GB, its also depend on your operating system in MAC os android studios running smoothly then in Linux its also give good performance but in Windows its creating a problem, i think you need to upgrade your RAM.

Add this line to the file:
org.gradle.daemon=true
From now on Gradle will use a daemon to build, whether you are using Gradle from command line or building in Android Studio. You could also place the gradle.properties file to the root directory of your project and commit it to your SCM system. But you would have to do this, for every project (if you want to use the daemon in every project).
Note: If you don’t build anything with Gradle for some time (currently 3 hours), it will stop the daemon, so that you will experience a long start-up time at the next build.
Note: Performance improvements are one of the great tasks in the Gradle roadmap for 2014 (and reaching into 2015). So I hope, we’ll see the general performance increasing within these years.
Note: This does only affect console builds. Android Studio always uses a Gradle daemon (and depending on your settings some other optimizations).

Found the reason!! If Android Studio has a proxy server setting and can't reach the server then it takes a long time to build, probably its trying to reach the proxy server and waiting for a timeout. When I removed the proxy server setting its working fine.
On Windows File > Settings > Appearance & Behavior > System settings > HTTP Proxy

Related

Default Android Studio compiler to offline, but also download things that's necessary

I am traveling in China for a few month and the network connectivity is weak due to the great fire wall. I have found enabling Offline work in Gradle setting super helpful. It reduced my compile time from a few minutes to a few seconds when I make a minor change in the build.gradle file.
However, I still need to manually turn it on and off if I introduce a new library to my project. So here comes my question:
Is there a way to default to Offline work and still download new library when needed?
you can use following build command from android studio terminal.
gradlew --offline assembleDebug

Android Studio AVD, CRASH, GRADLE PROBLEMS, cannot start up

The AVD fails to load, it doesn't recognise it. It asks me to run this manually, which I did via: "Run as Administrator" on android.bat found in the Android local, platform-tools folder.
I also did all the necessary SDK-platform and tools update for the relevant devices, etc. Still doesn't work.
I followed also a lot of 50 topics on Stack Overflow and Google bug
issue to find my solution to this. Still no luck.
I even clean project, rebuild project, deleted .gradle folder, tools folder, platform-tools folder to the point of uninstalling everything of Android Studio and their old caches.
Even with new Android Studio installation, I still cannot load up the AVD.
Before I did the whole complete uninstallation, yes I did kill the adb.exe many times via cmd and the rest of the lurking PID processes.
It was reported a bug in Android Studio 7 years ago and with everyone having solutions to this problem. I am still unable to fix this.
UPDATED 23.02.17 The issue still NOT resolved. Currently I am using another pc to do my development
More information
SDK_HOME = C:\Users\My Name\AppData\Local\Android\Sdk
Gradle version: 2.14.1
Android Plugin version 2.2.3
Workspace = C:\Users\My Name\MyProjects (Local, not version control or open source on cloud)
Source of download: https://developer.android.com/studio/index.html
Android Studio 64 bit 2.2.3 version
Laptop: 64 bit PC
Windows 10
Virtual Machines = Mac, Linux
UPDATED 25.02.17 Log specifically from .gradle assembleDebug log. (10 seconds after, standstill, left overnight and couldn't create a new project with NO CODE and couldn't load up Android Studio)
Looking in classpath from com.intellij.util.lang.UrlClassLoader#736e9adb for /com/sun/jna/win32-x86-64/jnidispatch.dll
Found library resource at jar:file:/C:/Program%20Files/Android/Android%20Studio/lib/jna.jar!/com/sun/jna/win32-x86-64/jnidispatch.dll
Trying C:\Users\User\.AndroidStudio2.2\system\tmp\jna8874909424579227886.dll
Found jnidispatch at C:\Users\User\.AndroidStudio2.2\system\tmp\jna8874909424579227886.dll
Looking for library 'user32'
Adding paths from jna.library.path: null
Trying user32.dll
Found library 'user32' at user32.dll
Loading library manifest C:\Users\User\AndroidStudioProjects\MyApplication2\app\src\main\nevercreated.xml
Merging main manifest C:\Users\User\AndroidStudioProjects\MyApplication2\app\src\main\AndroidManifest.xml
Merging library manifest C:\Users\User\AndroidStudioProjects\MyApplication2\app\src\main\nevercreated.xml
Merging manifest with lower nevercreated.xml:1:1-12:12
Merging applicati
on with lower nevercreated.xml:3:5-11:19
UPDATE 26/2/17 I did a chkdsk /f /r /x check and no bad sectors were found in the hard drive, to ensure that read and write or hard drive issues were the cause of the problem. No issues with the hard drive to affect this issue.
JDK was also reinstalled to ensure that the JDK was not hindering the problem. No firewalls or firewall programs were enabled, all of them were disabled and uninstalled. No problem even with firewall on for many months before too, so this is not a concern.
All processes were indeed TASKKILL before any other processes would occur. Still no luck.
UPDATE 27.2.17 I ordered a new SSD to arrive tomorrow and I will make a new installation (dual-boot) Linux and Windows 10 and install Android Studio on both systems to see whether it will work or not. So I took the extreme measure to have uninstall and reinstalled the program, no luck, the operating system, no luck and now I will test on a new hard drive soon. (FINGERS CROSS). Even though there is no bad sectors or error on this hard drive through checking the logs.
UPDATE 28.2.17 I reinstalled the whole operating system and I bought another new SDD. The Android Studio problem is solved.
REFLECTION
I reinstalled operating system before, but still had Android Studio problems. This leads me to think that it is a hard drive issue, an internet connection (firewall) issue OR Android Studio bug issue.
Unfortunately, I cannot pin point what caused my problem. It randomly happened out of no where. BUT I hope this will provide comfort to those who experienced almost 10 days of gruelling annoyance.

What's the fastest way to run unit tests in Android

There are two options available to run unit tests in Android Studio:
Right click on the file with your unit tests (which is Gradle-Aware Make).
testAppDebugUnitTest task is from the list of available Gradle tasks.
The first one actually consists of two tasks:
- :app:assembleAppDebug and :app:assembleAppDebugUnitTest
The second one is just testAppDebugUnitTest itself.
The first one is a recommended way by Google Tools Team, but it takes as twice as much time compared to the second one.
There is no visible difference how to run unit tests except the duration. You might think your code won't be compiled without assembleAppDebug, but this is not true - changes you introduce to either class under a test or a test itself compiled and executed as expected.
So, what's the difference and why is it the recommended way if it takes as twice as much time to prepare everything before actual unit tests run?
I don't have much work experience with Gradle, But off course it is always better to use Google Team recommended tools instead of others.
it takes as twice as much time compared to the second one.
If you use the new Gradle build system with Android (or Android Studio) you might have realized, that even the simplest Gradle call (e.g. gradle project or grade tasks) is pretty slow.
To avoid this time taking processes in android studio you need to Speed up Gradle build time. It will definitely makes a difference
Here is few steps to speed up the Gradle build time >>
In compiler settings (Android Studio -> Preferences -> Project
settings[your project] -> Compiler (Gradle-based Android Projects)),
type --offline in the "Command-line options" box.
from ~4 minutes to ~20 seconds.
In another way, You can decrease this startup time of Gradle (on my computer down to two seconds), if you tell Gradle to use a daemon to build. Just create a file named gradle.properties in the following directory:
/home/<username>/.gradle/ (Linux)
/Users/<username>/.gradle/ (Mac)
C:\Users\<username>\.gradle (Windows)
Add this line to the file:
org.gradle.daemon=true
From now on Gradle will use a daemon to build, whether you are using Gradle from command line or building in Android Studio. You could also place the gradle.properties file to the root directory of your project and commit it to your SCM system. But you would have to do this, for every project (if you want to use the daemon in every project).
Note: If you don’t build anything with Gradle for some time (currently 3 hours), it will stop the daemon, so that you will experience a long start-up time at the next build.
For more details please refer this Building and running app via Gradle and Android Studio is slower than via Eclipse
Performance improvements are one of the great tasks in the Gradle roadmap for 2015 (and reaching into 2016). So hope, we’ll see the general performance increasing within these years.
n g+ there is a discussion with the developers about it.
Hope this information will helps you.
The reason your option 1 takes twice as time is because most of the time is wasted on spinning up Gradle and checking if tasks are up to date. So running an no-op assemble will make it twice as long. You can verify this by running it yourself and check the time wasted by doing an no-op.
With gradle, running with "--offline --daemon --parallel" can get you somewhere (offline is helpful when you have slow internet access to Maven/JCenter repos, daemon is helpful to keep files cached, and parallel is particularly helpful if you have MultiDex on and have split your app into small modules)
If you are just asking about "What's the fastest way to run unit tests in Android?" without considering the change you would need, I would recommend switching to Buck (https://buckbuild.com/), which is 10x faster than Gradle on dex-xing and spinning up tests but has limited AS support.

Extremely slow gradle build

The following measures were taken to speed up gradle build from this (SO post)
org.gradle.parallel=true, org.gradle.daemon=true
build from terminal and not from android Studio
building with ./gradlew assembleDebug --offline
Problem:
Even after these measures build times can take upto 6-8 minutes for a single line of code change! and during this time computer mostly freezes and nothing else can be done except to stare at the terminal. I've noticed that "app:dexDebug" takes a lot of time in this. What are the possible causes?
Relevant files:
Terminal build dump
build.gradle(app)
build.gradle(project)
System details:
Android Studio 1.2.2
Description: Ubuntu 14.04.2 LTS
You can try disabling your lint checks by adding this code to your build.gradle
tasks.whenTaskAdded { task ->
if (task.name.toLowerCase().contains("lint")) {
task.enabled = false
}
}
Also you can use the --profile parameter to export a html report of what's taking so long in your build time
EDIT: removed the debug check
We had a similar problem: our build took about 4 minutes. After some research, we get next steps:
Try turning on offline work in your Gradle settings (Ctrl + Alt + S for the Settings, then Build Tools -> Gradle settings). Usually, we do not update libraries so often and Gradle will not check that they are up to date.
Multidex increases the time for build: Android documentation. To mitigate this, you can add additional flavors for debug and production builds, setting for debug builds minSdk = 21 (suggestion from official site).
If you have several modules in project, try to flatten them into one or at least extract "Library project" and connect it as .aar
As a result, our build time decreased to about minute - minute and a half. Hope these suggestions will help you too.
And if we will talk about small changes, starting from Android Studio 2.0, it is possible to use Instant run and Incremental build, which makes small changes in method or layout even faster.
Understand that Gradle Build has nothing to do with your CPU Speed or RAM. The reason why the Build gets slower in your PC is due to your Internet Connection. The build can take nearly ~100 MB approx. of data to complete it's process. Even if your Internet Connection is fast and your connection's PING speed is slow, it takes more time.

Gradle - high CPU use

I recently started to use Android Studio and while I like it a lot, there is one thing that annoys me a lot:
Gradle - it's nice tool and all, but damn it's such a resource hog, also it's just so painfully slow. No matter if I use my 5 years old laptop or my gaming PC, when it's running, other applications go to a full stop (well almost)...
Is there really a reason for a build tool to be so demanding??? I understand compilation can be a slow process but from my experience javac always seemed to be blazingly fast, so it cannot be source of a problem (also building Android apps with ADT was many times faster too)...
So is there something wrong with my configuration? Can I make Gradle run faster?
Create a gradle.properties file either in your project root directory or your ~/.gradle directory with the following line:
org.gradle.daemon=true
From the Gradle manual:
The Daemon is a long-lived process, so not only are we able to avoid the cost of JVM startup for every build, but we are able to cache information about project structure, files, tasks, and more in memory
Also, you can go to File > Power Save Mode if you want to turn off continuous building in Android Studio.

Categories

Resources