All was well until very recently when I noticed that debugging has become very slow. I do not recall any drastic changes that would cause this.
UI Navigation has a noticeable lag and network operations take forever. This is somewhat remedied if I reboot the phone and restart Android Studio/ADB.
App behaves fine when running in normal mode.
I'm using Dalvik runtime, on Android 4.4.2. I have not used ART.
Any advice on how to address this?
Check your breakpoints in Debug bookmark (button "View Breakpoints"), if there are many breakpoints which you forgot delete in the past this may slow you debugger. In my case deleting all breakpoints fix the problem.
I had such an experience before and it was due to a custom library that I had attached to my project, I still don't know how these two were related but after removing the library it worked like a charm.
See what has been added to your project recently, maybe it help you too.
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.
So I'm staring at this image trying to figure out how to actually look at my app...
I just updated my IDE to 1.5 and now none of my projects render a visual representation of their layouts.
I've tried restarting the application, checking for updates, restarting my computer, making sure my SDKs are all in order, but without fail upon startup I am treated to a pleasant view of nothing.
I've tried the solutions listed here and here but nothing has really worked. I don't see a sort of rendering log or even alerts of bugs.
Any ideas?
I had to re-install pretty much all of my SDKs, but I was finally able to get the layout to render again.
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!
Recently upgraded to the AIR 3.1 SDK and have run into a show stopping issue regarding InvokeEvent on mobile devices. The application is dispatching a new InvokeEvent each and every time you change orientation on the device. And it isn't clearing the "queuedEvents" array. Worst of all, the new event it dispatches each time is a clone of the last one recieved. In the case of our application, this would be parameters that tell the application to load certain data. So each time you change orientation, the application re-triggers that load sequence, causing lots of undersirable behavior.
The code is pretty simple to test out:
protected function preinitializeHandler(event:FlexEvent):void
{
NativeApplication.nativeApplication.addEventListener(InvokeEvent.INVOKE, onInvoke);
}
protected function onInvoke(event:InvokeEvent):void
{
trace(event.toString());
}
Now each time you change orientation you will see the trace statement and the event.target.queuedEvents collection continues to grow while never clearing any of the previously caught events out.
Rolling back to AIR 3.0 fixes this behavior. And I've been able to demonstrate that in two separate projects.
I'd love to hear of a fix or work around so we can release using 3.1, but either way, I thought I'd make others aware of this issue as I haven't been able to find anything about it through my searching.
For additional details on hardware: This doesn't occur in emulator or my LG Slate, but it does happen every time on both of our Xooms and our Samsung Galaxy Tab. It doesn't appear to be an issue with iOS.
UPDATE: Just updated to the 3.2 release candidate (3.2.0.2060) and the problem remains. Our software wont be able to update past 3.0 for the foreseeable future, which means we can't upgrade to Flex 4.6 SDK either, not without removing a significant feature of our application. This doesn't inspire us to the future of AIR in our company.
There are a few solutions and work around we might be able to employ to fix our specific feature, but there is still a concern over the effects of having an ever ballooning invoke queue that never clears. That could have additional issues over extended use of the application.
UPDATE 2: I put more details in the Adobe forum post. http://forums.adobe.com/message/4278518
Eric Jensen
I am trying to wrap my head around Android Widgets, using the sample provided here: http://code.google.com/p/wiktionary-android/
I have corrected the strings.xml but the plugin will not work properly, neither on the emulator nor on the actual phone. It installs fine, but it never updates.
But at least on the simulator i get some DDMS output, telling me, that the API-response could not be parsed, so I assume, that the Wiktionary API has probably changed.
However, on my phone, the public void onUpdate(...) method doesn't even seem to get called at all when I install the Widget. I have inserted Log.i(...) lines for debugging and while they all show up when I use the Widget on the emulator, none of them seem to come up when it actually runs on the phone.
The phone is a Samsung Galaxy S II running android 2.3 but that hardly matters I think.
has anybody encountered this before and knows anything that might help?
EDIT I was told it might be a permissions issue, but could not verify this.
OK. Just in case anybody else ever comes across this. There is a strange thing with android widgets when the throw an exception... just uninstalling isn't always enough one hast to restart the phone.
Can not explain why that is but it always did the trick.