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
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
(The check for whether the dialog had already been shown was
accidentally removed in change I1c1bd12.)
Bug: 5069310
Change-Id: I2ea35c5891667922e78d7919132ffe599411f851
Also, the panel is no longer buried below the screen edge
when there are no notifications.
Bug: 5115158
Change-Id: I01bc8a65ceebd64143a4c4c52d63641dc3cd1c77
In Japanese, the day of week should follow the date
Bug: 4606219
Change-Id: If385b3f9989bbe5f1b4bc21293d9be651e187c1f
Signed-off-by: Mike Lockwood <lockwood@android.com>
It was configuring this to have its width follow the display size
but height be a fixed amount. As a result, during a rotation we
would end up with a surface that is 800x712, which uses a lot more
memory.
The fix is to just always set the window to a fixed size, changing
it when the display size changes.
Also the expanded view was setting itself to use a hardware layer
for no reason -- it is a top view so there is no point in this,
and anyway it is doesn't even use hw rendering. This saves 1.5MB
of the layer bitmap.
This change also fixes the returned problem where the expanded
view would flicker when pulling it down in landscape.
Change-Id: If57420b0bc3fdc2706d2d3b36cb2d287b5fc9e27
* New "X" button appears in the system bar, allowing the
user to clear all notifications. Only appears when the
notifications list is showing and there are clearable
items. (Note: the textual button on phones has also been
replaced with an X.)
* Updated panel background artwork and positioning.
* Removed a bunch of old art.
Bug: 4970588
Bug: 4974043
Bug: 3509407 (regression)
Change-Id: Ibadb638cd18c4faa751cd1f311d73ceda65cb3ca
Nice to not load 4MB bitmaps in the system process.
Also, hey, with how we are now scrolling the surface instead of
the bitmap, there is no reason to keep that 4MB bitmap loaded in
to memory. So don't.
Unfortunately it looks like for some reason the VM is still
holding on to the bitmap. I'll need to figure out why. Later.
Change-Id: Ib3503756144502fc5c8d5e294248c2417c4fe8c8
When the "ongoing"/"latest" split is removed, this will be
replaced with something less odious.
Bug: 5090331
Change-Id: Ib804de66985ff5f5df2e1df3c85437a1e31f1c49
