IssueTracker

We use build flavours heavily with a lot of common code. The refactoring support in AS is really good but it continually catches us out when it doesn't work across all flavours in a project. It's a big gap for serious product development.

We at my company need this same feature. We have a lot of white labels and need refactor the same class across flavours. :(

I need this feature too...

+1, I need this very badly

+1 My company also need this feature.

Can we atleast know the status of the issue please? Will it be fixed or is it in low priority. It's been 4 years.

We are currently investigating possibly solutions.

+1 This will exclude a lot of unnecessary work. In my work I have 25 flavours. :(

+1 .. we need it as well...

Any update on this?

I would like to vote for this feature as well.

+1

+1

+1

+1 "Build flavor source code is useless until this is fixed." - agree

+1

My team are heavy users of Android Flavours and the IDE remaining semantically aware of all flavours besides the currently 'focused' one, for refactoring and searching purposes, would be a major productivity boost.
Indeed, the current state almost feels like flavours are only partially supported in the IDE.

[Comment deleted]

I am trying to develop a simple survey project on Android Studio and I can't believe how much I am suffering just to change a single text in a activity.xml file. My system is Intel Core i7-4790 3.60Ghz - 256 GB SSD - 8 GB Ram. I am not sure about people will continue to develop apps on this platform and I think this is ruining google's reputation.

I have the same problem on a 2013 Mac Book Air (on Mac OS X 10.11 and 10.10).

This is still observable in the newest AS (1.3.2). As other people mentioned, I also don't have a "weak machine". Just do something about it, please.

This is evident in the 1.4 release as well.  I came across this as my machine started to crash in an odd way while I was working with AS.  It turns out it was due to temperatures reaching high limits - 90+, which was caused by doing many successive builds through AS.

FYI:  I'm running an i7 with a stock cpu cooler in an antec case with 2x60mm + 1x120mm intake fans, as well as 2x60mm exhaust fans.  i always thought heat would be my last problems.  not with gradle...

I can confirm the problem is still present in the 1.4 release. My Surface Pro 3 which normally would last 8 hours on a single charge only lasts about 2 hours while doing some light work on the go on android studio. The fan spins like crazy and i can not work in public places because of the noise it makes and the constant need of recharging my battery.
Also my desktop has problems with gradle builds and compiling, even with 16 gigs of ram and an i7 4790k (without mentioning that even with my GTX 980ti and HAXM enabled, the emulator still runs laggy and slowly)

Exact same issues noted above on AS 1.4. My computer is using Win 7 SP1 64bit with i7 Intel core, 2.7GHz & 6GB Ram.

Please resolve.

This issue is painful. Quadcore i7 with 24GB RAM, I feel like in the 90's when compiling. If I only could continue using the PC while compiling, ie for checking documentation, cleaning up code, whatever, but this, this hurts.

Have the same issue. Gradle is too slow! Building takes a minute and i can't use my computer while building. I have a Core i7 and use Linux

Same problem with gradle in JetBrains IDEA.

I am still facing the 100% cpu utilization issue with Android Studio v2.0 preview8. At least please suggest us any workaround till you fix the issue?

Thanks.

I am having the same issue with Gradle on Linux, it uses all my cpu's and blocks the ui for a couple of seconds. Android Studio 1.5.1

Same for me from 1.4 to 2.0 Preview 9 of Android Studio

This has been a huge problem for me for a long long time all the way up to Android Studio 2.0 Beta 2. It really doesn't matter how fast is your machine (mine has 32GB of RAM and 4.0ghz 4 cores/8 threads i7 CPU). Every time I click run the CPU goes up to 100% usage interfering with other apps normal behaviour.

I've resolved this issue by decreasing number of CPU cores assigned to studio64.exe and java.exe by one. 4th CPU core is now unused when compilation runs and other apps are responsive. I used Process Lasso app to do so.
Hope this will help somebody too.

Process Lasso works wonders for Android Studio, auto manages threads to prevent any one process from locking things up.

https://bitsum.com/

Same issue here, using Mac computer with i7 processor and running Android Studio 1.5.1.

i am using Surface pro 3 i5 cpu , android studio 2.0 release,  is experiencing this issue.  this let me crazy....................as;dfla;sdghkl


can anyone tell how to fix this?

Same issue here. Fast MacBook Pro and everything hangs. What can be so difficult to fix about this?

I cannot wait 5 Minutes for a f***** build and meanwhile do nothing else because the whole pc not responding.

get this fixed please!

The following statement is just some hit about how I was able to "fix" the issue for my environment, I mostly using atMonitor (on mac) to monitor my computer when building, this can't be a solution, but I now able to build easily now.

Environment:
So I was facing the same issue with a mac intel core i5 2.9GHz and 8GB memory on el capitan. For me when build, everything was frozen, only the mouse (sometime) was moving. The freeze could be from one minutes to five minutes, if more, I have to shutdown my computer. I'm using the AS preview 2.1 Beta 2, with gradle:2.1.0-beta1 and I working on a "kind of" huge project.

Fix:
Edit ~/Library/Preferences/AndroidStudioPreview2.1/studio.vmoptions ( Nothing more than the following option):
-Xms256m
-Xmx1524m

In your root project a gradle.properties (same thing nothing more than the following option):
org.gradle.jvmargs=-Xmx1524m -XX:MaxPermSize=256m

I know a quick search on google will show you other option like -XX:+UseCompressedOops etc..., but with this option computer still freeze.

Now It's been five day, I'm with this configuration, building process take around 40% to 70% cpu and I didn't get a freeze since!
Build process is around 1 mins 35.975 secs that look good to me and I don't use instant run.  


One last thing I got the following warning when building :

.....transformClassesWithDexForDebug
To run dex in process, the Gradle daemon needs a larger heap.
It currently has approximately 1355 MB.
For faster builds, increase the maximum heap size for the Gradle daemon to more than 5120 MB.
To do this set org.gradle.jvmargs=-Xmx5120M in the project gradle.properties.
For more information see https://docs.gradle.org/current/userguide/build_environment.html

Forgot to say you have to closed Android Studio after change, including any emulator. Also I don't know if that will change something but I also remove .gradle folder from my root project so that everything was re-downloading as new.  

Ok this has been a year and Android Studio 2.0 has been released and nothing has changed. Instant run works fine in the latest release, but the initial gradle build has become even longer. My Surface Pro 3 used to build my project in 2.5 minutes, now it takes 5 to 6 minutes and it is unusable. My desktop PC which sports 16GB of ram and an i7 4790k passed from 30 seconds to 2.5 minutes.
Meanwhile, all the CPU cores show 100% usage on every thread, this is just ridicolous.

process lasso helps, a lot!

Yeah, process lasso may help but a solution should be provided because this is obviously a bug and can't be ignored. Not everyone is willing to mess around with third party programs and someone could even be restricted from using it on his working machine because of his company security policy.

[Comment deleted]

What about on MAC? I tried cputhrottle but not working as expected.

Same issue here with Android Studio 2.0

Windows, Quad core i7, 16 GB of RAM. Doing a Gradle build pegs the CPU at 100%.

I am developing a small project. On another computer with similar (possibly worse) HW capability, I have Android Studio 1.5 with a **MUCH** larger project that does not exhibit this problem.

Another update:

From my previous post (#53), another important differences is the version of the gradle tools that were being used.

In my AS 2.0 environment, I am using gradle 2.0.0; this has the CPU pegging behavior. In my AS 1.5 setup, I am using gradle 1.5.0; this only uses about 25% of my 4 cores when it builds (a much larger project).

So: I tried using gradle 1.5.0 in my AS 2.0 environment and saw that the CPU also gets pegged (for 2 minutes when I try to deploy the app; 2 MINUTES of not being able to use my computer).

From this, I do not think that gradle is completely to blame for this. Another important difference is that for the AS 1.5 environment, I am primarily doing pure Java development (with a little Android work), so when I package my Java GUI I am not using the Android gradle plugin. The CPU gets pegged when I try to package and deploy an Android application.

As such, I think that the problem squarely lies in the **Android Gradle plugin**.

Problem came with Android Studio 2.0.. Please Google appoint this problem!

This has become a much bigger issue after updating com.android.tools.build:gradle from 1.5.x to 2.x. Even on a Macbook Pro with 16GB of RAM and an i7 CPU Android builds now cause other programs (Chrome) to hang and freeze for seconds.

Same here, before updating it worked ok on Macbook Pro 13, now (2.1.0) if freezes the system while building.

MBP 13 with 8GB RAM/i5, build takes up to two minutes and the machine is not usable while building (totally dead time)

I mean ... any compilation typically uses 100% cpu, that's what it's supposed to do, it's not exactly a bug. Through affinity and other things this can be controlled. The time compilation takes is pretty ridiculous though.

It really does not make sense that this issue is unresolved for such a long time. quadcodei7, SSD and 16GB RAM config feels like pentium 4

this is very slow. Do we have a solution yet ?

still soo slow. :( i7-4700mq - 16gb ram - 128gb ssd )

Not a single official response on a critical bug thread in 2 years. Yey, Google!

Any known workaround to limit number of CPU cores used on MacOS?

my 8-core xeon station with 12 ram and mac pro mid-2012 ssd/12 ram both become unresponsive for several seconds during the build - sth hasn't happened in a long time.

Android Studio for sure locks up when building and uses 100% of CPU when building. My machine is an iMac Retina Late 2015 32 GB ram, 4.0 GHz Processor, fully loaded. Should not have any stuttering or issues when using Android studio.

This also magnifies when I have multiple Studio projects open at the same time. I average 2-3 projects open at any given time.

any progress on the issue?

Gradle and Google please get your #$&T TOGETHER! FIX THIS NOW!

Please address this issue, since it's already affecting Jenkins, on a linux server, ON AN EFFING LINUX SERVER!

This is getting ridiculous, Android Studio is practically unusable.  I spend more type waiting for gradle syncs and 'Indexing...' than actually writing and testing code. It gets worse if you have multiple projects open and I regularly need 6-8 projects open at a time (one for an app and multiple library projects that are used in the app).  Every time I build a library, ALL the AS instances start to index and CPU usage goes to 100% on all cores for minutes at a time. The whole machine becomes unresponsive. The spinner in the AS status bar updates at about 1-2 fps while it's busy.

Is Google eating their own dogfood ? I can hardly imagine anyone inside Google using Android Studio or it would have been fixed by now. It's completely ridiculous how bad it is.  This is on a MBP i5 with 16GB RAM and a PCIe SSD.

Probably that's why it was lined up as a #666- ticket? Because it's one of the hellish issues to solve? :D

Okay, I'll see myself out.

Please fix this, it makes Android Studio *unusable* .

I think they are ignoring this because it's a ticket for the old version, someone needs to file this for the current vesion..

Someone already did, and it seem to get the "template" treatment:
https://code.google.com/p/android/issues/detail?id=202113

Can someone check the new build tools plugin?

 'com.android.tools.build:gradle:2.2.0-alpha6'

It seems to have addressed the high CPU issue (at least it's lower on my end, just 86%).

Hey guys from Google. Seriously that this issue was not solved yet?
I'm running in a Mac Book pro i7 3.0 16GB RAM and even a new project created with only one activity takes 17min to build with the standard configuration.

Android studio 2.2.1 and gradle com.android.tools.build:gradle:2.2.1 the problem still hapennig.

Doesn't matter if I run in the emulator or in a external device, using a terminal or inside Android Studio. When the build starts the pc becomes unusable for ~20min in each build.


I think Google should care more about this issue. Its opened since 2014.
Shame on you Google.

[Comment deleted]

I agree, it's a shame i loose so much time between each builds and my laptop cannot be used anymore during build process, maybe my configuration is not enough for Android development ?
Android Studio 2.2.2
MacBook Pro (Retina, 13-inch, Early 2015), 3,1 GHz Intel Core i7, 16 GB 1867 MHz DDR3

For me the high CPU Is obvious, the build time is understandable, what's not is that system is barely responsive during build...
It doesn't seem to be related to hardware, as it's the same on my ultrabook (4-year-old Asus) and on my PC (i7 @ 3.8GHz, 16GB RAM, SSD...)

I tried solving this by assigning lowest priority to all java processes, but system was still unresponsive. This is NOT the case for all other builds -- I'm using gentoo linux, and when I compile my packages with nice level set to 19, system usage is 100%, but the system is fully responsive! I read somewhere that the gradle threads "don't yield to other threads very often", maybe that's the case?

A possible issue may also be high thread count: on both my systems during compilation my load avg is constantly about 20-25, which is way too much for both 4-core and 8-core systems...

So apparently one company found it necessary to purchase additional hardware and write some scripts to run Android builds on a remote machine so people could continue using their laptops while Android Studio is building.

See: https://github.com/gojuno/mainframer
And related Reddit thread: https://www.reddit.com/r/androiddev/comments/5jkdub/speed_up_your_project_build_time_by_remote_build/

It's totally ridiculous that people have to go to these lengths to make Android development less painful.

Meanwhile, Google's devs are twiddling their thumbs. It's taking over two years now just to introduce a fixed-size thread pool and there's still no solution in sight. This should be a 5 minute fix guys (if it's not, then there are probably even bigger architectural problems with the Android build tools than I imagined).

[Comment deleted]

We have a property that you can use if you want to restrict the amount of threads our tasks  use. Run gradle with -Pandroid.threadPoolSize=4. This is available in 2.3 right now.

We're also fixing cases where using different `buildScript` blocks in different modules could lead to our plugin being loaded by different classloaders in different module which breaks our singleton threadpool which leads to each module not sharing threads, and therefore leads to even more threads being used. This is being fixed now and will be in 2.3 beta3.

A better fix is in the work to have better threading APIs in gradle to solve this properly.

Hi,

i just tested with Android Studio 2.3 beta 2 with
android.threadPoolSize=2
in my gradle.properties, but nothing change, did i miss something?
When you are talking about :
"Run gradle with -Pandroid.threadPoolSize=4. This is available in 2.3 right now."
2.3 you refer to the Android Studio version right ?

Could you provide us with some more info:
- Do you place the 'buildscript' blocks in subprojects?
- Do you run the build in parallel mode? (Parallel mode is enabled by selecting the 'Compile independent modules in parallel' option in Settings/Build, Execution, Deployment/Compiler when building from the IDE, or by adding the --parallel parameter when building from the command line.)
- How many subprojects (modules) do you have?

As explained in #84, we do use a shared thread pool with size specified by -Pandroid.threadPoolSize (or the number of available processors if that parameter is not set). However, if (1) is true, Gradle will load the plugin multiple times. Combined with the fact that the build is running in parallel (2), it will mean that each subproject will be built with a separate thread pool. So the actual thread pool size is effectively multiplied by the number of subprojects.

If that is the case, then this issue is related to https://code.google.com/p/android/issues/detail?id=229171.

We have fixed it in Android Studio/Android Gradle plugin 2.3 beta 3, not beta 2. Please try again and let us know.

To clarify, (1) and (2) above refer to the previous questions asking for more info.

Anyone has an update on this issue?

We suspect this has to do with parallelization configurations, but we need more info. As mentioned, there are two levels of parallelization:

- Project parallelization is enabled by the Gradle parameter --parallel or -Dorg.gradle.parallel=true (it is disabled by default). The number of threads used at this level is controlled by --max-workers (--parallel-threads was deprecated); the default value is the number of processors.

- Task parallelization is enabled by default for several tasks within the Android Gradle plugin (which users can't disable). They share the same global thread pool with size specified by -Pandroid.threadPoolSize; the default value is also the number of processors.

Please try building (from the command line) with no project parallelization, and set -Pandroid.threadPoolSize to a really low value (even 1) to see if the problem persists. You can also try varying the values of the above parameters and observe their effects on the build.

Please report back to us any findings that you have.


(Note: Also make sure that buildscripts are not placed in subprojects, especially if you are using a plugin version prior to 2.3 beta 3, to avoid problems caused by the plugin being loaded multiple times.)

there will be more control once we start using the new Gradle worker API.

CPU usage is 100% when aapt is processing the string.xml resources, so the build is taking a lot of time post build tool version 23.0.1 as logged here
https://issuetracker.google.com/issues/37076896

Does it relate to this issue?

This bug is closed as the NeedsInfo tag was never resolved. Please re-open providing the requested information if this is still outstanding.

Still reproduceable, even with the settings provided.