Android Studio Debugger Issue - android

Recently Android Studio (4.1.1) has started to act strange. I cannot debug things properly because debugger stops on a random breakpoints (I have removed all of them) I have not set any. To reach a specific breakpoint i need to keep clicking Resume Program many times. Attaching few images in case it helps.
Hope it helps.

Related

Android app runs very slowly after resuming from breakpoint

My Android app runs dead slow (almost frozen) after resuming from a Java breakpoint, even if I disconnect from the debugger or even unplug the USB cable. I get the same behavior on every device and emulator I've tried. Performance is great until it hits the first breakpoint, but it's unusable after I resume and I have to kill it. It's very frustrating.
It used to work great but it started with Android Studio 3.1.x and it's still happening after I upgraded to 3.2.1, then 3.3.2, the latest stable release at this time. None of my colleagues who work on the same app have this problem so it's probably not the code. I suspect I have a configuration issue somewhere.
I have no idea what changed when it started. It happens no matter where the breakpoint is. I don't see any errors in LogCat.
I'm using a MacBook Pro (15-inch, 2017) running OSX 10.13.6, Android Studio 3.3.2 (current stable release) and a Pixel XL running P. Also various emulators running P.
Any ideas or suggestions are much appreciated.
NOTE: It happens on Java breakpoints but not Kotlin.
NOTE: I cannot repro with a simple default app, so it's project specific, but only on my machine.
As #Magudesh stated, method breakpoints are very slow for the android debugger.
It's a lot more useful to just add a line breakpoint in the first line of your method and then (if it's necessary) in the last line.
That will greatly increase performance. If you then want to jump to the next breakpoint you can just hit the green play button in your debugger window.
make sure your debugger is ok .
Don't add breakpoint in the method definition. Method breakpoint will decrese the performance. Go with line breakpoint. That is better.
Please go through the difference b/w method breakpoint and line breakpoint if you are not aware.
Try to remove all the previous breakpoints that you might have added in Android Studio.
Go to the debugger window and select the View Breakpoints option and then disable all the old breakpoints and only add the new one which you want to use.

Why Android Studio stop button remains active after running tests?

This happens every time I run a test as long as I remember (Android Studio 2+, 3.0, 3.1, 3.2)
.
Sometimes the stop button even shows multiple processes. Also it doesn't matter how many times I click the stop button, it will never work (it does stop the test but the button remains in active state).
It seems to be a bug in Android Studio. I have found that it was reported previously on Google Issue Tracker with ID 64031765 and is not fixed yet.
For some reason my answer was deleted by a moderator without any explanation. It is a bug and there is nothing more to add.

Android Studio Debugger Application Crashes with InterruptedException

