The HW composer was getting confused by the transparent
window (which was a holdover from a previous design for
lights-out/fullscreen mode).
Bug: 5155982
Change-Id: I548e1b2b3b012aecba96ccf022730a9bd289e003
Unfortunately fixed internal size calculations for HC, but never the
external size calculations.
Bug: 5113898
Change-Id: Idfe8af0ba74a20aa767eb9abac431ee1c74dcf8e
Codepaths for wifi and mobile were contaminating one
another's data, which is fine when you're only showing one
at a time, but not so good in the general case.
Bug: 3481508
Bug: 5159559
Bug: 5161130
Bug: 5163206
Change-Id: I64e6f5ebd07a5b0777e7296b1c210195431e4ce6
Removed the delay after the swipe and before the remaining items
animated into their new places. Also, expanded container of app so
that it no longer clips the swiped thumbnails on the right (on tablet).
Change-Id: I3d757a3b42bf0d1e002fab5b74b47c1e7f4f97a2
Now tapping anywhere on the notification/clock/status end of
the system bar will bring up the notification panel.
Swiping up anywhere in that region works as well.
This change also adds visual touch feedback to the panel
trigger area.
Bug: 4723688
Change-Id: I5e24fea1231b798c41ddd48c0c42c283c92ebe65
When removing an item from the Recents list such that the list went from
larger than the screen to smaller (bringing the first item completely into view)
there was an artifact where the list would jump briefly, just prior to running
the transition to animate the remaining items into place.
The problem was that the custom ScrollView classes in the Recents app were
manipulating the scrollX/Y values of the items as a side-effect of any resize
of the list. Meanwhile, the LayoutTransition was manipulating both the size and
the scroll position of the list. The transition's scroll values would get clobbered by
the app's side-effect operation, causing the jump that we'd see on the screen.
The fix was to disable the side-effect operation during a layout transition.
Change-Id: I17f3f05d0e8a792e41bd46869ee700f128e63216
* Clear-all button (X) fades in and out
* "No notifications" text fades in after a few sec
* Swipe-out velocity can be much higher, dramatically
reducing perceived jankiness in clearing notifications
Bug: 5150699
Change-Id: Ic7e5254fee57724c42b6437d1c4ed8a700615208
Copy resource would fail without a good error code when the file
couldn't be found during copy.
Also destroy the target container ID during move operations since it
might exist. If the copy failed due to it existing, it would get
destroyed anyway. This way the user has a chance to have a good outcome
the first time.
Bug: 3375299
Bug: 5113898
Change-Id: I00559833f0801bc50e7cc031b462495e37a6b4ab
Its region is now treated like the system bar: inaccessible
to applications and therefore not worth reporting as part of
the display.
(Note that using setSystemUiVisibility you can gain
temporary access to the navigation bar region, unlike the
sempiternal system bar.)
The navigation bar is now considerably less in control of
its own behavior (the window manager assumes it will be a
certain size and in a certain position in landscape and
portrait). This change also fixes the navbar so that it
becomes GONE instead of merely INVISIBLE (allowing
underlying windows to expand in size accordingly).
Bug: 5052456 // the feature
Bug: 5067627 // notification shade falling behind the navbar
Bug: 4959805 // fix third-party apps relying on DisplayMetrics
Change-Id: I60257fc5c858e0edcaba8cfc1f8d58dd99a68258
This helps avoid a race condition that can sometimes leave
the status bar handle untouchable (read: hiding behind the
expanded view's transparent window, which is too large
because the close handle's height has not yet been
calculated) on first boot.
Bug: 5122306
Change-Id: I5fa2595798a66289c2c33d7c78dd16f9db066ede
Take care of updating from old component name, and don't let this happen
again.
Also tweak how we switch between static wallpapers to avoid introducing
a 4MB allocation in the system UI process when this happens -- we now
stop the current wallpaper service and start a new one, so we get a
brand new surface that we can draw only one time in to.
Change-Id: I6fc8a42b8a46bba79759bd68fb7d0684b5d897b7
We now don't automatically deny the operation if stopped, but instead
allow the activity to be destroyed and recreated as usual. We retain
the observer instance across that sequence so we keep getting progress
reports etc.
The UI now also uses the spiffy new button bar styles, and positions
the deny / confirm buttons according to ICS standards.
Bug 5115411
Change-Id: Ie760a0c8496c69f9d5881273a63ad5b5b76ff554
(The check for whether the dialog had already been shown was
accidentally removed in change I1c1bd12.)
Bug: 5069310
Change-Id: I2ea35c5891667922e78d7919132ffe599411f851
