Develop Reference

why two threads get scheduled in android poll_sched and epoll

I am trying to create thread using HandlerThread in android code :Thread gets created but some how I see two instance of it.
But when run "ps -t | grep pid" command to see the thread details , I see two threads getting generated as below:
system 3421 3487 730544 88612 SyS_epoll_ b6d58ce4 S testThread
system 3422 3487 730544 88612 poll_sched b6d58eac S testThread
Can someone please let me know what is difference between sys_epoll and poll_sched and why two threads are created?
Does Select() api can cause poll_sched ?

Android debug confusion

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.

Interpret Logcat entry: threadid=8: still suspended after undo (sc=1 dc=1 s=Y)

I am running around ten AsyncTasks after my application starts. Sometimes the emulator takes a long time to start these tasks. When this occurs, I see the following message in the log cat:
D/dalvikvm(1983): threadid=8: still suspended after undo (sc=1 dc=1 s=Y)
When the emulator executes quickly this message doesn't appear. Strangely, this behavior changed today without any modifications. Since I have explicitly assigned 512mb ram to the emulator, it is no longer extremely slow ~5min, now ~5s. On a real device I never have execution that slow.
I would like to understand what this log cat message means. I understand that the thread with the specified id is suspended and not working while in this state. But why? After what undo? What does (sc=1 dc=1 s=Y) mean?

The message comes from dvmSuspendSelf(), which threads call when the debugger (via the JDWP thread) has asked them to suspend.
The way it's supposed to work is (where "we" are a thread):
JDWP asks us to suspend
we tell it we've suspended and go to sleep
eventually, debugger wakes us up and we resume
The message is logged when the condition variable the VM is waiting on signals, but for some reason we're still marked as suspended. The code notes:
/*
* The condition was signaled but we're still suspended. This
* can happen if the debugger lets go while a SIGQUIT thread
* dump event is pending (assuming SignalCatcher was resumed for
* just long enough to try to grab the thread-suspend lock).
*/
The expectation in this case is that we got woken up unexpectedly when a signal arrived (e.g. system_server thinks there's an ANR because the main thread isn't responding because the debugger has suspended it), and if we loop around again the debugger will get a chance to clean us up and set us on our way.
The log message is printing the values of self->suspendCount (how many times have we been told to suspend ourselves), self->dbgSuspendCount (how many of those suspend requests came from the debugger, so we can "undo" all those if the debugger disconnects), and the value of the self->isSuspended boolean.
Note the "s=Y" flag disappeared in gingerbread -- the way thread suspension works was changed.

This thread is old but this answer should provide useful for users stumbling across this question months later.
Quoting a user's reply on a google group thread
There's a weird interaction between the VM and your debugger. The
thread suspended itself and then waited to be woken. However, when it
was woken the thread was still marked as being suspended (s=1) by the
debugger (d=1).
I've come across this on the emulator and on the phone itself. If the debugger is disconnected from the device (be it emulated or real), this error condition is reset. I have found no other way of escaping the problem.
Another SO answer claims this is due to debug breakpoints being out of sync - DexFile.class error in eclipse
You can try that too.
HTH

Me too come across the problem.
Simply just because after I started a new Thread(), I tried to access the stuff in the thread that had already been suspended.
Removed that code, and the problem is resolved.
HTH

Possible states for native threads on Android?

What are all the possible thread states during execution for native (C/C++) threads on an Android device? Are they the same as the Java Thread States? Are they Linux threads? POSIX threads?
Not required, but bonus points for providing examples of what can cause a thread to enter each state.
Edit: As requested, here's the motivation:
I'm designing the interface for a sampling profiler that works with native C/C++ code on Android. The profiler reports will show thread states over time. I need to know what all the states are in order to a) know how many distinct states I will need to possibly visually differentiate, and b) design a color scheme that visually differentiates and groups the desirable states versus the undesirable states.

