Under certain circumstances, the power manager might continue to
hold the display wakelock long after the display had been turned
off due to the mDisplayReady flag having an incorrect value.
1. An inverted conditional caused DisplayPowerState to incorrectly
signal the screen on ready state.
2. The DisplayPowerController failed to clear the block screen on
flag in the case where the screen was turned off before it became
unblocked from turning on. This could happen when the display was
rapidly turned on-off-on-off.
Bug: 13248135
Change-Id: I8faa3034695c83c8cd35613d81acccf40d22128d
The window manager and view hierarchy currently disable all drawing
when PowerManager.isScreenOn() returns false so no drawing occurs
while dozing. This will be fixed in a future patch to take the
display blanking state into account correctly.
This patch is a workaround to unblock development in the meantime.
Bug: 13133142
Change-Id: I2dc0b422c77285e657d73adca2606aa68264d987
This fixes the logic on the death handlers for notification listeners,
and doesn't unbind from the listener services so that the system will
bring them back up again.
Bug: 12587702
Change-Id: I44ce250e0e1c2583836dc823d9a333dabec51df9
The power manager sends SCREEN_ON and SCREEN_OFF broadcasts
purely based on the current wakefulness state. In particular,
when the system is awake, we consider the screen to be on even
if the screen may actually be off due to the proximity sensor
or some other condition. Likewise when the system is dozing
or asleep, we consider the screen to be off although technically
it may still be on and dozing.
This behavior is maintained for compatibility with applications
that interpret screen on / off as an indicator of user presence.
As it happened, the value of PowerManager.isScreenOn() did not
always match the state indicated by the broadcasts under certain
situations. Instead, it was based on the desired screen state.
These states used to be closely correlated but the addition
of doze mode causes them to diverge in meaning.
One consequence is that wake events from input devices might not
always wake the device from sleep unless the display's power
state was actually DOZING or OFF even if the power manager's
wakefulness was already DOZING or ASLEEP. This is now fixed.
Change-Id: Ie819c6d2c5a9ffaaf3101c5dee93ff72e9bc9f30
When the ActivityView is part of the home activity special checks
must be made. Things like don't move the home stack to the back
when the ActivityView activity is resumed.
Fixes bug 13119389.
Change-Id: I3a6040c9824dfd4b8ee97d58d131b14a519b470a
A task is scheduled for deletion after the final activity has
been removed and has animated away. But if another activity is then
added to the task the deletion flag must be reset.
Also added improved debugging.
Fixes bug 12987986.
Change-Id: I207ea6e9592a9e036d67aa5d1465b4acc5bdd120
Using the alpha value to trigger a resizing of the DimLayer was a
Bad Idea. The alpha value should reflect the true alpha value and
not be used to trick the code. Actually changing the size and
position is a Better Idea.
Fixes bug 13101776.
Change-Id: I11c16b8276919ea85960fe87bb17c0956ce8a3b1
When a doze component has been specified in a config.xml resource
overlay, the power manager will try to start a preconfigured dream
whenever it would have otherwise gone to sleep and turned the
screen off. The dream should render whatever it intends to show
then call startDozing() to tell the power manager to put the display
into a low power "doze" state and allow the application processor
to be suspended. The dream may wake up periodically using the
alarm manager or other features to update the contents of the display.
Added several new config.xml resources related to dreams and dozing.
In particular for dozing there are two new resources that pertain to
decoupling auto-suspend mode and interactive mode from the display
state. This is a requirement to enable the application processor
and other components to be suspended while dozing. Most devices
do not support these features today.
Consolidated the power manager's NAPPING and DREAMING states into one
to simplify the logic. The NAPPING state was mostly superfluous
and simply indicated that the power manager should attempt to start
a new dream. This state is now tracked in the mSandmanSummoned field.
Added a new DOZING state which is analoguous to DREAMING. The normal
state transition is now: AWAKE -> DREAMING -> DOZING -> ASLEEP.
The PowerManager.goToSleep() method now enters the DOZING state instead
of immediately going to sleep.
While in the doze state, the screen remains on. However, we actually
tell the rest of the system that the screen is off. This is somewhat
unfortunate but much of the system makes inappropriate assumptions
about what it means for the screen to be on or off. In particular,
screen on is usually taken to indicate an interactive state where
the user is present but that's not at all true for dozing (and is
only sometimes true while dreaming). We will probably need to add
some more precise externally visible states at some point.
The DozeHardware interface encapsulates a generic microcontroller
interface to allow a doze dream for off-loading rendering or other
functions while dozing. If the device possesses an MCU HAL for dozing
then it is exposed to the DreamService here.
Removed a number of catch blocks in DreamService that caught Throwable
and attempted to cause the dream to finish itself. We actually just
want to let the process crash. Cleanup will happen automatically if
needed. Catching these exceptions results in mysterious undefined
behavior and broken dreams.
Bug: 12494706
Change-Id: Ie78336b37dde7250d1ce65b3d367879e3bfb2b8b
