| 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>
/frameworks/base/core/jni/android_os_MessageQueue.cpp
|
| 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
/frameworks/base/core/jni/android_os_MessageQueue.cpp
|
| 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
/frameworks/base/core/jni/android_os_MessageQueue.cpp
|
| 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
/frameworks/base/core/jni/android_os_MessageQueue.cpp
|
| 17cc33a35729733aaa0a7706f38b1c45f0b1590a |
|
06-Mar-2011 |
Carl Shapiro <cshapiro@google.com> |
Remove unused JNI global references.
Change-Id: Ie4886ab66538e293832c3bc3d6023e34304a2d21
/frameworks/base/core/jni/android_os_MessageQueue.cpp
|
| 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
somehow.
Change-Id: I488d29417ce0cdd7d0e447cda76ec978ef7f811c
/frameworks/base/core/jni/android_os_MessageQueue.cpp
|
| 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
/frameworks/base/core/jni/android_os_MessageQueue.cpp
|
| 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
/frameworks/base/core/jni/android_os_MessageQueue.cpp
|
| 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
/frameworks/base/core/jni/android_os_MessageQueue.cpp
|
| 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
/frameworks/base/core/jni/android_os_MessageQueue.cpp
|
| 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
/frameworks/base/core/jni/android_os_MessageQueue.cpp
|