I've been told that native threads on Android are just lightweight processes. This agrees with what I've found for Linux in general. Quoting this wiki page:
A process (which includes a thread) on a Linux machine can be in any of the following states:
TASK_RUNNING - The process is either executing on a CPU or waiting to be executed.
TASK_INTERRUPTIBLE - The process is suspended (sleeping) until some condition becomes true. Raising a hardware interrupt, releasing a system resource the process is waiting for, or delivering a signal are examples of conditions that might wake up the process (put its state back to TASK_RUNNING). Typically blocking IO calls (disk/network) will result in the task being marked as TASK_INTERRUPTIBLE. As soon as the data it is waiting on is ready to be read an interrupt is raised by the device and the interrupt handler changes the state of the task to TASK_INTERRUPTIBLE. Also processes in idle mode (ie not performing any task) should be in this state.
TASK_UNINTERRUPTIBLE - Like TASK_INTERRUPTIBLE, except that delivering a signal to the sleeping process leaves its state unchanged. This process state is seldom used. It is valuable, however, under certain specific conditions in which a process must wait until a given event occurs without being interrupted. Ideally not too many tasks will be in this state.
For instance, this state may be used when a process opens a device file and the corresponding device driver starts probing for a corresponding hardware device. The device driver must not be interrupted until the probing is complete, or the hardware device could be left in an unpredictable state.
Atomic write operations may require a task to be marked as UNINTERRUPTIBLE
NFS access sometimes results in access processes being marked as UNINTERRUPTIBLE
reads/writes from/to disk can be marked thus for a fraction of a second
I/O following a page fault marks a process UNINTERRUPTIBLE
I/O to the same disk that is being accessed for page faults can result in a process marked as UNINTERRUPTIBLE
Programmers may mark a task as UNINTERRUPTIBLE instead of using INTERRUPTIBLE
TASK_STOPPED - Process execution has been stopped; the process enters this state after receiving a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU signal.
TASK_TRACED - Process execution has been stopped by a debugger.
EXIT_ZOMBIE - Process execution is terminated, but the parent process has not yet issued a wait4() or waitpid() system call. The OS will not clear zombie processes until the parent issues a wait()-like call.
EXIT_DEAD - The final state: the process is being removed by the system because the parent process has just issued a wait4() or waitpid() system call for it. Changing its state from EXIT_ZOMBIE to EXIT_DEAD avoids race conditions due to other threads of execution that execute wait()-like calls on the same process.
Edit: And yet the Dalvik VM Debug Monitor provides different states. From its documentation:
"thread state" must be one of:
1 - running (now executing or ready to do so)
2 - sleeping (in Thread.sleep())
3 - monitor (blocked on a monitor lock)
4 - waiting (in Object.wait())
5 - initializing
6 - starting
7 - native (executing native code)
8 - vmwait (waiting on a VM resource)
"suspended" [a separate flag in the data structure] will be 0 if the thread is running, 1 if not.

If you design a system app that has to work with threads in even more advanced way than usual app, I'd first start by examining what API is available on Android to access threads.
The answer is pthread = POSIX threads, with pthread.h header file, implemented in Bionic C library. So you have starting point for knowing what you can achieve.
Another thing is that Android doesn't implement full pthread interface, only subset needed for Android to run.
More on threads + Bionic here, and how they interact with Java and VM is described here. Also I feel that thread is actually a process, as my code uses setpriority(PRIO_PROCESS, gettid(), pr); to set new thread's priority - I don't recall where I got this info, but this works.
I assume that thread may be in running, finished or blocked (e.g. waiting for mutex) state, but that's my a bit limited knowledge since I never needed other thread state.
Now question is if your app can actually retrieve these states using available API in NDK, and if there're more states, if your users would be really interested to know.
Anyway, you may start by displaying possibly incomplete states of threads, and if your users really care, you'd learn about another states from users' feedback and requests.

Google:
Thread.State BLOCKED The thread is blocked and waiting for a lock.
Thread.State NEW The thread has been created, but has never been started.
Thread.State RUNNABLE The thread may be run.
Thread.State TERMINATED The thread has been terminated.
Thread.State TIMED_WAITING The thread is waiting for a specified amount of time.
Thread.State WAITING The thread is waiting.
These states are not very well explained - I don't see the difference between BLOCKED and WAITING, for example.
Interestingly, there is no 'RUNNING' state - do these devices ever do anything?

Debugging Event code

If I wish to debug some code for a UI event, e.g.
public boolean onTouchEvent(MotionEvent me)
{
// code to be debugged
}
... and I hold onto this thread (UI):
After 5 seconds I will get this warning: Key dispatching timed out sending to com.hos/com.hos.MyActivity ... null to Window ...
After 20 seconds I will get: Key dispatching timed out sending to com.hos/com.hos.MyActivity ... null to Window ... Continuing to wait for key to be dispatched
After 35 seconds I will get: Key dispatching timed out sending to com.hos/com.hos.MyActivity ... null to Window ... timed out expired process next Key & find new target
At this point, not only is my application frozen but so is the phone. Quite often I need to wait for the ANR and sometimes hard restart the phone.
Is there a way to debug this code for more than 35 seconds without freezing the app / phone?

If your processing may take more than milliseconds to process you may want to consider launching the processing in another thread which has access to a handler in the main thread.
Once you are done processing, you can then pass a message over to your handler which will then execute on the UI thread. This will help prevent those errors from coming up as well as make debugging your code easier.
If you are looking for an automated UI testing framework, perhaps you could look into integrating Robotium into your project.