I love the new incremental Java compile in IDEA 12.0 but there seems to be a price to pay. Making now takes about twice as long as in 11.x, most of the time appearing to be spent
Executing DEX
(according to the status bar).
I can take a 12.0 project, revert to 11.x and making is back to "normal speed" (approx 4 minutes vs 30 seconds).
I don't get this. AFAIK, IDEA (or Eclipse or any other IDE) is just shelling out to dx.jar to compile the Dalvik executable. If there was a problem with the ADT, it would affect 11.x equally.
OS is Win 7 Ultimate. 3.2GHz quad core with 16GB but I suspect that the issue is not related to OS or PC since 11.x is OK.
Any ideas? I'll log a bug with Jetbrains but wanted to see if anyone has more concrete info or workarounds? There's nothing so far on the Jetbrains bug tracker or fora that I can find.
I have had this issue a couple of times in the past and it's always been due to the inclusion of a global library that hangs during build.
On one occasion it was due to the Python libraries trying to execute when the Android project was built because I had a python file in my Android project and IntelliJ decided to add the Python runtime libs to my project dependencies.
More recently the same thing happened with Groovy when I had a gradle file in the Android project.
For me I simply removed these dependencies from the project and the problem resolved itself.
In my case I discovered this by force killing (kill -9) the java process that was running the make. This caused intellij to dump the error to the Messages view in the IDE where I could see groovy trying to execute.
Related
Just upgraded to Android Studio 3.4 and am trying to compile my apks for the first time with it. Seems to be stuck forever at:
Shall I give this up as a bad job, or be patient?
No, I gave up after 1 hour (had to force close Android Studio), log out and back in again. I then noted that R8 is enabled by default, so I disabled it as per this and now it's back to normal (using ProGuard rather than R8 though).
EDIT I tried enabling R8 again and this time I got an error message Out of memory: Java heap space, with a suggestion to increase the amount of memory allocated to Gradle by using the following line in gradle.properties:
org.gradle.jvmargs=-Xmx1024m
... and it worked! Seems to compile a lot quicker using R8 compared to Proguard.
Even after having 16GB-RAM/256SSD/Core-i7 configuration, I ran into similar issue while building project in release mode on Android Studio 3.4 version with gradle-5.1.1, but after updating to gradle-5.2.1 all issues gone. Just go to File menu and open the Project Structure dialog to update the version.
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.
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
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.
The second I open up layout.xml file from a simple skeleton app in Eclipse example plugin, the cpu usage locks up to 25% IE. 1 full core. and it's been on like this for the last 30minutes I wanted to let him run a longer time because I thought it is working something in the background but it just keeps doing that.
I've tested this on 2computers so far and the setup is
install Android SDK,
install Eclipse IDE for Java Developers,
install ADT plugin: http://dl-ssl.google.com/android/eclipse/
open new project, select a skeleton project for Android 2.3.3
and just open the layout skeleton activity and perhaps change to android 2.3.3 in the upper right corner and maybe setup to theme.black.noTitleBar.Fullscreen.
And now your processor should be hitting 100% ( on one core ) and should be locked like that from now on.
Is there any solution to this issue, because at home I only have 1 core and I can not work on anything.
Does any one have any clue as to why this is happening ?
http://my.jetscreenshot.com/demo/20110517-gbr8-201kb
I'm seeing the same issue so I filed a bug report at http://code.google.com/p/android/issues/detail?id=18865.
The Android team have now released a fix and it works for me. You have to upgrade to the latest revision of each SDK module that you downloaded through the android tool. The latest version of the ADT also has a number of fixed for long-standing issues.
I can't answer "Why" this happens. But I can say what fixes it.
I encountered this on Ubuntu 12.04 64 bit. I had 100% cpu and eclipse hang when I switched to debug view - Eclipse was unusable and had to kill it. I found the below bug report
https://code.google.com/p/android/issues/detail?id=34641
Following the comments there, I tried
cd /usr/lib/x86_64-linux-gnu/gtk-2.0/modules
mv libgail.so libgail.so.moved
Eclipse did not hang (no 100% cpu) when I switched to debug view.
Start Eclipse with -Dcom.sun.management.jmxremote (put it into eclipse.ini or start eclipse.exe with this option).
When Eclipse runs, start jconsole and look at the thread dump to see which thread hogs the CPU. It's the one which isn't WAITING. File a bug report.
I had the same problem and it was resolved just by moving my workspace to C:/workspace instead of Win 7 Libraries.