I am working with Google's Leanback library for Android TV and I am trying to figure out how to best listen for the buttons on the remote control (especially the ones that are not captured by the MediaSession).
For that reason I have a break point in BaseGridView.dispatchTouchEvent() and when I press one of the remote buttons the debugger does indeed jump to that point and shows me the usual debug information.
However, after a few (2-5) seconds the debug info disappears and is replaced by the message "Frame is not available".
In other places the debugger is working fine, so I was wondering whether the delay caused by the debugger is counted as ANR and the app is therefore force closed?
In any case, is there any way to get around this?
This message appears because u set too many breakpoints, and threads are waiting data from other threads, to settle this, you could cancel some breakpoints and waiting for the data to be ready...
the message "frames not available" means that no more frames are available for debugging.
The android studio help states clearly the purpose of the frame window and the frames within:
The Frames pane enables you to gain access to the list of threads of your application , export to a text file and customize thread presentation. For each thread, you can view the stack frame, examine frames, navigate between frames, and automatically jump to a frame's source code in the editor. You can select a thread via a the thread selector drop-down list on top of the pane. The status and type of a thread is indicated by a special icon and a textual note next to the thread's name.
So now that you have no frames available means all frames are closed for debugging. Might be due to app being force closed or misbehaving at that line in any way. Try debugging the statement after which this happens to get rid of this behaviour.
Hope it helps
When you get the message "frames not available" it means that no more frames are available for debugging. The frames are part of Android Studio's debugging which gives you access to the list of threads running in your application. It is the long list of processes you see in the debugging window. So what is happening is that Android Studio loses knowledge of the threads it had before you set the breakpoint when you are stepping out. This might be happening in your case because by default when you set a breakpoint, it stops execution of all threads. When you step out, the threads that follow rely on the threads before to work which is what closes the app. Since you are setting your breakpoint at getCurrentDetails, my best assumption is that it did not get the response from OKHttp in time since it is happening in a background thread. You can try two things to get it to work. First, try and right click on the breakpoint and change the breakpoint from pausing all threads to just that thread. This should allow OKHttp to get the response in time before being cut off. Or, shift your breakpoint further down and see if it works.
Having the same issue, restarting AS works for me.
File --> Invalidate Caches/Restart fixed the problem that I had.
Related
My app is hanging when returning from one activity back to a ListView activity. I know the ListView is slow and RecyclerView is a better replacement, however I don't think this would be causing complete UI freezing for multiple seconds (I see ListView lag however this hang is 100% unresponsiveness). The hanging is almost always persistent until you close and re-open the app, and ANR is almost always triggered.
I have messed around with TraceView and see a lot of Object.wait() calls taking up CPU time, but I don't know how to interpret that. Where can I go from here?
Edit (more info):
There is a lot going on from SQLite, image loading, rest calls and so on going on in the app and I've been running Strict Mode and fixing issues but nothing shows up in Strict Mode logs when this type of hang happens (which is very reproduceable)
Screenshot of systrace during hang
high cpu loading screenshot link
Please see the screenshot hyperlink. Does anyone knows what's going on?
I want to do keep detecting and send message through socket in while loop. But it cause my app high cpu loading and getting slower and slower, then stop finally. So, I simply the code like screenshot. The problem is still there. If I can't write the code like screenshot and of course I can reach what I want. Does anyone have any idea?
I monitor by android studio and get 97% runs in "android.os.MessageQueue.nativePollOnce".
Thank you for your help~
"The thread has a while loop to deal with tasks about socket"
ANRs indicates you are doing an excessive amount of work on the primary thread. Without showing your code we cannot be sure what causes it, but since you mentioned a while loop I guess you are either not running on a new thread or blocking the UI thread in some other place.
I'm loading a bunch of images using AsyncTasks, creating bitmaps. Lots of recycling views going on etc. Without going into the gory details, I would like to know if there is any way I can get some realtime stats on threads that might be helpful. In particular what I am noticing is that the doInBackground runs really fast once it gets kicked off, but it seems they it takes a while for these tasks to run. So I was wondering how I can know how many threads are running at a given time. I have seen the dreaded 128 limit on thread exception with 10 in queue, but thats once there is an overload, I would like to be able to watch this as the program is running. Hopefully this visibility will tell me something. BTW, I did try bumping of the thread priority within the doInBackground() but again its really not that it is not fast once it runs, its that it does not get scheduled to run fast. I'm on Android Studio, what kind of tools are available?
When debugging and stopped on a breakpoint you can scroll through all the launched threads and their current execution points (the spinner on the left of the debug tab).
Knowing where your threads are started you can launch method profiling on this method and see how your threads are performing (a "timer" button on the left of the android tab).
I have an app developed with Sencha Touch and phonegap. At one point, it downloads data from a server and, once it has received a successful response, it displays the next screen. I found, when bundling it up as an iOS app, that it would transition to that next screen, but not display anything, reporting low memory. So I simplified the layout of that next screen (the DOM structure was pretty complex) and it now works on the iOS simulators and on my iPhone.
However, in Android, I can see from the output of my console.log statements that it successfully retrieves the data and fires an event to display the next screen. It then sits around for ages before it displays that screen, even though my console.log statements show that the 'painted' event of that screen has been fired.
Eventually, the screen does show up, but all the controls on the screen are unresponsive to touch. Is it likely that I need to simplify the structure of that screen still further? As the iOS version received a low memory warning before I simplified the page structure, I suspect the Android version may have a similar problem, but I don't know how to monitor memory usage. In the Android version, shortly before the screen does eventually display I see the following in logcat:
UpdateFrameCache: pending style recalc, ignoring
And on the screen which is unresponsive, when I tap some (but not all) of the unresponsive controls, I see:
Got ACTION_DOWN but still waiting on stale event. Catching up.
Eventually, the app will just close itself, with:
Fatal signal 11 (SIGSEGV) at 0xbbbadbeef (code = 1)
Any help gratefully received.
If you perform intensive computations in the UI thread, it might explain why it takes so long.
Try using AsyncTask or a Service if you have some backgorund computations to do. Once they are done, update the interface in the UI thread.
Gordak
I am frequently using gdbServer to debug a remote Android application. The area I have set breakpoints in is a shared library, written in c++.
Stepping through the code is extremely slow. Does anyone know why this is? My assumption is that the JNI calls to the library impose a large delay.
My assumption is that the JNI calls to the library impose a large delay.
When you are at a breakpoint, and execute step command in GDB, no JNI calls are actually happening (you are already in native code, and just continue until next line, or step into the next function, what's JNI got to do with it?)
Unfortunately, step could be slow even when executing natively; especially so for optimized code.
How could step command work? In theory, GDB could examine instructions for the current line, discover that there are no CALLs and JMPs, set a temporary break of the first instruction on the next line, and continue. That would be fast, but that's not how GDB actually works.
What it does instead is something simpler: it single-steps the processor, and at each instruction asks "am I now stopped on the same line I was last time I stopped?". If "yes", single-step again, until the answer is "no". You can observe this behavior by setting set debug infrun 1.
Depending on how many instructions your current line has, it could take a 100 single-steps to complete your step command. That can be slow with native debugging, it can become much slower still when using remote gdbserver, as every time single-step completes, GDB needs to ask gdbserver "where am I now". That's a lot of packets flying between GDB and gdbserver. You can observe these packets with set debug remote 1.
Thus the factors that
GDB remote protocol is "chatty",
that each packet needs to go to the device and back over a (relatively) slow link, and
that a single step may involve a 100 of these
combine to produce the very slow step executions you've observed.
A possible workaround is to avoid doing steps. Instead, set breakpoints, and examine program state at each. Eventually you'll get to a breakpoint that is "downstream" from the bug (i.e. the program is already in a bad state). Now set a new breakpoint somewhere "upstream" from that, and look at the state there. Using "divide and conquer" approach, you'll pretty soon zero in on the problem.