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!
Related
Testing on Samsung Galaxy Note Edge, Android 6.0.1
PLEASE NOTE - this issue happens only on Samsung Phones with pre-installed "Smart Manager". If you have no experience with that constellation, please read in detail whats the real issue. This is irregular, not a usual debugging thing. Please don't expect a code snippet right now, there cant be one. At this point I cant post any reasonable line of code because the origin of those errors is COMPLETELY UNCLEAR. I have only 4500 lines, and 25 classes, but absolutely no clue where to pick a meaningful snippet from without any hint what Smart Manager complains concretely. It says just one word: "ERROR", but not when, not why, not what ... Mission Impossible 😩
I've researched a lot now, but found almost nothing being of help. My app is compiling fine without errors and running smoothly (and very fast!) as desired. I cant feel anything about "performance degradation", but Samsung "Smart Manager" has this very weird issue with my app...
Battery lasts for days on standby, no heat, nothing notably.
No information what kind of error should have been occurred at all. No more details to open, simply nothing!
My app does definitely not run in background. It stops, pauses and resumes without issues. No issues, no errors during building (Android Studio 2.2), no warnings about Smart Manager performance issues, this error pops up ONE WEEK LATER, or two or three. That's why I you have no chance to create a link between error and possible root cause to start tracking down. In that time you made lots of code changes before you get notified from SM the first time, lots of Git commits, but which one contains the change this external tool complains? That makes it a real hell.
I also let it connected for 5 days to USB, collecting tons of logs, crawling the logcat like crazy for any relevant events, but SAMSUNG's Smart Manager doesn't seem any need to log at least one word when it counts its ominous errors.
What I've found on the net, nobody really knows how to debug this, just very time-consuming guesses which I followed where applicable - without success.
What I've already tried:
Exceptions - all caught and handled
Removed all debug logging output
Checked for infinite loops
Checked for missing or damaged resource files
Disabled auto-translation
Checked for whatever could be irregular, suspicious or extraterrestrial 👽
And after making changes I must wait days or weeks if it will finally pop up again or not...
Could there be any way to catch those Smart Manager error count events and attach some whatever sort of logging to it? There is no documentation from Samsung anywhere, no support for this pre-installed app, no help at all.
The error message is very clear, 10 crashes in 1 week. I would clearly say that the app is sub standard.
You should start with implementing a Global Exceptional Handler or start using some specialized service such as "Crashlytics" in you App to understand what is going on.
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.
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.
A while ago I bumped into an issue with eglSwapBuffers freezing the phone with the following message showing up in the device log:
W/SharedBufferStack( 1110): waitForCondition(LockCondition) timed out (identity=28, status=0). CPU may be pegged. trying again.
I've seen discussion on this issue all over the web but the only solution I've found to have any effect is calling glFinish after eglSwapBuffers. This solution, however, results in the framerate dropping by a whooping 10-20, which is far from acceptable.
Issues have been opened and one can be found here
Someone commented that using square textures eliminated the issue. By square I initially thought he meant power-of-two textures but after making sure I was not using any non-power-of-two textures and not getting rid of the issue I began to think that he might have actually meant textures with matching width and height?
I'm testing on an HTC Desire with Android 2.3.3. Someone commented that future versions should have fixed this issue but 2.3.3 is installed on so many devices that we can't disregard it.
Anyway, anyone have any thoughts on this? We're very close to shipping a title and this issue is threatening out schedule.
I also came across this issue, I used to re-install the Application and it worked for me.If not, then simply reboot your device.This issue is related to internal isssue of OpenGLES.You can refer this link:
Android "cpu may be pegged" bug
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