I recently switched to IDEA as I often had have problems with Eclipse. Overall everything feels great. However, one issue annoys me. Building a simple application take a lot of time. If I change only one line, building takes about 1min. In Eclipse it took about 3 seconds.
I've searched a lot how to improve the performance, but nothing helped. I use the 64 Bit version of IDEA, I increased the RAM, gave the compiler a higher heapsize (Java and Android DX compiler), checked "Make project automatically" and "Compile independent modules in parallel". It didn't change the situation.
Why is Eclipse so much faster in building an .apk than IDEA is? How do you handle this long process?
In my case the antivirus software was causing the issue (ZoneAlarm). Please vote CrazyCoder's comment up, he had the correct intention. Build and launching the app takes about 2 seconds now. Great, really great.
Related
While researching this I was writing an answer to IntelliJ IDEA: Breakpoint not being hit, and is shown without the tick, just a red dot until I realised it is a completely different question. I have had this issue twice in the past 4 weeks, but my use-case is IntelliJ is no longer ticking the red breakpoints. I just watched the ticks fall away before my eyes.
First time it occurred was after unceremoniously ripping out the USB cable in a hurry. I don't appreciate the need for ceremony here. That broken project remains so.
I tried everything to fix it, and gave up on that particular project; it was largely complete. I tried adb kill-server and the general family of off-then-on-again solutions to no avail.
Fast forward a couple of weeks I'd forgotten about it and was delighted (I tell a lie, I was taking it for granted) to be able to test my new protocol with breakpoints on an Android device. First symptom was my icons messing up (I thought I must have had a trapped thread somewhere in the IDE but find it hard to believe I wouldn't have noticed that with just the single process being debugged). Next the breakpoint's tick just dissappeared and I had a blue message in the IDE's console, something about GDX and taking too long with the graphics (similar message appended at bottom of post). Foolishly I restarted the apk.
What haven't I tried? I'm thinking something drastic like persevering with Desktop only development, or ditching Windows. I thought about upgrading (contracting) Gradle but my other project was brand spanking new and recently diagnosed with specific Gradle version dependencies.
I can start the app from my dev machine but even pausing isn't able to find what it is doing because it will pick a (random) thread out of context with my app.
I can also hit breakpoints from the Desktop app
I suppose I should try Android Studio with this project but know that won't be an easy fix. I'm using Win10 Pro and on brand laptop and phone (nothing fancy mind). I'm using Gradle 2.1 (IIRC, I get a daily nag to upgrade to 4.1) but my other similarly fated project has specific dependencies on Gradle versions so I want to leave well enough alone.
I don't know if it's the answer or not, but it seems to work fine with the emulator, which would seem a more universal solution than something as challenging as, you know, supporting a bunch of different hardware. I ran it again and trapped a certain line, observed the same screen artifacts as before, but killed it before I could lose my emulator too.
This is the last thing she printed:
W/zygote: Long monitor contention with owner GLThread 260 (8155) at boolean com.mygame.game.screens.Menu$4.keyDown(int)(Menu.java:128) waiters=0 in boolean com.badlogic.gdx.backends.android.AndroidInput.onKey(android.view.View, int, android.view.KeyEvent) for 9.799s
It was trapped in a different method but the gist of it is I've blocked the GLThread.
I keep trying to build the latest Android source repository, but it always comes to a stop at one point, then it uses up just about all the system's RAM, and it keeps sitting there for hours without progressing one bit. It always comes to an end at about this line:
target Java: Contacts
(out/target/common/obj/APPS/Contacts_intermediates/classes)
and when I Ctrl+C it, it always gives me this (sometimes among others, depending on how many threads I set for make):
make: *** Deleting file
'out/target/common/obj/APPS/Contacts_intermediates/classes-full-debug.jar'
I'm trying to build aosp_shamu-userdebug on a Ubuntu 14, with open jdk 7. All over the net I found two similar questions to mine, but both had only the answers "you need more RAM". I was trying to build with 8 GB, last night i put in 8 more and left my PC to build this overnight, but come morning it had stopped at the same exact spot. I also tried building with no multithreading, in case that was the issue, but the result was the same.
Seeing as the problematic .jar has "full-debug" in it, I would suppose a "user" variant build might be successful, but it would be just about useless to me - I need to get a userdebug or eng running. However, if it would provide me with a jumping point to building what I need, I would of course try it.
Any and all suggestions on this matter would be greatly appreciated, thanks.
I've been developing an Android app for a week using Android Studio. I've noticed my disk space has been dropping and I don't know why. It seems that each time I run the app (99% of the time I use a test device, not an emulator), I lose disk space on my computer's hard drive. I have no idea why. Does anyone else know why and how I can fix it?
Update 2021: I had forgotten that I asked this question but someone else is having the same problem. I never figured this out on my old laptop. I ended up only working on my desktop (which didn't have this problem). Sorry I can't be more help :/
Try doing Build->Clean Project and then Build->Rebuild Project, it will reduce the space occupied by your project folder.
As for the rest, a good portion of the space occupied by Android Studio comes from the packages you have downloaded within the SDK manager. Try uninstalling those you don't currently need to free some space on your HD. See if it helps.
When using the ART runtime on my HTC One GPE with Eclipse the currently executing line of code indicator does not move when Step Over and Step Into are used. The execution appears to continue, but it is very hard to tell where it's at without the indicator. Switching back to Dalvik resolves the issue. Has anyone experienced this and is there any way to fix it?
Was having the same problem, switching back to Dalvik fixed the issue for me too
what made it hard to find is the fact that the debug was working rundomly sometimes on the first instructions dont know why
Yeah, the new VM as it shipped with kitkat has several bugs that affect debugging. In particular, stepping doesn't work at all well. There are numerous bug fixes already checked in to AOSP. I think this particular bug was fixed by this change, relatively innocuous though it sounds: https://android.googlesource.com/platform/art/+/f2910eef247b45ce1d489e323b36b5de6b6157aa
If you have a Nexus device you can build AOSP yourself and try it out. If not, you'll have to switch back to dalvik for now.
If you find other bugs, please use b.android.com to report them. You can't assume someone will make us aware of bug reports on stack overflow!
When dimensions of a project start being considerable the plugin of Android for Eclipse starts not working properly and also very slow, when it comes to XML modifications, refractoring the code from the XML files becomes tedious. Also sometimes it doesnt recognize strings resources. And I have to clean the project(which sometimes is like the solution for windows of restart the computer...)
Do you know about solutions to improve this behaviour? As I think it will be really helpful.
There are two things impacting eclipse's performance: I/O and memory....
I/O: Buy Good SSD disk. Full stop.
Memory:
There are few ways to improve performance:
1) include the following lines in eclipse.ini (with at least these values):
-vmargs
-Xms160m
-Xmx2048m
(that is if you have enough memory)
2) Use 32-bit eclipse on 64-bit system
That might be surprising, and it is only valid if you have not very big amount of memory (few gigs). 32-bit eclipse take about 50-60% of memory comparing to 64-bit one - the thing is that in 64-bit java every object/field etc. take 2x much memory as in 32-bit java. Until java supports (so far experimental) compressed references taking less space, it might well be that memory limits will be hit with 64-bit version where 320bit should work just fine.
Eclipse can run slow if you have too many projects open, especially if the projects are very large. I remember when i had like 3 sample projects open at the same time and eclipse went from running on 200 meg to running at 500 meg, it was really slow untill i closed all the projects i wasnt using, it also depends which type of computer you have, if your computer doesnt have very much ram then eclipse will run slow. My computer cleans projects really slow when i have a bunch of projects open.
Please make sure that eclipse.ini doesn't contains following line:
CompileThreshold=5
I have taken this line from some superfast Eclipse jvm config, but that option just makes compilation terribly slow.