The PowerManager may call into the BatteryService while
holding its locks. We need to be careful that the BatteryService
doesn't call into other services, particularly the ActivityManager
while holding its own locks.
Bug: 7298218
Change-Id: Ibf8ab13224f204a9857825265e864f93583bce8e
Created a new flag that indicates that a window should be shown
to all users. For the flag to be valid the owner of the window
must have system permissions.
Also separated system window types into those that show to all
users (e.g. StatusBar, Keyguard, ....) and those that appear only
to the owning users (e.g. Drag, ANR, TOAST, ...). Those that appear
only to their owner can override their default behavior using
the new flag (e.g. LowBattery).
Fixes bug 7211965.
Change-Id: I1fdca25d57b7b523f0c7f8bceb819af656c388d4
While fixing this bug, I fixed a few other issues:
- Always call showAppropriateWidgetPage(), even when DPM enabled
- Always disable status view interaction, even when DPM enabled
Fixes bug 7294880
Change-Id: Ia8495555c1940f2b38f42389558f46fde6aab775
Fixed a race between the UiModeManagerService and PowerManagerService
both of which are trying to wake the device when docked / powered.
Bug: 7281240
Change-Id: Ia41fef48f17f2a2eb56549437d295f9a86c95af2
The last bit of undoing the earlier tangle around query results having
observers under the calling user's identity. We do *not* want to drop
calling identity in the call() processing; we want the table-based
permission checks at the point of the underlying db operations to be
performed against that identity.
Bug 7265610
Change-Id: Ie0c9331ebd0918262a0a32b5b03b876fc2a92ca3
If the panel was left open when the screen was turned off,
in some cases it might get stuck in an "open" state (the
panel's expanded height would be nonzero) although the
status bar window is in fact fully collapsed (due to
makeExpandedInvisible). The next time the user would go to
open the panel, things would be in an inconsistent state and
the panel wouldn't come down (on phones, the settings panel
would be attempted, but still nothing would happen).
This was easiest to reproduce on the keyguard (turn on
screen, pull down panel, turn off screen).
Bug: 7260868
Change-Id: Iec0000ba020e5a519eb5b4d42ac273b6689a18bd
Existing primary users were never being marked as complete,
causing things that relied on this (e.g. showing the quick settings panel)
to break.
Bug:7282088
Change-Id: I9c8622f3cd0fb99a44477946d3db22fa2cbbc6fc
The failures were caused by the implementation of doTextRunCursor
passing a too-small value for contextCount into the underlying
getTextRunAdvances call (it wasn't accounting for the start offset).
Thus, when getTextRunAdvances made a copy of the text for its cache key,
it was getting a partial copy.
This patch fixes the size so the cache key always has a full copy of the
text.
Change-Id: I57e3ac6de7aef0e1f1c7000dc3d653f9b0d623d2
Some security screens aren't currently calling userActivity(). As such,
they allow keyguard to timeout before the user has a chance to enter
the required information.
The fix uses a TextWatcher to look for changes in the input text
and call userActivity() appropriately.
bug 7291431
Change-Id: I6d7889cc01a4d6bdbefefc5af478e812c35b1a49
