-> Also fixing a typo in AppWidgetProvider clone() -- this was the cause of
the "couldn't load widget". It wasn't getting expressed before for various
reasons.
Change-Id: Ib7114565a414d66facd8b4baeb97d5a71e96b5e9
-> If the challenge is showing and the page is swiped, instead of immediately
sliding down the security and expanding the small widget, we instead
quickly fade out the security and keep the widget+frame small until
the page settles and fades out.
Change-Id: I0f376dcd863744b977a1c5ccc7a46a5c6fdb891d
The gnarly stuff where we keep track of the old input method
window as if it was still there was sitting around leaving things
in a stuck state. Now we clear this out at key points in the
window manager (freezing screen, user change), and the input
method manager service is less aggressive about asking the window
manager to do it.
Also fixed a problem that was causing flickers during some
wallpaper transitions -- when we are animating two things on
top of the wallpaper and one of them disappears, we need to
make sure the wallpaper target points to whatever the current
target should be (if any), not left pointing to the old target
that has gone away.
Change-Id: I2fb9600f569a5bd5e3528aaf24cde9340af56cb0
Throw early when structure is unstable, which allows the normal
recoverFromWtf() path to recover automatically.
Bug: 7440485
Change-Id: Ic150d17daac4de7c9ff3489025403a9b485b4620
...lockscreen sometimes and remains black / blank
The problem was that we were using the animation-side wallpaper state
in cases where it was not updated yet.
The mWallpaperTarget variable is propagated over to the animation
side when the main window manager state updates. On the animation
side, this is used by hideWallpapersLocked() to determine if the
current wallpaper should be hidden.
The problem is that various paths to hideWallpapersLocked() can
come from the layout side of the window manager instead of the
animation side. This causes the problem here because in this case
the wallpaper state may not have yet been propagated to the
animation side, so it could incorrectly decide to hide the wallpaper
because it thinks there is not a target when in fact a target is
set in the layout side. This won't get fixed until some time way
later that the layout side decides that a new window is being shown
that may need to have the wallpaper shown.
The fix here is pretty gross, but as safe as possible -- the
hideWallpapersLocked() function now uses either the animation or
layout wallpaper state depending on where the call to it is coming
from.
Change-Id: I9250bfeae6e11c1761760bcc696fdb33fb5c8a5f
- space between digit and mnemonics
- better center the (left-aligned) text in its container
- nudge the enter arrow a little to the left in its
container
- add missing contentDescriptions for SIMPIN/PUK
Bug: 7427380
Change-Id: I0f5d9d1554a476c00591981028733ee6924bb729
If applicable, also announces that the user needs a headset when
displaying the PIN pad layout. Also fixes accessibility focus "falling
through" to the next Z-ordered view.
Bug: 7436382
Change-Id: Ic1db5320b2e47ff181c5902e9f7980fe3fe6756b
