1. When magnifier, if a dialog that popped up is wider than the scree we pan to its upper
left corner. We now show the upper right corner if the locale direction is RTL.
2. Keyguard dialogs are not centered since they are used as a sign to recompute the
magnified area but an unnecessary else statement prevents such dialogs from being
properly show via a pan.
bug:7374331
Change-Id: I285e46b822a29f0082c502cb642f9da32dabfe6a
Status bar displayed on all devices.
Update logic for displaying nav bar to whether or not
device has soft button.
Update navigation buttons to new look.
Remove battery and signal from navigation bar.
(cherry picked from commit 891b703f7b1e0e396d16477cc66a286da7161b49)
Change-Id: Id7cc9ad4255d2c4d2e6461a565dfe2cc17e12e75
Typo in ImageWallpaper made a dimension check incorrect.
Issue#7373200 pause when toggling between All Apps and Home screen; Home button stays illuminated for a long time
Change-Id: I82763ac8c9ed564eba904f552975ab20c8aef932
This commit is the result of a comprehensive permissions review for
MR1 release. It addresses a number of deviations from spec and from
MR0's behavior, bringing MR1 into sync with both.
It also cleans up the concept of "location resolution permission",
representing it internally as an enumerated access level to reduce
reliance on cumbersome string manipulation. There's a function to
convert the enum int into a permission string where needed, too.
Additionally, this confines caller-identity-sensitive calls to the
hopefully-obviously-named "getCallerAllowedResolutionLevel()". This
should make it much easier to prove correctness with respect to
accidentally calling functions that depend upon the caller's identity
after identity has already been shed by Binder.clearCallingIdentity().
Change-Id: I446169aee8fb2fde26ac6d04b479b40253782acb
This allows services watching for USER_REMOVED to fetch the serialNumber of a dying user.
Also fix an AIOOBE when building the userId array, typically on cleanup.
Bug: 7368826
Change-Id: I24e52278af8353b5744372127da4bf4fafc89baa
If the user has requested that dreams start when docked and a user
activity timeout occurs, then start dreaming assuming all of the
other usual conditions are appropriate for dreaming (the device is
powered, etc.).
Previously dreams only started when the device was initial docked
but not if the device fell asleep while remaining docked.
Bug: 7281240
Change-Id: I72c3f854fd1ae8e6615f4fa6e4c4ecd8de37c84b
Status bar displayed on all devices.
Update logic for displaying nav bar to whether or not
device has soft button.
Update navigation buttons to new look.
Remove battery and signal from navigation bar.
Change-Id: I8241d71269a17126218a3062ba727e379a8e6c25
When maybeCreateKeyguardLocked was called from methods other than
show(), the requestFocus() call on the new KeyguardHostView was
never made.
At boot time the screen on notification was not propagated to
KeyguardViewManager because the showListener callback was null.
This passes on the notification but does not make the callback
if it is null.
Bug: 7299119 fixed.
Change-Id: Iaf058954473dc63fe4864ab1f435db4463b1110e
Instead of explicitly scanning OWNER accounts, move to using the
"user starting" call path for consistency.
Bug: 7358086
Change-Id: Ied3289a074aafa48259d828db1d68804912589b3
An error in the logic meant that some valid invalidations weren't getting through,
causing Launcher (for one) to get stuck sometimes.
Change-Id: I180622623b19770cd61034a5bd7991a5e2fd0a64
