History log of /frameworks/base/core/jni/android_os_MessageQueue.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
63a37153238d95cf8897939e6d6e8fbc56e9ec7f 10-Jan-2014 Ashok Bhat <ashok.bhat@arm.com> AArch64: Use long for pointers in android/os/MessageQueue

Long is used in android/os/MessageQueue class to store
pointers as native pointers can be 64-bit.

In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)

Change-Id: I7e901b8515a5b5e3afe1dadaaf3e5c186955c2a0
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
efa92b2182ab581873aa8e75d596e2e363bd5e6d 03-May-2013 Dianne Hackborn <hackbod@google.com> Cleanup some of the thread merging.

Adds an optimization for checking whether a looper is stuck,
with a new Looper method to see if its thread is currently
idle. This will allow us to put a large number of loopers
in the monitor efficiently, since we generally won't have to
do a context switch on each of them (since most looper threads
spend most of their time idle waiting for work).

Also change things so the system process's main thread
is actually running on the main thread. Because Jeff
asked for this, and who am I to argue? :)

Change-Id: I12999e6f9c4b056c22dd652cb78c2453c391061f
864693461b6223a995038847591b17abe2de647e 28-Jan-2013 Jeff Brown <jeffbrown@google.com> Optimize Looper JNI code.

Use static native methods.

Release the native looper objects as soon as the Looper quits
instead of waiting until the GC finalizer to take care of it.

Change-Id: I02783e48782a8f972ec2138862f700ade33d8e78
603b44589682db3ff33ade172facb0c5e309f1be 07-Apr-2012 Jeff Brown <jeffbrown@google.com> Ensure that apps crash if they throw exceptions.

Previously, if an app threw an uncaught exception in an input,
vsync or native activity callback, it would log the exception then
continue limping merrily along. In the case of input, it
could result in an ANR occurring because we had not drained
all of the pending input events and marked them as finished
(we only marked the most recent one finished).

Bug: 6304124
Change-Id: I87d76f7fd605e1a8af1237c66d8d62973080277e
17cc33a35729733aaa0a7706f38b1c45f0b1590a 06-Mar-2011 Carl Shapiro <cshapiro@google.com> Remove unused JNI global references.

Change-Id: Ie4886ab66538e293832c3bc3d6023e34304a2d21
415d8c38199e258dfce92cdb0c69e056b3b51ef8 06-Oct-2010 Jeff Brown <jeffbrown@google.com> Switch Looper back to using poll() instead of epoll().

Added a couple of micro-optimizations to avoid calling wake() unnecessarily
and reduce JNI overhead slightly.

Fixed a minor issue where we were not clearing the "next" field of Messages
returned by the MessageQueue so the Message would hold on to its successor
and potentially prevent the GC from collecting it if the message were leaked

Change-Id: I488d29417ce0cdd7d0e447cda76ec978ef7f811c
4fe6c3e51be77e35f40872cdbca6c80f8f8b7ecb 14-Sep-2010 Jeff Brown <jeffbrown@google.com> Replace epoll() with poll() and rename PollLoop to Looper.

As part of this change, consolidated and cleaned up the Looper API so
that there are fewer distinctions between the NDK and non-NDK declarations
(no need for two callback types, etc.).

Removed the dependence on specific constants from sys/poll.h such as
POLLIN. Instead looper.h defines events like LOOPER_EVENT_INPUT for
the events that it supports. That should help make any future
under-the-hood implementation changes easier.

Fixed a couple of compiler warnings along the way.

Change-Id: I449a7ec780bf061bdd325452f823673e2b39b6ae
85448bbecd4e0909eecfab15b7c3605f114d0427 07-Jul-2010 Dianne Hackborn <hackbod@google.com> Add new glue code for writing native apps.

This factors out the boiler-plate code from the sample
app to a common glue code that can be used for everyone
writing this style of app: a dedicated app thread that
takes care of waiting for events and processing them.

As part of doing this, ALooper has a new facility to allow
registration of fds that cause ALooper_pollOnce() to return
the fd that has data, allowing the app to drive the loop
without callbacks. Hopefully this makes some people feel better. :)

Also do some other cleanup of the ALooper API, plus some
actual documentation.

Change-Id: Ic53bd56bdf627e3ba28a3c093faa06a92be522b8
682674154e3fe88f6061245145f934f25f1a2eb8 03-Jul-2010 Dianne Hackborn <hackbod@google.com> Add new native Looper API.

This allows us to avoid exposing the file descriptor of
the event queue; instead, you attach an event queue to
a looper. This will also should allow native apps to be
written without the need for a separate thread, by attaching
the event queue to the main thread's looper and scheduling
their own messages there.

Change-Id: I38489282635895ae2cbfacb88599c1b1cad9b239
46b9ac0ae2162309774a7478cd9d4e578747bfc2 23-Apr-2010 Jeff Brown <jeffbrown@google.com> Native input dispatch rewrite work in progress.

The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.

Includes part of the new input event NDK API. Some details TBD.

To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.

There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.

End-to-end event dispatch mostly works!

To do: event injection, rate limiting, ANRs, testing, optimization, etc.

Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
fa9e7c05c7be6891a6cf85a11dc635a6e6853078 06-May-2010 Christopher Tate <ctate@google.com> Sketch of Native input for MessageQueue / Looper / ViewRoot

MessageQueue now uses a socket for internal signalling, and is prepared
to also handle any number of event input pipes, once the plumbing is
set up with ViewRoot / Looper to tell it about them as appropriate.

Change-Id: If9eda174a6c26887dc51b12b14b390e724e73ab3