- 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
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
This change merges debug.hwui.profiling and profiling_visualize.
Now only the first property exists and accepts the values true, false
and visual. This enables setting the property from Settings.
Change-Id: I16a11fe23ac1a6bb907a1a826e418d6b3994b56c
When profiling is enabled with debug.hwui.profile set to true,
setting debug.hwui.profile_visualizer to true will display the
profiling data directly on screen.
Change-Id: I3d5fe3f0347090815087b1cbfce66b8e76d9347b
An earlier fix made it possible to call requestLayout() during layout
(which is not recommended in most cases outside of a ListView) without
ending up with blank content and internal layout flags in a confused state.
However, that fix incorrectly detected a problem in some cases (such as
ListView practices of adding views during layout) which were actually okay;
as long as you make sure to measure and layout your children properly
before returning from layout(), then it's not a problem. We were improperly
spamming the log with supposed problems, and causing more overhead in correct
cases by running a full request/measure/layout pass after the first layout
pass, all of which is unnecessary in cases where the containers know what
they're doing.
This new fix changes the logic to only cause the second layout pass (and third,
posted to the next frame, if things are really done incorrectly) if the layout-request
flags are still set on the requesting views after the full layout pass is complete.
This situation causes the blank screens we've seen in buggy apps, and is exactly
what we should avoid. However, correct cases (e.g., ListView) will not have these
problems because they run measure/layout correctly after the request calls, which
clears these flags. The upshot is that buggy cases will be detected and compensated for
(by clearing the flags and then running a second request/measure/layout pass, as in the
original fix) and non-buggy cases will be noop'd, going back to their previous, working
logic flow.
The bug below is one of the buggy apps to demonstrate this problem. I noticed that the
original problem (blank screen) is no longer reproducible. I suspect that logic was
added to the app to force a refresh after it is attached. You can still detect the problem
(and the fix) by seeing that prior to the fix (say, on mr1.1) there is a delay of about
a second between the end of the progress bar updates and the showing of content on a
screen that used to just remain blank. With the fix (both the previous version and this
one), the content is updated immediately, because we now handle the buggy request-
during-layout situation in the same frame as it occurs.
Issue #6914123 News and Weather app sometimes loads to a blank screen
Change-Id: I4c34817cc3dd44ba422ff50de4321624c0824d83
1. This patch takes care of the case where a magnified window is covering an unmagnigied
one. One example is a dialog that covers the IME window.
bug:7634430
2. Ensuring that the UI automator tool can connect and correctly dump the screen.
bug:7694696
3. Removed the partial implementation for multi display magnification. It adds
unnecessary complexity since it cannot be implemented without support for
input from multiple screens. We will revisit when necessary.
4. Moved the magnified border window as a surface in the window manager.
5. Moved the mediator APIs on the window manager and the policy methods on the
WindowManagerPolicy.
6. Implemented batch event processing for the accessibility input filter.
Change-Id: I4ebf68b94fb07201e124794f69611ece388ec116
All three of these are interrelated!
* Allow broken MeasureSpec values. The long-standing implementation
of MeasureSpec.makeMeasureSpec has been to add both values rather
than masking/or-ing the values together. Some old code relied on
this, such as if it mixed up size/mode params.
* Disable ImageView adjustViewBounds allowing the view to grow beyond
its initial size. A bug in RelativeLayout in the presence of the
above MeasureSpec fix causes this not to work properly in apps.
* Allow RelativeLayout to send overflowed/bogus MeasureSpec values
when measured with MeasureSpec.UNSPECIFIED mode. Some apps have
custom child views that do not properly handle UNSPECIFIED
measurements, but the exact overflow semantics caused this to
generate AT_MOST $REALLYBIG MeasureSpecs for those views instead if
they were placed inside a RelativeLayout in a scrolling container.
Change-Id: I977a5f1ba5637f0cba3d26a70139e2bcd021fc9c
