| 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
|