A change to the Animation framework now throws an exception for
negative durations, which was causing Recents to crash when
there are no recent activities.
Change-Id: I65b7d6b6d5ad4637ae93b44c147ff6193d8c03cc
The entire notification area fades out quickly before the
notification ticker appears, and fades back in when the
ticker is totally done.
This change has the side-effect of bringing back nice
animations for the notification icons when they appear by
themselves (at boot and when unlocking the device).
Bug: 3293680
Bug: 3018785
Change-Id: Id99cc20e6849f0f037fc9fba076243d362664478
This change reduces the overall timing of showing recents to make it
feel more snappy.
It also removes the first item from the list, which is assumed to be
the current app or the home screen, depending on which is currently
showing. This allows the use of muscle memory for switching between
two tasks quickly.
Change-Id: I04713c41ea235483ea4d3f712a84c56b0174394f
Also modified the shortcut key handling so that it drops chorded
Search+X keys when even if no shortcut was found. Without this
change, pressing an unhandled shortcut causes the Search widget to
pop up and the character to be typed.
Bug: 3022227
Change-Id: Ic0921428bd1270604ca28caf1f8493727127f4ed
Also issue #3281400: Rotating a retained instance fragment leaks the fragment manager
And turn off fragment debug logging.
Change-Id: Ibdd7db82bb35618021bcba421ba92ced7cd691c2
This change improves animation by enabling hardware acceleration
and reducing the size of the blue glow.
Change-Id: Ie8b7668b9b1f1ae91211875c2fa11b305a317d64
In preparation for an upcoming change that will make UsbService into a real system service
Change-Id: Id85d624cfc6b10b49a08105cfaaacc667a492c12
Signed-off-by: Mike Lockwood <lockwood@android.com>
While any IME is showing, taps on the empty region in the
center of the status bar will inject a KEYCODE_SPACE (62)
KeyEvent. This gives a huge Fitts' Law boost to LatinIME's
spacebar, which is easy to miss when typing quickly.
This is sort of a hack; a better solution would be to
translate the tap vertically until it enters the IME's
window and then hand the motion event back to the IME
(thereby accommodating IMEs that have something other than a
spacebar in their bottom row).
Bug: 3114340
Change-Id: Iabbfb5ca0000101074932304bce44eb6f7dca85d
(This introduces a StatusBarManager disable flag to ask the
status bar to hide just the clock, which might be useful in
other situations, such as clock/dock apps.)
Bug: 3130393
Change-Id: Ia08627508518e2ed3713ffbf856e4ec42952b3a8
Legacy applications using FLAG_FULLSCREEN do so principally
to get as much screen real estate as possible; reducing
clutter is usually a secondary concern. The new UI style
takes care of the latter for the most part, and the former
is irrelevant because the xlarge system bar never goes away.
Lights out---and with it the disappearance of important
systemwide navigation controls---is probably *not* something
these apps are expecting! Consider a game: it might want
FLAG_FULLSCREEN on phone to take over your entire display,
but might also rely on menu (to pause the game or bring up
options) and home (to allow you to exit). Lights out makes
these tasks much harder on the user because those buttons
aren't visible anymore.
So, to mitigate this potentially confusing situation, we now
disable lights out for fullscreen legacy apps.
[Hack, er, cleverness alert: We use NEEDS_MENU_KEY as a
shorthand for "legacy app." This flag is set by
pre-Honeycomb apps by default, but even an app built against
the current API can request this flag; be forewarned that if
you do, you won't get lights out mode in this particular
system bar implementation when you use FLAG_FULLSCREEN.]
Change-Id: If90d8354114ba45f9485b935b87ee575a30b9f87
When calling startDrag(), the app can now supply an Object to be passed
along in every DragEvent that the app winds up receiving itself. This
object is *not* passed to any other applications; it's strictly app-
local. The purpose is to allow state tracking/management to be done
directly through the drag mechanism rather than requiring out-of-band
code.
An example of the utility here might be TextEdit widgets. A drag that
starts in one TextEdit but ends in a different one should be treated as
a copy/paste operation, where the originating TextEdit is not altered.
However, a drag that starts and ends in the *same* TextEdit is a 'move'
operation within that TextEdit; the text is removed from its original
position and inserted at the drop point. To support this easily, the
drag/drop code in TextEdit can now pass a pointer to the originating
view as the local state object. Then, the drop recipient could tell
whether the drag started within the same TextEdit without needing to
implement any other out-of-band state tracking.
This CL (and its accompanying CLs in a few other packages where the
startDrag() API is being used) adds the new local-state parameter to
the API, but does not actually change the behavior of any existing
clients.
Change-Id: Icba73b2ab4a650b7a94485a19633065b0ef9058c
