Android Studio freezes for a few seconds every time. When tries to autocomplete, when loads gradle and even when i just open another directory! My computer has 16GB RAM core I7. I checked it's running processes and there is nothing overloading my computer. I found this log on Android studio just after a freeze action.
Received result Success[value=org.gradle.tooling.internal.provider.BuildActionResult#9ce896] from daemon DaemonInfo{pid=4363, address=[1459bd31-811f-4cf0-8cfe-ad8b357eaff9 port:54982, addresses:[/0:0:0:0:0:0:0:1%1, /127.0.0.1]], idle=true, context=DefaultDaemonContext[uid=014c14d9-e239-44bf-a401-d80b04b94f3c,javaHome=/usr/lib/jvm/java-7-openjdk-i386,daemonRegistryDir=/home/ezequiel/.gradle/daemon,pid=4363,idleTimeout=10800000,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]}.
I had a similar issue recently with Android Studio 2.3.3, starting to freeze on a regular base every three to five seconds, regardless of what the actual action was and independently from a running build or any other background activity.
Gradle definitely was not the culprit here, instead it seems that some plugin or configuration made it freeze.
I ended up partially following the steps here: How to completely uninstall Android Studio?, removing everything in ~/Library/Preferences/AndroidStudio2.3 ~/Library/Application Support/AndroidStudio2.3, ~/Library/Logs/AndroidStudio2.3 and ~/Library/Caches/AndroidStudio2.3, which made CPU load go down from 100 to around 15 percent while being idle, making the freezing go away completely.
I'd loved to find out the real reason, considering the fact that this occurred on two different machines (at home and at work), which IMHO doesn't make it a "random" issue specific to only a single, weird configuration.
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've added ember-cordova to my ember app;
after that I've tried to open the project in android-studio but at startup it starts "Scanning files to index..." and never ends... While it'ìs doing that it's impossible to run the app in the emulator;
I've been googling a lot and tried many things like invalidating caches, but nothing worked;
I'm using android 2.2.2; is there a knowed solution to speed it up? I guess this is not normal, the project is not that big;
I can't even understand if it's just very slow (if in N hours it will come to an end) or if it's blocked and will never end
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.
Ever since updating to the latest ADT (version 18), I've noticed that there seems to be some sort of odd lag between what's happening on device emulators and what various tools are seeing. For instance, if I set a breakpoint in Eclipse and then attach the debugger to a running app, the debugger will miss the first time that the breakpoint is reached, breaking only on subsequent executions. Similarly, if I try to take a screen snapshot with the Devices view, the image is always from one or two screen changes back. Similar behavior happens if I run hierarchyviewer outside of Eclipse, so I don't think it's an Eclipse problem specifically.
I should mention that the part of the app that I've tested this with has static screens that change only on user input (that is, no animations or background threads); so it's not just a communication lag. I can change screens, wait five minutes, take a screen snapshot, and still get an image of what had previously been on the screen. Screen snapshots in perticular never seem to catch up. (Repeating the snapshot still generates the previous screen, not the one on display.)
Has anyone else seen this behavior? Does anyone know how to fix it?
UPDATE: This is on a Windows 7 machine running Java 1.6.0_26 and Eclipse 3.7 (Indigo).
The Google/Android team have been enhancing the emulator images with the ADT updates like GPU support and sensor injection. If you are using old emulator builds (AVDs) from when you first created your work environment (say months ago) you will want to recreate them fresh from the new tools and see if the problem resolves.
I am trying to test my app on android emulator. So as soon as, i am choosing run the application, a new window pops up on the screen and after taking 1-2 minutes, it goes not responding.
I also tried running the emulator separately using AVD manager. Using this, i am able to start the emulator; but after 3-4 minutes - it goes "not responding".
OS- Windows 7 32 bit [ intel pentium 3.00 GHZ + 2GB RAM]
Java - 1.6
Android SDK - i have the latest SDK with 3.0 OS
IDE - eclipse Helios Service Release 2.
Plz help, i am unable to do anything.
Update: can you guys point me towards other 3rd party emulators which i can use?
Update2: My emulator is taking too much time in launching now. Can this be a cause? If yes, then how do i decrease the boot time?
(This isn't so much of an answer, but might go some way to figuring out the source of the problem; I'd comment on the original question instead but don't have enough rep to do so)
I keep having this problem too. I have an app with a few activities, one of which contains a layout with a Canvas which runs its own thread to do drawing processing. All of the activities run fine except for this Canvas activity which seems to crash the emulator in the way the OP described (the emulator .exe itself crashes rather than the application within the emulator) if left to run for a few minutes. As far as I can tell I'm not doing anything unusual with the thread - I copied the Lunar Landar example in the SDK and worked from that so I'm doing everything "by the book". The app runs fine on real devices.
So, while I realise the OP may be long gone, could anyone else with a similar problem confirm that the affected Activity is using a Canvas, drawing Thread, or anything like that? This problem is a real pain and I can't find any other discussions/solutions for the matter.
EDIT: I recently did a complete, clean re-install of the most recent versions of Eclipse and the Android SDK with all the updates and that seemed to solve the problem. Guess there was a bug in an older version of the emulator that was fixed in a more recent release.
Have you enabled snapshots. If you enabled it then you can be trying to open a incorrectly saved snapshot. If so, while starting the emulator with launch options, uncheck launch from startup
#mudit:remember Android 3.0(Honeycomb) is dedicated entirely to only tablets and not the mobile phones..
Does the emulator prompts you "not responding" in your app or when you just start the emulator without launching an app, too?
A strong advice: you don't need to restart the emulator for every app launch, just keep him running (maybe you already do that).
Does the logcat show some errors prior to the "not responding"? Have you tried creating another AVD?