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
- Pass to surface flinger whether we want animations or not.
- Don't use the animation when the screen goes off because of the prox sensor.
- Turn the screen-on animation back off
- Also, now the animation setting controls whether or not we do the animation.
Bug: 3097475
Bug: 3098508
Change-Id: I205d5564d6668b33a8dc1c40d8cc06c4aad305cf
Merge commit '9a12a3c8d4bb20042cf69e07d268e3a04ac71f96'
* commit '9a12a3c8d4bb20042cf69e07d268e3a04ac71f96':
Remove dead code, and make the animation a setting.
turn off the electron beam
Merge commit '14854820eac895a925791fb41ccd330447fd4f02'
* commit '14854820eac895a925791fb41ccd330447fd4f02':
Add a configuration option to turn on the screen when you unplug the device.
Merge commit '5be893a71aa72f54660496dd01cfad66adb86b8f'
* commit '5be893a71aa72f54660496dd01cfad66adb86b8f':
Don't throw when userActivity fails because of the permission check.
... to make sure that if you press the power button to turn off the
screen, that the prox sensor won't turn it back on.
Bug: 3011618
Change-Id: Id16c1d65417539d4592f485b1c3efb737540c3cd
We were flunking the enforcement of DEVICE_POWER since apps don't need that permission to use a wake
lock.
Bug: 3051596
Change-Id: I1910d8402adb3e9a4d8635de5d2a301f6286f216
Merge commit '198297b495d975cd4889f5136cd69368bd319eed'
* commit '198297b495d975cd4889f5136cd69368bd319eed':
Revert "Revert "Check for the DEVICE_POWER permission in userActivity.""
Merge commit '05e110506156a1b782232833b907afb428802b69'
* commit '05e110506156a1b782232833b907afb428802b69':
Revert "Check for the DEVICE_POWER permission in userActivity."
Merge commit 'f5bdeba197aba659e2dd3849a5bdfba8826c036d'
* commit 'f5bdeba197aba659e2dd3849a5bdfba8826c036d':
Check for the DEVICE_POWER permission in userActivity.
Merge commit 'abdd2c7f03651e95424133c2be948238c6dc7bf6'
* commit 'abdd2c7f03651e95424133c2be948238c6dc7bf6':
Fix NPE in PowerManagerService on boot, if some settings are corrupted.
Merge commit '227afd3a1b1a32891e5e20c79fd98b2ccf982426'
* commit '227afd3a1b1a32891e5e20c79fd98b2ccf982426':
Fix problem where power manager was calling battery stats with bad wl type.
This fixes a problem where applications could ask the location
manager to do very heavy-weight things (like... say... update
location every minute), which would get accounted against the
system instead of the application because ultimately it is the
system making the heavy calls (wake locks, etc).
To solve this, we introduce a new class WorkSource representing
the source of some work. Wake locks and Wifi locks allow you
to set the source to use (but only if you are system code and thus
can get the permission to do so), which is what will be reported
to the battery stats until the actual caller.
For the initial implementation, the location manager keeps track
of all clients requesting periodic updates, and tells its providers
about them as a WorkSource param when setting their min update time.
The network location provider uses this to set the source on the
wake and wifi locks it acquires, when doing work because of the
update period.
This should also be used elsewhere, such as in the GPS provider,
but this is a good start.
Change-Id: I2b6ffafad9e90ecf15d7c502e2db675fd52ae3cf
This change adds a second timeout to the SecuritySettings page
separate from the standard display timeout.
Change-Id: I41fe10e31688308f52695ad3ee30a4b0507112bd
Merge commit '797e688b3bebbf1f50a8ad08528740b064f79153' into gingerbread
* commit '797e688b3bebbf1f50a8ad08528740b064f79153':
Continue trying to make the turn off quickly after call feature work.
The previous implementation worked if the set timeout is short enough, which mine was. This one
carries the remaining amount of timeout override forward through all of the countdown steps.
Bug: 2844990
Change-Id: I040df22f9f9ddf98c355ac6845b7624e95f84f33
- Now track wake locks in battery history.
- Now track sensors in battery history.
- Some filtering of sensory data.
- Fixes to some data that wasn't cleared when resetting battery stats.
- Print amount discharged since last charge.
And the big part -- keep track of wake locks held per process,
and kill processes that hold wake locks too much while they are in
the background. This includes information in the battery stats
about the process being killed, which will be available to the
developer if the app is reported.
Change-Id: I97202e94d00aafe0526ba2db74a03212e7539c54
Merge commit '8c65ee2d509db7dcb50ce4530d52eb5bdca3f917' into gingerbread
* commit '8c65ee2d509db7dcb50ce4530d52eb5bdca3f917':
Add a method to let a properly permissioned app directly
manipulate the user activity timeout. We should come up
with a better API for this, but this is for a last minute
power manager hack to turn off the screen sooner after a
phone call ends.
Change-Id: I76422f952e3e894c90b3311e7d889899c79cbbaa
Removed old input dispatch code.
Refactored the policy callbacks.
Pushed a tiny bit of the power manager state down to native.
Fixed long press on MENU.
Made the virtual key detection and cancelation a bit more precise.
Change-Id: I5d8c1062f7ea0ab3b54c6fadb058c4d5f5a9e02e
