Keyboard and button brightness are always set to assign values
immediately but were being passed through the animation process
anyways. This interfered with the state of the screen brightness
animation. Intercept keyboard and button brightness directives and
implement them immediately.
Also use actual screen brightness and value to determine when we
are dimming or brightening. Previously we were using the sensor
values to determine whether the action called for was to brighten or
dim. This looks at the actual screen brightness level to make that
determination. If the two values get out of sync it is better to rely
on the screen value than the sensor value.
Fixes bug 6626681.
Change-Id: I82158f5188ffb739e01f818ba88e79f03a405c58
Done by setting the dimming period to Integer.MAX_VALUE. While it
doesn't technically disable dimming it will take 248 days to get to
any target value.
Fixes bug 6616423.
Change-Id: I5b753286b9d93664fbff79021be38adf4d8a007d
Use the first sensor value received after screen on to set the screen
brightness. Do this setting immediately rather than animate to the
target brightness.
Fixes bug 6612418.
Change-Id: I6c24c55e0bd35ef58a6494d3b5e449954241fd00
1. If a new brightness animation is started while an unrelated one is
ongoing complete the old animation immediately. Unrelated means that
the old and new animations apply to different devices (button,
keyboard, or screen).
2. Do not interpret turning off the keyboard or button lights as
turning off the screen in isScreenTurningOffLocked().
Fixes bug 6519847.
Change-Id: I53a20951036bcdb793daeff84a9ebeed44be01fc
Setting of mInitialAnimation member was assuming that currentValue
member would only be 0 at boot. It also gets set to 0 when the
sensor goes dark. This fix removes mInitialValue reliance on
currentValue.
Fixes bug 6444319.
Change-Id: I27069f1b44f1f727533d34bbecad2e5aeaa7aab8
Previous auto brightness policy was to only ratchet screen brightness
up and never return to dim levels until the device was turned off. This
caused the screen to be very bright in dim areas and reduced battery
life. This change allows the screen to dim down over the course of
a minute to the desired brightness level.
Fixes bug 6422464.
Change-Id: I5592c06a495650c6496ec2fc9846d7a10fac4b16
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
