This refactoring sets the stage for a follow-on change that
will make use additional functions of the power HAL.
Moved functionality from android.os.Power into PowerManagerService.
None of these functions make sense being called outside of the
system server. Moving them to the PowerManagerService makes it
easier to ensure that the power HAL is initialized exactly once.
Similarly, moved ShutdownThread out of the policy package and into
the services package where it can tie into the PowerManagerService
as needed.
Bug: 6435382
Change-Id: I958241bb124fb4410d96f5d5eb00ed68d60b29e5
The window manager policy made some incorrect assumptions about the
meaning of the Configuration.keyboard field. We need to be more
careful about distinguishing between built-in and external keyboards.
Most of this change is to move the determination of the parts of
the Configuration related to input devices into the WindowManagerService
leveraging new features of the InputManagerService to good effect.
Then we plumb through the flag that indicates whether a device
is internal or external so that we can be more particular about
how the lid switch effects changes to the Configuration.
Bug: 6424373
Change-Id: I36a1c22ade35e578955465a25940a33f227b9763
Added a config option to allow the lid switch to turn off the
screen. This is a closer match to what a lid switch should be
doing.
Removed an old feature to bypass keyguard when keyboard is visible
because the way it was plumbed in made bad assumptions about
the meaning of the lid switch. Also, the last product we shipped
that had a physical keyboard turned this config option off.
So away it goes. We can bring it back someday if we really want it.
It's questionable how useful the feature is anyhow, since it only
works when the keyguard is unsecure and when the lid switch is
unlikely to be jostled in the user's pocket.
Fixed a bug where we would tell the power manager that the keyboard
was visible even if the lid switch did not control the keyboard.
This used to cause the power manager to try to set the keyboard
brightness, which doesn't work.
Bug: 6377115
Bug: 6406726
Change-Id: Ic84b71d09563d51c92cd1cf132fa8bdee6509103
Changed the SensorManager class so that it only contains API-related
bits including what's needed to support legacy sensors. Mostly just
moved stuff around. Making the class abstract is safe because
it does not have a visible constructor in the API.
One minor change is that the cache of sensor type to sensor lists
is now per instance of SensorManager instead of being static.
We can fix this if desired.
Another small change is that we bail out early from registerListener
if the listener has already been registered for the particular
sensor. This happened for both legacy and standard listeners.
The problem is that the ListenerDelegate maintains two lists of
sensors, one is a Map and the other is a List. Adding a sensor
twice causes one entry to be added to the Map and two entries to be
added to the List, but when the sensor is removed the next time, only
one entry is removed from the List, leaving it in an inconsistent
state.
Removed Sensor.getLegacyType() since the value it provides is only
needed in LegacyListener and we don't really save any significant
computation by caching it. Removing the field makes support for
legacy sensors a little more self-contained.
Bug: 6339552
Change-Id: I50d41ac97cf535924f2bfa2026d28547a4d00286
Rather than normal Activities (which have a host of problems
when used for this purpose), screen savers are now a
special kind of Service that can add views to its own
special window (TYPE_DREAM, in the SCREENSAVER layer).
Dreams are now launched by the power manager; whenever it is
about to turn the screen off, it asks the window manager if
it wants to run a screen saver instead. (http://b/5677408)
Also, the new config_enableDreams bool allows the entire
feature to be switched on or off in one place. It is
currently switched off (and the APIs are all @hidden).
Change-Id: Idfe9d430568471d15f4b463cb70586a899a331f7
An occasional call sequence through updateLightsLocked ended up storing
the old screen-off reason rather than the current screen-off reason.
This caused the Keyguard screen to be bypassed when turning back on. By
saving the power-off reason in mScreenOffReason prior to calling
updateLightsLocked we eliminate this problem.
The offending calling sequence was:
PowerManagerService.setPowerState(..., reason) => updateLightsLocked
=> animateTo => screenOffFinishedAminatingLocked(mScreenOffReason)
=> sendNotificationLocked.
Change-Id: I8ee0b3226f94af7ff7e7b7b0bf54e47fd0c03631
This fixes a bug where the code asked to change the keyboard brightness
on a device that doesn't support it. Instead of animating the keyboard
brightness, it ended up animating the display brightness and invoking
the power off animation as a result. The fix is to ignore keyboard
brightness because we don't have any devices that currently support it.
Change-Id: I672d89f92f991812ea676f19c40058b2d3008656
This fixes a crash on tablets introduced by Change Ifad76fb2. It was caused
by calling nativeStartSurfaceFlingerAnimation() on devices that previously
didn't call it and apparently don't support some feature it uses.
Change-Id: Ia4c04e7e611f45cde0fbeb861aec3435d1719552
This fixes a bug where the device could see a priority inversion when
updating display brightness. The problem occurs because the code that
manages screen brightness holds the master lock while waiting for the
native method to complete. On some devices, each call can amount to
tens to hundreds of ms, which meant clients using PowerManager APIs
could block for the duration of the call. In some cases, the animation
could block for many seconds because the unfairness of Java locks.
The solution is to handle all brightness updates in a separate thread that
does not hold the master lock while calling native methods.
This also makes the animation more consistent by animating by actual
wall clock time rather than depending on the round-trip from the driver.
Change-Id: Ifad76fb2fb77e7b2a72dd9150440d87e22581b40
Use PowerHAL to set system awake/suspend state.
Change-Id: If58a6f548564ea141b68f304455997d9ff04eace
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Enabled by setting system property ro.config.headless to 1
This will allow the framework to run without starting activities,
system UI and the keyguard.
Framework can still run services, content providers and broadcast receivers.
Signed-off-by: Mike Lockwood <lockwood@android.com>
Conflicts:
policy/src/com/android/internal/policy/impl/PhoneWindowManager.java
services/java/com/android/server/PowerManagerService.java
services/java/com/android/server/am/ActivityManagerService.java
Turning animations back on exposed this. The problem is that when the
screen brightness changes, it initiates a brightness animation. When
we force the screen to black as we wait for it to be ready to display,
it sees that an animation is running so stops it and thinks this means
it should now turn the display off.
To fix this, don't modify the screen brightness while we are waiting
to show the screen. This is good anyway because the whole point is to
avoid showing the screen until ready, and modifying the brightness at
that point would turn it on prematurely.
Change-Id: I84b296f8ca5705c2d237ea7741cdeb95c5521df9
Introduce a new concept of "B" services. All running services are
classified as either A or B. B services are later in the LRU list.
Their oom_adj is after the home app. This allows us to better pick
services to kill based on how long they have running, and should
reduce the amount that we end up killing the home app.
This temporarly turns on a debug log when the oom_adj of a process
is changed. Sorry, I know it is noisy. This is needed to try to
track down why some processes are being killed.
Also add a flag to the SyncManager's service binding to allow the
syncing process to be more aggressively killed if it has done UI.
This is to address cases we have seen where sync is causing an 80MB
gmail process to be kept around, preventing other process from running.
Now what will happen is that the syncing process will aggressively be
killed by the system, and can then be restarted in a much lighter-weight
state.
Do a little tweak in the power manager to allow us to still do smooth
brightness changes even when the fancy TV off animation is in use.
And get rid of a debug log in the window manager that was accidentally
left in.
Change-Id: I64a8eeaaa1f096bab29c665fbff804c7f1d029e2
Now the screen brightness will readjust to ambient lighting when toggling
auto-brightness on and off in Settings or the Power Widget.
Bug: 5486091
Change-Id: Ic98939fe1c59cb8def0f84266e48ca00329d6b30
Signed-off-by: Mike Lockwood <lockwood@android.com>
The correct behavior for the light sensor is to immediately report a value
when it is enabled, so this change should not be necessary.
Bug: 5426212
This reverts commit 5dca30affc517879315b3a928c78756cbc9cf689.
Be more explicit about initialization -- power manager never sends
screen update when first initializing, phone window manager retreives
current screen state and applies that itself when initializing.
Change-Id: I8294ed36d700e186c1637754df8c8183721c15dd
The keyguard/window manager recently got a facility to report when it is
okay to turn the screen on, when it knows the lock screen is displayed.
The power manager was using this wrong, just using it to drive the
flags given to the input system. Duh.
This change now uses the information to determine when to turn the screen
brightness up from 0. For an OLED screen, this is the time when the
user can actually see anything on the screen.
For LCD screens this may not be optimal, because the LCD may start running
before its backlight is turned on, so if you look carefully you may see
stuff before it is lit up. On the other hand, it is good to turn on the
display as early as possible (before waiting for the keyguard) because it
can take a little bit of time to get that and the touch screen going. By
only waiting on the display brightness, we allow turning on the screen
in the kernel to proceed in parallel with ensuring the keyguard is displayed.
Change-Id: I7ee4ce19fd4efd5b51872b855af6263f53cd6c30
Rework how we decide when it is okay to turn on the screen by having
the policy call back to the power manager when it knows the lock screen
has been drawn.
Change-Id: Ie8f3f72111dcf7f168723e6dce24e0343b4afe5d
When in a phone call, we keep the screen off while the prox sensor returns positive
and the device is oriented in a vertical position.
If the call is terminated on the other end, we keep the screen off
until the proximity sensor returns negative.
We do this to avoid having the screen turn on as soon as the other end
hangs up while the phone is still next to your head.
However, we allow the power button to wake the screen while waiting for the proximity
sensor to go negative as a precaution in case there is a problem with the proximity sensor.
But unfortunately that logic broke due to a change in the call path used to turn the screen
on from the power button (it previously called userActivity, now it uses a wake lock).
This change adds code to handle the new code path so the power button will wake the screen
while we are waiting for the proximity sensor to go negative after a call.
Bug: 5184524
Change-Id: I7d1e0f0d1f78680c552a05d68a392647823250ab
Signed-off-by: Mike Lockwood <lockwood@android.com>
...(when turning display on after recently turning it off)
Also clean up when we decide to turn the screen on to improve that
transition. There are still problems here with turning it on
before the wallpaper gets dispayed.
Change-Id: I2bc56c12e5ad75a1ce5a0546f43a845bf0823e66
Two issues:
1. First, due to an inverted conditional in the input dispatcher, we were
reporting touches as long touches and vice-versa to the power manager.
2. Power manager user activity cheek event suppression also suppresses touch
events (but not long touch or up events). As a result, if cheek event
suppression was enabled, touches would not poke the user activity timer.
However due to the above logic inversion, this actually affected long
touches. Net result, if cheek suppression was enabled in the power manager
and you held your thumb on the screen long enough, the phone would
go to sleep!
Cheek event suppression is commonly turned on when making a phone call.
Interestingly, it does not seem to get turned off afterward...
This change fixes the logic inversion and exempts touches from the cheek
suppression. The reason we do the latter is because the old behavior
was actually harmful in other ways too: a touch down would be suppressed
but not a long touch or the touch up. This would cause bizarre behavior
if you touched the screen while it was dimmed. Instead of brightening
immediately, it would brighten either when you lifted your finger or
300ms later, whichever came first.
Bug: 3154895
Change-Id: Ied9ccec6718fbe86506322ff47a4e3eb58f81834
Avoid resetting the debounce timer for automatic brightness if a new light event
is received that agrees with the direction of change of the previous event(s).
Change-Id: Id4d71f6db46ded46b24eb44cb8de9b2cfedb3f06
Signed-off-by: Mike Lockwood <lockwood@google.com>
These are the logs from when I just reproduced it here. This means that we got an event after the
screen turned off. So isScreenTurningOffLocked() is working, but we need to also check that we're
not off. This bug is happening because lightSensorChangedLocked is calling
mButtonLight.setBrightness() directly instead of going through updateLightsLocked, which is where
I added that check to not turn the buttons on of the screen is off.
D/PowerManagerService( 1243): onSensorChanged: light value: 1280
I/power ( 1243): *** set_screen_state 0
D/PowerManagerService( 1243): enableLightSensor false
D/PowerManagerService( 1243): onSensorChanged: light value: 320
D/PowerManagerService( 1243): lightSensorChangedLocked 320
D/PowerManagerService( 1243): lcdValue 55
D/PowerManagerService( 1243): buttonValue 255
D/PowerManagerService( 1243): keyboardValue 0
D/SurfaceFlinger( 1243): About to give-up screen, flinger = 0x8dcf! 0
Bug: 3117801
Change-Id: I722d66cafba71b183cc987b7383d4ad7e171ba82
Merge commit 'b34fe2f0258eb1ed512b682206b7fe65116f1dbd'
* commit 'b34fe2f0258eb1ed512b682206b7fe65116f1dbd':
Make sure that when the screen is off, we don't try to turn the buttons on too.
Merge commit '5747eebf6eb5ea91480dc576c45c752685383e37'
* commit '5747eebf6eb5ea91480dc576c45c752685383e37':
Pressing the power button quickly needs to turn the screen on and off correctly.
This does the animation with the power manager lock held, which isn't great, but is safe.
Bug: 3102208
Change-Id: Ib0af3fab1cf6ba47053c10ae8b701376d63802ff
