The efficiency of key, trackball and generic motion event
dispatch is greatly influenced by the IME dispatch cycle.
This change simplifies the dispatch of focused input events
and avoids causing event processing to be requeued on the
handler and delayed unnecessarily.
Bug: 7984576
Change-Id: Id82624a3f32c05efe6ee5c322bd55bf2ab21525d
The efficiency of key, trackball and generic motion event
dispatch is greatly influenced by the IME dispatch cycle.
This change simplifies the dispatch of focused input events
and avoids causing event processing to be requeued on the
handler and delayed unnecessarily.
Bug: 7984576
Change-Id: Id82624a3f32c05efe6ee5c322bd55bf2ab21525d
Use this to track the package name of applications
accessing GPS.
And now the app ops service can enforce that callers
must provide valid package names.
Change-Id: I842a0abe236ea85f77926d708547f0f95c24bd49
When switching to a widget, examine its hierarchy to determine if it
contains TextClocks that show hour and minute for the local timezone.
If so, hide the status bar clock. Doesn't fix closing walls.
Bug: 7667638
Change-Id: I1e2c40345c9e5eb0193efd70838c7ca9f779190b
I made a mistake of missing out on static for CREATOR on a Parcelable
and it threw a NPE which was not obvious. We do not get NoSuchFieldException
when CREATOR exists but is not static.
Change-Id: Ib06f60797c00722075255d45e8189f8cebef9ae2
Bug: 7617139
WebViewFactoryProvider.getProvider() is thread safe, and when
called from findAddress() this is giving a spurious strict mode
warning.
Also removing obsolete comment while here.
Change-Id: I0b36bc23c13c9c9bec26edaf32ee83ade88982c8
- add mirrored version of the icons
- make VolumePanel respond to layout direction changes
- make AudioService propagate layout direction changes to the VolumePanel
Change-Id: Ibb884ab81641c319a9b7bea1381066f3f19581f0
Initial implementation, tracking use of the vibrator, GPS,
and location reports.
Also includes an update to battery stats to also keep track of
vibrator usage (since I had to be in the vibrator code anyway
to instrument it).
The service itself is only half-done. Currently no API to
retrieve the data (which once there will allow us to show you
which apps are currently causing the GPS to run and who has
recently accessed your location), it doesn't persist its data
like it should, and no way to tell it to reject app requests
for various operations.
But hey, it's a start!
Change-Id: I05b8d76cc4a4f7f37bc758c1701f51f9e0550e15
1. ViewRootImpl was keeping reference to the old focused view so it can
call back the global on focus change listener when another view gets
focus. The stashed reference, however was not cleared which caused a
memory leak if the last focused view was removed from the view tree.
In general keeping additional state for the last focus in ViewRootImpl
is not a good idea since this add complexity due to additional book
keeping work that is required. The view tree already keeps track of
where the focus is and it should be the only place that holds this
data. Since focus does not change that frequently it is fine to look
up the focus since this operation is O(m) where m is the depth of the
view tree. This change removes the duplicate book keeping from
ViewRootImpl and the focus is looked up as needed.
2. ViewRootImpl was calling the global focus change callbacks when focus
is gained, lost, or transferred to another view. This was done in
*ChildFocus methods. In the case of a child losing focus, i.e. in
clearChildFocus, there was a check whether focus searh yields a view
to take focus and if so it did not call back the global focus listener
assuming the the found view will take focus (the view tree gives focus
to the first focusable when a view looses focus). This is not a correct
assumption since some views override methods called as a result of
View.requestFocus that determine what the next focused view should
be. For example, HorizontalScrollView overrides onRequestFocusInDescendants
and changes the direction of the search. In fact focus search does not
take into accound ViewGroup descendant focusability. Hence, the view found
by calling the focus search from the root is not necessarily the one
that will get focus after calling requestFocus. Actually, it is
possible that the focus search will find a view but no view will
take focus. Now the View class is responsible for calling the
global focus listeners which avoids the above problem. Also this
saves book keeping in ViewRootImpl.
bug:7962363
Change-Id: Ic95a18b364e997021f3f6bb46943559aac07d95a