While working today, it seemed as if suddenly I could no longer debug our application. The funny thing is, if I ran the app normally it would work just fine. To clarify, I was running the debugger all morning without incident (apart from the occasional glitch or crash). Then after lunch it began failing 100% of the time. Of course, I've been making changes all day, hence the "it seems" above. So, here are some relevant details:
Android Studio 2.1.1 (April 28, 2016 build)
This app starts up with a log in screen. The user must then authenticate with a username/password which calls out to an external service.
I can get to the login screen, but the app would always crash at the same point in the middle of the authentication.
Here is the stack trace:
05-24 14:56:25.764 2399-2745/com.mycomp.myapp.test E/Crashlytics: Failed to execute task.
java.lang.InterruptedException
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:375)
at java.util.concurrent.FutureTask.get(FutureTask.java:162)
at com.crashlytics.android.v.a(SourceFile:1936)
at com.crashlytics.android.v.uncaughtException(SourceFile:307)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:693)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:690)
05-24 14:56:25.764 2399-2745/com.mycomp.myapp.test E/AndroidRuntime: FATAL EXCEPTION: pool-5-thread-1
Process: com.mycomp.myapp.test, PID: 2399
java.lang.InterruptedException
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:1991)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2025)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:410)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1035)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1097)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:820)
Here are the things I've tried to fix it:
Back out all my changes (git stash)
Uninstall application from phone
Do a clean build
Do a Gradle Project Resync
Remove all breakpoints (seriously?)
Ok, I've been adding breakpoints all over to see how things work, so who knows? There's some merit there.
Restart Android Studio! (turn it off and on again)
And so far, nothing works. However, I can't emphasize enough that if I just run the app (play button, ^R) and run it on the very same device, it works just fine! Log in with no problem. So, it doesn't seem to be a code problem.
Furthermore, if you look at the stack trace, there is nothing pointing to our project.
Any ideas?
Well, I figured it out. It turns out I had a "Java Field Watchpoint" selected with "Suspend Thread" as one of the options. See the attached screenshot for clarification. Takeaways:
As you can see, I had been using a bunch of breakpoints, so it got buried in the window and I didn't see it.
I still don't know how it got set. I had been using watches on a previous day, but I had deleted them all. Furthermore, I'm quite certain I didn't turn it on, so how it mysteriously stopped working in the middle of the day is still a mystery. Also, I certainly wouldn't have checked "suspend thread" on my own. Some sort of default setting?
Point remains - if you are seeing weird stack traces, it might be good to check all the breakpoints and watch point settings.
I hope this helps someone.
Instant Run appears to be the culprit (at least in my case with Android Studio 2.3.3). Instead of disabling breakpoints, try disabling Instant Run. Once I did this, breakpoints ceased to cause crashes.
See Android app crashes when launched in debug mode for details. Under Mac OS X, I disabled Instant Run by going to Android Studio->Preferences->Build, Execution, Deployment->InstantRun and unchecking "Enable Instant Run to hot swap ...".
There is a "Having trouble with Instant Run?" message displayed in the settings panel. I clicked on "Re-enable and activate extra logging", reproduced the crash, and then immediately reported using the "Help - Report Instant Run Issue..." option as they requested.
Turn off instant run, It'll fix all the issues
I changed emulators (from Android 8.1 to Android 7.0) and did not experience this again. I wasted 3 hours on this. I hope I help someone by suggesting this.

How to stop logcat from scrolling in Android Studio

I used Eclipse before and I could easily stop logcat from scrolling, but I can't find same funcionality in Android studio. Anyone knows how to do it?
There's no dedicated button for this, but you can just click on / highlight some text around where you want to stop scrolling.
android studio have this feature
you just click on the line three times and you can selectd the line , it will stops scrolling.
I had the same issue. Simple solution:
In Android monitor, on the right, change No Filters -> Show only selected application.
Android Studio Stop scrolling log
Disable Scroll to the end
If not - you are able to scroll to necessary line manually and LogCat will not be automatically scroll to down
I actually just had a problem (in 1.2.2) where I couldn't keep it from scrolling. I tried all the tricks and proper methods mentioned here, but it kept scrolling out from under me.
Turns out there was a problem trying to connect to an emulator that had long since been disconnected, and it kept retrying. And every time it did, it reloaded everything causing logcat to refresh. So it wasn't REALLY scrolling, it just felt like it was because of how big the buffer is.
I unplugged my physical device (that was running along side the emulator), restarted Android Studio, plugged the physical device back in, and boom, it no longer kept "scrolling".
Hopefully this might help someone else. Because I was getting incredibly frustrated for a while, there.
Goodness, the trick is to search. Search for something within LogCat and then scrolling will stop. Tested: running Android Studio 1.1.0 against a real device (S5). Also, was ticking one line up and one back down until I then right clicked. Then it totally stopped. After that, I can remove the search and the scrolling is no longer automatic.

Eclipse keep deploying to device in debug mode

After deploying to my device once for debugging, every time I try and "Run As" in regular mode it still attached the debugger. I have deleted the application from the device and it still does this. This causes and issue when I just want to run the app, untethered from my laptop.
Has anyone else ran into this issue? If so, how do you fix it.
Does clicking on the "Disconnect" button do the trick?
Try restarting Eclipse. I had this issue once and restarting Eclipse worked for me.
I have had problems with this as well. I don't recall what specifically fixed the problem, but I remember I did a combination of: 1) changing the configuration to "Run" only, 2) restarting Eclipse, and 3) trying multiple times.
One thing to keep in mind- even in "Run" mode you can see things going on in the debugger. For instance, you still get log messages. The main difference that I see is that it is much faster, and you don't see the threads and variables.

Categories

Resources