| 4610eeff9c6c4789705b6550a57333150d39e970 |
|
03-Dec-2015 |
Chet Haase <chet@google.com> |
Revert "Add support for partial view layouts"
This reverts commit c55d5072ac52cee1811b52406419228fa81119ce.
There were several bugs related to incorrect handling of various
layout issues (layout not being run on containers/views that needed
it), reverting to take another run at it outside of master.
Issue #25980198 requestLayout() sometimes doesn't result in measure/layout for view
Change-Id: Ic0e159cbcf6171652d8fd1bee9ae44a3977cea04
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| c55d5072ac52cee1811b52406419228fa81119ce |
|
19-Dec-2014 |
Adam Powell <adamp@google.com> |
Add support for partial view layouts
Traditionally, when a view called requestLayout it would force
recursive requestLayout calls for all parent views up the
hierarchy. This meant that there was no way to determine at traversal
time whether a parent view itself needed layout, or if just one of its
descendants did.
Add a ViewParent method requestPartialLayoutForChild(View). This lets
a caller state that a particular child of a given parent needs a
remeasure and relayout at its current measured size and position
within that parent. This can help prevent the full-tree relayout often
caused by otherwise trivial changes. Partial layouts are processed
after any pending "full" relayout during ViewRoot traversals, but
before drawing.
Add a ViewGroup method requestLayoutForChild(View). This lets a
ViewGroup decide whether it is more appropriate to request a
traditional relayout or a partial layout for itself or just the child
that changed.
Add a ViewParent method findDependentLayoutAxes. This allows a caller
to check if the ViewParent's layout is dependent on a specific direct
child view along one or both axes. Called recursively, this can be
used to determine if a change in a child view can be isolated to a
partial layout, even if its direct parent's own layout is tied to its
other ancestors. (e.g. MATCH_PARENT, LinearLayout weights)
Implement ViewGroup#requestPartialLayoutForChild to call new
ViewParent method findDependentLayoutAxes and based on the result,
either request a full layout for itself or a partial layout for the
child in question.
Implement findDependentLayoutAxes for common framework ViewGroups. A
private implementation in ViewGroup is available for use by framework
classes that will deal with basic LayoutParams. These implementations
specifically check for derived LayoutParams classes and abort the
optimization if they find something beyond their expected parameter
types.
Change-Id: I0a1a9b79293d17d4fae8d9892b96d3586f9401ae
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| 08c7116ab9cd04ad6dd3c04aa1017237e7f409ac |
|
28-Feb-2015 |
John Spurlock <jspurlock@google.com> |
Remove unused imports in frameworks/base.
Change-Id: I031443de83f93eb57a98863001826671b18f3b17
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| 5352a89e8a633e348c450aaee835d2a2d72e8ae0 |
|
21-Aug-2014 |
Adam Powell <adamp@google.com> |
Unify code paths for collapsing action views in action bars
This reverts a well-intentioned bugfix that made
ActionBarOverlayLayout focusable in touch mode and caused issues with
some activity layouts. Removes the associated key handling code for
the Back key in ActionBarOverlayLayout and handles it at a higher
level in Activity instead. (This same code path was already in use by
ToolbarActionBar.)
Bug 17105724
Change-Id: I57e4cace44a6d11f25a2549644b565446d616a52
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| 90e854ab7b470a1f41d70df523dfa451cecdf683 |
|
13-Aug-2014 |
Chet Haase <chet@google.com> |
ActionBarOverlay needs to be focusable
Issue #16654827 Settings search does not close all the way.
Change-Id: I6e46ac828a6a5e90e29761c176899b90d32563c5
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| 720924b6a9770f03355999102a11d98c5954407c |
|
12-Jun-2014 |
Adam Powell <adamp@google.com> |
Fix incorrect dispatch of empty WindowInsets from ActionBarOverlayLayout
Fix a bug where ActionBarOverlayLayout was using a private constructor
of WindowInsets to return empty insets that should have been marked
fully consumed. This caused dispatch to further child views not to
stop appropriately, corrupting application layout in some cases.
Bug 15588587
Change-Id: I97fcefa4755addf2385a7e7b0ffbf6d3e91adc5c
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| e021e6ed8931a0a8296af182fc9b0c76b64fb0c4 |
|
24-May-2014 |
Adam Powell <adamp@google.com> |
Toolbar factoring and ActionBar functionality integration
Toolbars now can act in the role of ActionBar with the exception of
navigation modes. Expandable action views are now supported as well as
populating menu items from a host window.
Change-Id: If477db9c7ad9f95723f28cf73cbf03a07ce9d6ad
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| 4369e7d0b087d777e5012e2706acc5be9be47de7 |
|
17-May-2014 |
Adam Powell <adamp@google.com> |
Action bar refactoring, round 1
Decouple PhoneWindow and ActionBarView to allow for using Toolbar in
some circumstances later.
Change-Id: I907743e06c3a1203e21cfd84860a1884c66f3527
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| c4b416f18d83100a386ab81e934e572cd471c4b3 |
|
02-May-2014 |
Adam Powell <adamp@google.com> |
Fix a bug in querying showing state for action bars
Bug 14492418
Change-Id: I8d24fd90a8d4004ace186f5ce84ba68fc8419307
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| b36e4f944fe28ce68182f9ec91e5341866b49084 |
|
01-May-2014 |
Adam Powell <adamp@google.com> |
Add support for hiding action bars on scroll.
Also tweak the nested scrolling API around nested flings and fix a bug
where recursive nested scrolling would stop prematurely.
Change-Id: I561226db878b2493970440a6af3e2332c56a1913
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| e43340c80dc66c45edc793ecd0343774aa34d108 |
|
18-Mar-2014 |
Adam Powell <adamp@google.com> |
android.widget.Toolbar
Add the new Toolbar widget for use in app layouts.
ActionBar can now be used as a point of control for either a
traditional window decor action bar or for a Toolbar that appears
inline in an Activity's layout.
ToolbarActionBar is currently WIP.
Change-Id: I0da093e5645840f4fd032aa34efa0ae5f1825ff2
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| 14a9738330c14410378fe2ba1c25404a444adaf3 |
|
18-Mar-2014 |
George Mount <mount@google.com> |
Fix ActionBar layout bug when INVISIBLE.
ActionBar did not layout properly when INVISIBLE, but worked
when VISIBLE or GONE.
Change-Id: I30ca85377f3516c79174a35b65648d4ca68e927a
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| 46e38fd9abe1af3ccb903a80ff89bc3faef4d3e3 |
|
03-Feb-2014 |
Adam Powell <adamp@google.com> |
Refactoring of fitSystemWindows to applyWindowInsets for views
Applying insets is now handled by:
* WindowInsets class - Encapsulate system insets and local decor
insets into a single object, written specifically so that new inset
categories may be added later. Apps cannot construct their own
WindowInsets, only clone with optional modifications. This is to
prevent losing data in the event of new insets added in the future.
* onApplyWindowInsets - Actually perform the application of insets.
* OnApplyWindowInsetsListener - Allow an app to use a separate
Listener object to apply insets to a View. This allows for things
like support lib integration in custom views written for older
versions where the verifier would otherwise complain about the use
of the new WindowInsets class as a method parameter. It also allows
for applying insets in a custom way without writing a custom view.
* dispatchApplyWindowInsets - Dispatch the call to self and children
in turn, if applicable. An OnApplyWindowInsetsListener will override
the behavior of the view's default onApplyWindowInsets method; a
listener wishing to call down to the 'superclass' implementation as
part of its own operation should call view.onApplyWindowInsets. App
code should generally not override this method and instead override
onApplyWindowInsets or provide a listener.
Compatibility support with the existing fitSystemWindows method has
been provided in both directions: for code that previously called
fitSystemWindows on arbitrary views and also for code that overrode
the fitSystemWindows method in custom views. A view that supports the
newer onApplyWindowInsets mechanism should not mix that behavior with
other calls to fitSystemWindows or vice versa. Support lib-style code
should take care to consistently use one mechanism or the other at
runtime.
Change-Id: Ie88b96e0382beb5d3c3f6cd013f7043acbc0a105
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| e8222dddaf2e3da14380101e818d4254899e0c0d |
|
05-Sep-2013 |
Chet Haase <chet@google.com> |
Change build version from KEY_LIME_PIE to KITKAT
Issue #10631619 Change build version to KitKat
Change-Id: I6ad13f6169ad74204078d36929479998b498ad8b
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| 9b0dc2894df1c3d26aa6196ecdef1989967e6ec9 |
|
31-Jul-2013 |
Adam Powell <adamp@google.com> |
Fix a regression where android:windowContentOverlay did not draw properly.
This was the victim of an earlier refactoring. Have the
ActionBarOverlayLayout draw this directly over the content so that it
can stay properly in sync with any animations and also remove an extra
couple of views from the decor layout.
Some apps now expect the broken behavior in default themes. Protect
them from themselves until they bump their targetSdkVersion.
Public bug https://code.google.com/p/android/issues/detail?id=58280
Change-Id: I4284503577e322f3e68d4a7fabda8441d3749b98
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| 474690caf8b3bece133b40914979ac2520036989 |
|
06-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #8325007: EyeEm app crashes on launch- NPE at...
...android.view.ViewGroup.measureChildWithMargins
The app is doing grungy stuff with trying to insert its own
views inside the window decor. This new custom layout of the
action bar was assuming it would get fitSystemWindows() called
at which point it would retrieve all of its child views... but
with the app doing this, it blocks the call down to
fitSystemWindows() and breaks us. So we now make the layout
manager more robust and ensure it has retrieved its children
when measuring.
Also fix an issue where the xlarge layouts were not updated.
Change-Id: I6c69f26f26b59a6aa8fa1e5788288ffce0b490ca
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| 7cf71fbdc3225778d0397b22cdaf40c812c15afb |
|
06-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
A few small missing things from the custom action bar layout.
Change-Id: I91e0b43ccf92d5c9541f80220922951acb0795e7
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| 1dc5f92716189da02aa62f508adb6099061668b5 |
|
05-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #8311263: Corrupted UI across all tabs in People app
The problem is that there are other configurations that the
action bar can be in that ActionBarOverlayLayout didn't account
for -- such as here, the nav part visible but the rest hidden.
Fixing this was non-trivial because it means that to correctly
implement fitSystemWindows() we need to in these cases take the
actual measured height of the action bar for positioning the
content view... but that is not yet available, since
fitSystemWindows() must run before layout.
To solve this, ActionBarOverlayLayout now inherits directly from
ViewGroup and implements its own custom layout. In its measure
pass it does all of the fitSystemWindows() work that is dependent
on the measured sizes of the action bar child views after those
are measured and applies them to the content view before it is
measured.
Change-Id: Ie327075d502e9c348aa80b0968c6b0403478301e
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| df7221ced3b7cd807f14e84c302fc09fd659fd68 |
|
26-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
Unify normal and overlay action bar layouts.
Switch the action bar to always use the overlay layout, and
make it smarter to do the right thing depending on whether the
action bar is in overlay mode or not.
This allows apps to use the system UI magic flags without
having to worry about whether the action bar is configured
in overlay mode or note -- just select a stable layout and it
will automatically go into overlay mode.
In the future this should also allow us to simplify the action
bar code, since it is all sitting on one common implementation.
For example, much of the logic in ActionBarImpl can be moved
to the root action bar layout, and that layout can be optimized
to do custom layout with all of the known elements it has.
Also fixed a little bug in the performance tests.
Change-Id: Iec0c0c0699754f0d1ce37402d786b4966e052a56
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| c4aad01cbbb69c916ef323693e1fd0560b0eccba |
|
23-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
Formalize overscan metrics.
The window manager now maintains and reports a new formal
"overscan insets" for each window, much like the existing
content and visible insets. This is used to correctly
position the various UI elements in the various combination
of layout options. In particular, this allows us to have
an activity that is using fitSystemWindows to have the content
of its UI extend out to the visible content part of the screen
while still positioning its fixed UI elements inside the
standard content rect (and the entire window extending all
the way into the overscan area to fill the screen as desired).
Okay, maybe that is not written so clearly. Well, it made
my head hurt too, so suffer!
The key thing is that windows now need to know about three
rectangles: the overall rectangle of the window, the rectangle
inside of the overscan area, and the rectangle inside of the
content area. The FLAG_LAYOUT_IN_OVERSCAN option controls
whether the second rectangle is pushed out to fill the entire
overscan area.
Also did some improvements to debug dumping in the window
manager.
Change-Id: Ib2368c4aff5709d00662c799507c37b6826929fd
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| 139e5aa1da51b27231ab36344cf2d0dafab23f1e |
|
06-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #6404215: New ActionBar auto-hide can conflict with application
The action bar now maintains separate states for the things that can
impact its visibility (calls from the app, action mode, system UI) so
that the changes in these won't incorrectly mix together.
Also added a hack to force the status bar to be shown when showing
the action bar for an action mode, when the UI is in a state where
the action bar would be shown with a gap above where the status bar
is.
Change-Id: Ib0950a7f585c5d2c9e77d11b237ba6e150f15ebd
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| 9801435820dc159725c0185f18f7e60e0fb1b833 |
|
06-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix so that status bar doesn't resize when hiding nav bar.
The status bar now extends behind the nav bar, and uses
fitsSystemWindows to ensure its content is not covered. We
always report a stable content insets (as if the nav bar is
visible) even if the nav bar is hidden, so the content doesn't
jump when transitioing. This does mean that if you only hide
the nav bar (and not the status bar), when in landscape you
will end up with a status bar whose right side still leaves
room for the nav bar. But why the hell would you want to do
that?
Also improve documentation on setSystemUiVisibility().
Change-Id: I8087d875f1214ef0085a91b5ed5c2f35ff2fc1b3
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| fe2b7ccca4c5fdaa0d77968b897bd789f4c87c30 |
|
01-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #6268190
Change-Id: Ib269fe34c4d3e704f4080076e173241c0761040c
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|
| 3a3a6cfd8ec12208ca75c0d0d871d19d76c34194 |
|
26-Mar-2012 |
Dianne Hackborn <hackbod@google.com> |
Add new feature to let apps layout over status bar / system bar.
The main change is a few new flags you can supply to
View.setSystemUiVisibility(). One is a new visibility mode,
SYSTEM_UI_FLAG_FULLSCREEN, which is basically the same as
the global FLAG_FULLSCREEN option for windows, but driven as
part of the system UI state.
There are also three new flags for telling the framework that you
would like to have your application's UI ignore screen
decorations -- SYSTEM_UI_FLAG_LAYOUT_NO_NAVIGATION for going
behind the navigation bar and SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
for ignoring full screen decorations (that is the status bar).
In combination with this you can use SYSTEM_UI_FLAG_LAYOUT_STABLE
to have the framework report consistent insets to your application.
When using NO_NAVIGATION, when the user taps the screen we now
also automatically clear ONLY_CONTENT, so that we atomically show
both UI elements. This should make it easy for apps like video
players that want to move between fully full-screen and regular
modes.
The ActionBar has also been extended when in overlay mode so
that it will adjust the system window insets to also account
for its space, and allow it to be hidden using the new
SYSTEM_UI_FLAG_FULLSCREEN.
Change-Id: Ic8db1adec49a0f420bfe40c1d92eb21307856d0b
/frameworks/base/core/java/com/android/internal/widget/ActionBarOverlayLayout.java
|