Add classes to handling binder marshalling to and from the native
common_time interfaces (config and clock)
Change-Id: I04fc429d9af27736c4f7f9b5468011ffdd4d7eaa
Signed-off-by: John Grossman <johngro@google.com>
Bug #5553515
The People app is forcing ACTV to show the IME which had the side effect
of showing the drop down popup. ACTV was unfortunately not ready to show
the drop down if the filtering resulted in no results. Doing so was putting
ACTV in a weird state that in turn caused a window to be leaked and really
bad behavior to occur in the lower graphics levels.
Change-Id: I2ff146d5ae4e4a28edf6ea17039c9f8fdb710e4f
This adjust various paths through InputMethodManager so that the flow
in switching focus from one application to another is cleaner, resulting
in less work being done, resulting in it being able to happen quicker.
Some of the changes here avoid doing stuff when not needed, such as when
we are told to unbind but are not currently the active input. A big part
is also a change to the flow when a window receives input. Previously
this would first do a checkFocus() which would tell the input method to
switch focus to whatever view has focus in the window, followed by the
windowGainedFocus() call telling it the window had gained focus. This
would result in extra work because the input method service would first
handle the focus switch, seeing the IME is currently displayed, so the IME
would remain up and reset its focus to the new view. The app would
immediately then tell it about the window, causing the service to find out
the IME should be hidden and telling the IME, but the IME couldn't hide
itself until it had first take care of switching its input.
There is the definite potential of this breaking IME showing/hiding in
cases depending on the order things may be relying on them to happen. I
haven't seen any problems with a brief trip through the UI.
Change-Id: I8494cbd6e19e2ab6db03f2463d9906680dda058b
There is really no point disposing the display event receiver
anymore. Moreover, it's hard to choose a good time to do it
since the Choreographer only supports one-shot callbacks now.
So let's made the code simpler.
Bug: 5721047
Change-Id: I8533a54e93a787e0ca30d99a1f1eea85534b13b9
Removed the listeners and schedule animation / draw methods.
Instead all requests are posted as one-shot callbacks, which is a
better match for how clients actually use the Choreographer.
Bug: 5721047
Change-Id: I113180b2713a300e4444d0d987f52b8157b7ac15
1. Added methods to the ActivityManagerService remote interface
that allow accessing content providers outside of an application.
These methods are guarded by an internal signature protected
permission which is given to the shell user. This enables a
shell program to access content providers.
2. Implemented a shell command that takes as input as standart
fagls with values and manipulates content via the content provider
mechanism.
Change-Id: I2943f8b59fbab33eb623458fa01ea61a077b9845
Also clean up the Choreographer so that it doesn't directly extend
Handler and so that it doesn't schedule animation or drawing unless
there are listeners or callbacks attached.
Bug: 5721047
Change-Id: I35350c8d41d4fa3f8c8c7bc43edd82e581b55a68
The synchronization barrier enables selectively blocking
execution of synchronous messages until the barrier is released.
Asynchronous messages may continue running in the meantime.
The barrier is intended to be used to implement more sophisticated
scheduling policies related to view hierarchy traversals. While
traversals are pending, most messages posted to the message queue
must be held up. This is to satisfy the invariant that traversals
will occur before subsequently posted messages are handled.
The exception to this rule are "asynchronous" messages that represent
external events or interrupts that come from other components such
as VSYNC pulses, input events or sensor events. Because these messages
are typically delivered at arbitrary times, they are independent of
traversals or other typical synchronization boundaries.
Messages can now be flagged as asynchronous to indicate that they
are weakly ordered.
Bug: 5721047
Change-Id: I1446dcfbc896f33b48355adc28967ace8c8c9b9b
The framework tries to have a focused view all the time. For
that purpose when a view's focus is cleared the focus is given
to the first focusable found from the top. The implementation
of this behavior was causing the following issues:
1. If the fist focusable View tries to clear its focus it
was getting focus but the onFocusChange callbacks were not
properly invoked. Specifically, the onFocusChange for
gaining focus was called first and then the same
callback for clearing focus. Note that the callback
for clearing focus is called when the View is already
focused.
2. If not the first focusable View tries to clear focus,
the focus is given to another one but the callback
for getting focus was called before the one for clearing,
so client code may be mislead that there is more than
one focused view at a time.
3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup
was calling the super implementaion when there is a
focused child. Since there could be only one focused View,
having a focused child means that the group is not focused
and the call to the super implementation is not needed.
4. Added unit tests that verify the correct behavior, i.e.
the focus of the first focused view cannot be cleared
which means that no focus change callbacks are invoked.
The callbacks should be called in expected order.
Now the view focus clear precedes the view focus gain
callback. However, in between is invoked the global
focus change callback with the correct values. We may
want to call that one after the View callbacks. If
needed we can revisit this.
Change-Id: I8cfb141c948141703093cf6fa2037be60861cee0
Applications sometimes crashed on exit due to the display event
receiver pipe apparently being closed while still a member of the
Looper's epoll fd set.
This patch fixes a few different possible races related to
the display event receiver lifecycle.
1. The receiver used to play a little dance with the Looper,
registering and unregistering its callback after each vsync
request. This code was a holdover from a time before the
surface flinger supported one-shot vsync requests, so we can
get rid of it and make things a lot simpler.
2. When the Choreographer is being accessed from outside the UI
thread, it needs to take great care that it does not touch
the display event receiver. Bad things could happen if the receiver
is handling a vsync event on the Looper and the receiver is
disposed concurrently.
3. It was possible for the Choreographer to attempt to dispose
the receiver while handling a vsync message. Now we defer disposing
the receiver for a little while, which is also nice because we
may be able to avoid disposing the receiver altogether if we find
that we need it again a little while later.
Bug: 5974105
Change-Id: I77a158f51b0b689af34d07aee4245b969e6260d6
