- Add callback to inform SysUI when the screen has been unblocked
and turned on.
- Cleanup inconsistent messaging about device interactive/screen on
and off.
- Add callbacks to inform SysUI about screen states
- Implement a quick fade for the scrim after touch, wake, and unlock.
First, start with a black scrim on top of everything, and then fade
it out.
- Make sure we play the normal unlock animation when device is pulsing
- Override navigation bar animations for touch, wake and unlock: Fade
in the same manner as the scrim.
Bug: 22571198
Bug: 21855614
Change-Id: I8ff08d72cced1e0f03c78d71ff710d8a4f6b848c
All the necessary information (most importantly outsets) arrives in
addWindowToDisplay that is happening a few lines earlier.
Bug: 22073222
Change-Id: I483e98808877f32812c0e959cdfc14b4e0ca5e62
Basically this is a copy of Iabef96921dd554ce3768fb18619cefc
for InputMethodManagerService.
As described in JavaDoc of Intent#ACTION_SCREEN_OFF and
Intent#ACTION_SCREEN_ON, one can use those Intents to be
notified when the device becomes non-interactive and
interactive. IMMS has relied on them to enable and disable
InputConnection between the IME and the application so as not
to allow IMEs to update text when the user does not present.
This is actually our design goal as documented in JavaDoc of
InputMethodManager.
An IME can never interact with an InputConnection while
the screen is off. This is enforced by making all clients
inactive while the screen is off, and prevents bad IMEs from
driving the UI when the user can not be aware of its
behavior.
The goal of this CL is to improve the timeliness of above
mechianism by introducing a direct communication channel from
PowerManagerService to InputMethodManagerService via Notifier.
Actually this is what InputManager has been doing since
Iabef96921dd554ce3768fb18619cefc3230b5fb0.
Reasons behind this change are:
1. There are several bugreports that imply those Intents can
dispatch tens of seconds after it is enqueued. This is
indeed problematic because the user cannot type password
to unlock their devices until queued
Intent#ACTION_SCREEN_ON is dispatched. This CL addresses
such an issue without waiting for figuring out the root
cause of the delay.
2. Intent#ACTION_SCREEN_OFF and Intent#ACTION_SCREEN_ON are
sent as a ordered broadcast, which may not be suitable for
tasks that require a certain level of timeliness, and what
IMMS wants is to enable users to start typing immediately
after the system.
This CL was originally authored by Seigo Nonaka.
Bug: 22423200
Bug: 22555778
Change-Id: I747c37ff6dd8f233faef43f2b5713a4320e848eb
The status bar window was stuck in the READY_TO_SHOW state
because it was not policy visible, whereas the policy
was waiting for the window to become HAS_DRAWN.
Now BarController also updates states if the window
is READY_TO_SHOW, which in turn allows the window to
become visible and HAS_DRAWN.
Bug: 22072099
Change-Id: I1836c276723ee2205d7d5759be079f02aaa23e2e
TextView is now much smarter about the text it reports, limiting it
to what is visible (plus a bit more). Also add a facility for it to
report where the lines of text are, both as offsets in the text string
and their baselines on screen.
Part of fixing issue #22328792: Fix scalability issues in AssistStructure
Change-Id: Idddb8c3a3331355f381e2d4af06d520fe7c7ce8e
bug:22234438
Updating the displaylist is invalid since this debug method isn't
called on the UI thread, and it defeats the purpose of seeing what
the hierarchy is currently rendering.
Change-Id: I10c5cc6dbae8d304559dfc6e863b0ede158d554f
This is a manual reland of I3680256d41793f62def42fda00e26db1dcc9,
which was certainly merged into lmp-mr1-dev then auto-merged into
master but silently lost there for unknown reasons when
I8c42a1e6091b0fe1253e90265ac248087e was auto-merged into master.
Changes in WindowAnimator.java was already covered by
I2933eaf0ab55fe31cb382c46c411033e33a756e0 so this CL does not
include that change.
Bug: 18021493
Bug: 22158649
Change-Id: Ib1bf9f5bef44d0400230afc32231f7d1f3a1c98b
This bug caused views which used to be quick-rejected to continue to not
be drawn because the parent's DisplayList no longer contained them. The
fix is to notice when offsetting a view puts it back on screen and invalidates
the parent appropriately.
Issue #21413554 offsetTopAndBottom requires invalidating parent when view becomes visible again
Change-Id: I0f5d2cc48e3da912a41635712d9c37fb30e70c86
Bug: 21750734
Doesn't fix the underlying issue that we were unable to
get a buffer but as this is non-critical be more defensive
about failures.
Change-Id: I7f2faaa35b064e3d0da0a13dba9aae3c226b9acc
Outsets aren't dynamic so they are a great candidate for a hint when the
window is added through the window manager. Thanks to this during first
view hierarchy measure or wallpaper window layout they are immediately
available and don't require multiple measure/layout passes.
Bug: 21593814
Change-Id: I573c15ffbbe4fcd8a6ed9c5e4fcd6cfbbcd7434f
Caused by ActionMenuItem's SubUiVisibilityListener
not being nulled when it is replaced via setActionProvider().
BUG: 22189734
Change-Id: Id4deaa05cd5554ca7bdf969a592e4812e39dcb75
...into account when calculating the position information
Actually what we need here is the full transformation matrix, if it
is available. And that means actually computing the location of
views on the screen requires doing this all through transformations,
so the AssistVisualizer has been changed to do this (while still
also keeping the old mechanism for comparison to verify that things
are working correctly).
Also added new properties for elevation and alpha.
And optimized the parcelling of AssistStructure to not write things
that aren't needed; this reduces the parcelled size by about half.
Change-Id: I50b0dd2e6599c74701a5d188617a3eff64b07d03
Cherry-pick from master
This change adds four new stem keycodes for Android Wear. These
keycodes are intended to represent the various hardware buttons
around the watch. There is one primary stem key that will be used
for power/settings and three generic stem keys that will be
customizable.
BUG: 21903503
Change-Id: I867cf79554c72d42c8acbb3ff8b1678e482d4fe2
Crash immediately so that we can track down the cause. If we let it
through, we'll hit an ISE later in dispatchVsync() and never know why.
Bug: 21948478
Change-Id: I84edf93cdf09d755419e18a7606b7b6cbd059956
"Default" packed colors are indicated by zero alpha and non-zero
red/blue. The cached alpha value used by Settings is stored in green.
Bug: 21602597
Change-Id: I1465210fda854ee979aa3a6b398ae60b41d10711
