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
|