History log of /frameworks/base/include/android_runtime/android_app_NativeActivity.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
a44dd26a75e24cc021802288fb81f4761e47be6b 11-Apr-2013 Michael Wright <michaelwr@google.com> Rewrite input handling for native applications

Bug: 8473020
Change-Id: Ic4353d8924ab877bec21aff8c2dba9fe725bf906
2b6c32ca4177f1a97307f9cbd81ca485df28762c 13-Mar-2012 Jeff Brown <jeffbrown@google.com> Fix spurious ANRs in native activities.

Some native activities experienced ANRs when the input consumer
deferred an input event due to client-side batching. If the
input channel was fully emptied then the client had no way of
knowing that it should wake up to handle the deferred input event.

This patch also fixes some lock issues in the native activity
input queue implementation. In at least one error case, it
was possible for a function to exit without releasing the lock.

Bug: 6051176
Change-Id: I4d9d843237e69b9834f8d8b360031b677fcab8c3
b93a03f841d93498bfea6cc92a22faa34bce1337 18-Feb-2012 Mathias Agopian <mathias@google.com> frameworks/base refactoring.

First step. Move libui includes to their new home: androidfw.

Change-Id: Ic042b52fdba72f30edc3cc6339bf30b4c1b99662
072ec96a4900d4616574733646ee46311cb5d2cb 07-Feb-2012 Jeff Brown <jeffbrown@google.com> Implement batching of input events on the consumer side.

To support this feature, the input dispatcher now allows input
events to be acknowledged out-of-order. As a result, the
consumer can choose to defer handling an input event from one
device (because it is building a big batch) while continuing
to handle input events from other devices.

The InputEventReceiver now sends a notification when a batch
is pending. The ViewRoot handles this notification by scheduling
a draw on the next sync. When the draw happens, the InputEventReceiver
is instructed to consume all pending batched input events, the
input event queue is fully processed (as much as possible),
and then the ViewRoot performs traversals as usual.

With these changes in place, the input dispatch latency is
consistently less than one frame as long as the application itself
isn't stalled. Input events are delivered to the application
as soon as possible and are handled as soon as possible. In practice,
it is no longer possible for an application to build up a huge
backlog of touch events.

This is part of a series of changes to improve input system pipelining.

Bug: 5963420

Change-Id: I42c01117eca78f12d66d49a736c1c122346ccd1d
3915bb845b032dc184dba5e60970b803390ca3ed 05-Nov-2010 Jeff Brown <jeffbrown@google.com> Tell system server whether the app handled input events.

Refactored ViewRoot, NativeActivity and related classes to tell the
dispatcher whether an input event was actually handled by the application.

This will be used to move more of the global default key processing
into the system server instead of the application.

Change-Id: If06b98b6f45c543e5ac5b1eae2b3baf9371fba28
db28a94d499f995b467b07cee5c9b9119f538b1c 22-Oct-2010 Dianne Hackborn <hackbod@google.com> Fix issue #3117918: No way to finish a native activity

Change-Id: Ic53e712f7ab5412d72a31b96ecba252344b91644
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
42c03e579aade011b451e2a13ea3f44a2ef0056a 08-Sep-2010 Dianne Hackborn <hackbod@google.com> Modify native ALooper to take an explicit ident.

The ALooper API now uses an explicit "identifier" for the integer
that is returned rather than implicitly using the fd. This allows
the APIs that had the fd to be a little more sane.

Change-Id: I8507f535ad484c0bdc4a1bd016d87bb09acd7ff0
2c6081ce3593712f30dacd990a97209c791d6ced 16-Jul-2010 Dianne Hackborn <hackbod@google.com> Implement native key pre-dispatching to IMEs.

This significantly re-works the native key dispatching code to
allow events to be pre-dispatched to the current IME before
being processed by native code. It introduces one new public
API, which must be called after retrieving an event if the app
wishes for it to be pre-dispatched.

Currently the native code will only do pre-dispatching of
system keys, to avoid significant overhead for gaming input.
This should be improved to be smarted, filtering for only
keys that the IME is interested in. Unfortunately IMEs don't
currently provide this information. :p

Change-Id: Ic1c7aeec8b348164957f2cd88119eb5bd85c2a9f
d76b67c340d1564abf8d14d976fdaf83bf2b3320 14-Jul-2010 Dianne Hackborn <hackbod@google.com> IME events are now dispatched to native applications.

And also:

- APIs to show and hide the IME, and control its interaction with the app.
- APIs to tell the app when its window resizes and needs to be redrawn.
- API to tell the app the content rectangle of its window (to layout
around the IME or status bar).

There is still a problem with IME interaction -- we need a way for the
app to deliver events to the IME before it handles them, so that for
example the back key will close the IME instead of finishing the app.

Change-Id: I37b75fc2ec533750ef36ca3aedd2f0cc0b5813cd
289b9b62372ef52a06113b83dfb870e2c2fb325a 09-Jul-2010 Dianne Hackborn <hackbod@google.com> Add ANativeWindow API for directly drawing to the surface bits.

Also other cleanup and fixes:

- We now properly set the default window format to 565.
- New APIs to set the window format and flags from native code.
- Tweaked glue for simpler handling of the "destroy" message.
- Um, other stuff.

Change-Id: Id7790a21a2fa9a19b91854d225324a7c1e7c6ade