As far as I know, debuggers work based on system calls like ptrace in linux, which will block the tracee and then tracer get informations from tracee's memory.
It means, if I want to use a debugger to debug the main thread in an android app process, it will block the main thread and wait for my operations, which may easily cause main thread ANR in few seconds.
So I am confused about is it really possible to debug the main thread in android app process and how?
Correct, ADP uses ptrace and blocks the main thread and this causes the application to slow down slightly while in debug mode. If you do step by step debugging the thread you put your breakpoint in will be halted completely.
For general debugging purposes this should not be an issue. Testing how smooth an application runs should be done in run mode and not in debug mode.
Related
I am processing UI instructions on a virtual machine (V8 actually) on Android in the main UI thread. This works fine. However, now I'm adding a JavaScript debugger into the mix (Stetho in my case). I can pause the UI thread when a breakpoint is hit, and even step through instructions. However, when an instruction changes the UI, the UI is not immediately updated. Instead, the view is invalidated and only when the main event loop continues processing will the updates render.
So my question is, can I force a redraw of the entire device from the UI thread without returning to the main loop? If I return to the main loop then I will blow my entire call stack, and pausing during debugging will no longer work.
I tried to get the main Looper, and I can even call Loop() on it (ideally to start processing the events), but then this will become the main loop (and you cannot quit the main looper). If anyone has any thoughts on how to simulate the main event loop, that would be greatly appreciated.
This is fun, I'm doing the same thing as you, creating a bridge between J2V8 and Stetho. The trick is to run the debugger in it's own thread. Since the debugger will have direct access to V8, it can easily manipulate the runtime, but commands going to Native code (like UI commands) will run on the main thread until they come back to the V8 runtime.
I'm using DDMS to monitor threads in my app, and I see that my app has a bunch of native threads as shown in follow picture. And time to time, the number of native threads increased as user interact with my app, which cause my app sometime does not serve as I expect. Is there anyway to kill these native threads?
There is no such thing as a "native thread" on Android, although some people might use that to refer to threads that are not attached to the VM (which would also make them invisible to DDMS). The threads happen to be executing (or waiting) in native code at the time you did a thread dump, but may spend most of their time executing bytecode. (A list of Dalvik thread states is available here.)
The names of the threads suggests that they were created without being given an explicit name. The one thread with a name, NsdManager probably exists because you're using NsdManager, which "responses to requests from an application are on listener callbacks on a seperate thread" [sic].
It's possible that you can glean some useful information from a stack trace. In DDMS, double-click the thread to get a backtrace. On a rooted device, you can kill -3 <pid> to get a full dump, including native stack frames.
Killing arbitrary threads is not allowed, as they might be holding locks or other resources. If you can determine what is starting them, and that they are unnecessary, you can prevent them from being started in the first place.
In Eclipse, I load up an Android Virtual Device, and then once it's loaded and not at the lock screen, I hit "Debug" on the Eclipse toolbar. My app runs fine (barring any errors from the last edit cycle, but that's what debugging is for). However, after I try to end my app (by hitting the back button from the main [only] activity - I have implemented a call to finish() as the last line of onBackPressed() , even though on further research it appears that hitting the back button from the main activity implicitly calls finish() ), it appears to not end the app.
The Eclipse debug perspective's Debug pane still shows the following:
MyAppName [Android application]
DalvikVM[localhost:8619]
Thread [<1> main] (Running)
Thread [<10> Binder_2] (Running)
Thread [<9> Binder_1] (Running)
I am assuming the DalvikVM line is the emulator. I do not knowingly spin up any extra threads in my app (light enough computations, so far, that I just do them all in the UI thread on button clicks, etc), so I have no idea whatsoever where Binder_1 and Binder_2 came from.
Also, when I go to debug again, thinking the app was fully shut down, the tool-tip on the debug icon is "Debug MyAppName (already running)".
Does finish() not terminate the application when it comes to Eclipse's debug hooks? Or, is there some other method I should call from the main activity that behaves like a "terminate()", that tells Android that not only the activity, but the whole app, is finished?
Yes, I am aware that Android apps' processes are not immediately killed when running on the device during the normal life cycle. I realize that I don't want to make my app kill its process stone cold dead when it comes to the shipped version. However, if this is the cause of the persistent debugger tie-in, I would at least like to implement something like if(DEBUG_MODE) trulyExit(); , either by teaching Eclipse to autokill after a finish() somehow, or by implementing some sort of trulyExit() in my main activity, to only be used during debugging. So, if I could get a few tips on how to teach Eclipse, or how one would implement a trulyExit(), that'd be awesome.
My workaround currently is closing the emulator each time. I can't think, though, that that's how you're supposed to end a debugging session...
Relevant dev environment info:
(OS: Windows 7 Professional)
IDE: Android Developer Tools build v22.0.1-685705
No additions/plugins to the ADT Eclipse, other than what Google's ADT download gives.
Test platform: Emulator, not device
(the USB port on my physical device is on the fritz, I am not sure if debugging tie-ins will still misbehave on it or not.)
This is major problem I am getting while monkey testing my application on emulator.
"activity home(in process
android.process.acore) is not
responding"
I don't know what is happening behind.
Has anybody any solution?
You are probably doing something time-consuming (like a network connection) on the event thread. You need to move all time-consuming processing into worker threads. See the article on Painless Threading.
That process don't belong to you application does it ? I think that is a system process.
Have you limited monkey to only run on your package ? Are you running emulator or target ?
Souns like monkey make your emulator or target phone "crash".
Is there a way to know all the threads that are currently running in background inside of an Android application??
Thanks!!
The user interface by default runs in a single thread!
Map<Thread, StackTraceElement[]> myMap = Thread.getAllStackTraces();
This map also contains system threads running in this application like garbage collection.
An Android application, by default, runs in a single thread. This is why it is important to spawn off threads to do significant work in your application so that the main thread can continue to respond to the OS and GUI input, avoiding the "Application Not Responding" dialog.
This information can be found in the Android development guide here.