Age | Commit message (Collapse) | Author |
|
Change-Id: I5f5a6435e64354b7d6535e8e9a63934ba7a3f448
|
|
immediately." into jb-dev
* commit 'ae3e5bc93f1077615b4ec8f6fbd06509241d25de':
More paths for turning on screen immediately.
|
|
* commit '89f5a4624bfa487cb5fb192d9c3c9b30937b3f26':
More paths for turning on screen immediately.
|
|
|
|
This fix forces the path through the updateLightsLocked method to turn
the screen on immediately if mWaitingForFirstLightSensor is true. Also
do not clear mWaitingForFirstLightSensor if mPreparingForScreenOn
is true. Wait until it turns false.
Fixes bug 6612418.
Change-Id: I03407e748cce4906a73de1f15df1654649b133c4
|
|
work even Stay awake..." into jb-dev
* commit '608601924651531210ad3c6179d02c471f42dddf':
Fix issue #6664140: Time to lock should work even Stay awake...
|
|
awake..." into jb-dev
* commit 'd8bbf96a84cba7c31fa1535fe2467520f2aa0198':
Fix issue #6664140: Time to lock should work even Stay awake...
|
|
...in Developer options is on
Don't respect stay awake while on as long as a time to lock limit
is being enforced. When we start enforcing one, make sure the
setting is off (since we won't be respecting it anyway).
Bug: 6664140
Change-Id: Id07cb528afa0c64c7766341841c51771f507121d
|
|
foreground priority" into jb-dev
* commit '5eed873f1076b685d3a8538894a49f29f85d1189':
Run the screen on/off broadcasts at foreground priority
|
|
into jb-dev
* commit '7661bc6c5afef4cca8ccee2f859906f8fb64087b':
Run the screen on/off broadcasts at foreground priority
|
|
Bug 6643559
Change-Id: I392f11dabea518238d0f4336c3663bf5c7d46146
|
|
* commit 'a8e46828bf463cf542885d7726310abeac915e0a':
Fix dumpPowerState method
|
|
* commit 'c99e6ee202ba9d895c96f034643fd39a035ea7f2':
Fix dumpPowerState method
|
|
brightness." into jb-dev
* commit '1189f855e680eb05f60d849372a7049cbf9a305e':
Do not animate keyboard and button brightness.
|
|
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
|
|
* commit 'fd62576f06c05d6aab687892b9fcccfed3899021':
Disable automatic screen dimming.
|
|
|
|
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
|
|
power on." into jb-dev
* commit '55ab60cd7fe97d95f997d5f0761a5e571a88aa14':
Set screen brightness to match sensor at power on.
|
|
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
|
|
|
|
dumpPowerState method shows the current power manger service state but,
BUTTON_BRIGHT_BIT is omitted.
Add a routine of checking BUTTON_BRIGHT_BIT
Signed-off-by: jaiyoung.park <jaiyoung.park@lge.com>
Change-Id: I00484fb384963bafdc58ce89b3251a1f5585d992
|
|
|
|
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
|
|
Change-Id: Ief16f2b429f67cfb50877d24281401d7d4fcc4db
|
|
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
|
|
Not yet ready for release.
Change-Id: I75bc87f35af47c6baac1f26953d8bf3e38062c92
|
|
Bug: 6382031
Change-Id: I87b0887ce867a79758bcd24e2202280270faaf8c
|
|
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
|
|
Bug: 6313695
Change-Id: Ib12b9102df01603df135cef03fd2a2f6e3634dd1
|
|
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
|
|
Change-Id: I8aa574b38a4d901fce91b6d7771207949f9c8044
Signed-off-by: Dima Zavin <dima@android.com>
|
|
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
|
|
brightness"
|
|
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>
|
|
Signed-off-by: Mike Lockwood <lockwood@android.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
|
|
Change-Id: Icfec22be99d8c79e9ff5720b80fb9dacbba36134
|
|
didn\'t turn the screen on in call" into ics-mr1
* commit 'e2d76314cdd64cc69c791af0ee2fd2bbcc0425ba':
Fix issue #5642121: Proximity sensor didn't turn the screen on in call
|
|
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
|
|
~15Hz) for ALS purposes." into ics-mr1
* commit 'a508f056d0b5a439b9436604824739049fd25be6':
decrease the light-sensor rate to 1Hz (from ~15Hz) for ALS purposes.
|
|
the intent here is to save power.
Change-Id: I6cc1cae865cc46551afcfcec9ca03faaa5b6936f
|
|
* commit 'e02c88af7935c72fb90a478375e61e4a94465587':
Work on process management.
|