As part of the power manager rewrite in JB MR1, we removed the ability
for the phone to suspend with positive proximity because it was not
clear that the proximity sensor was always correctly registered as
a wake-up source. The sensor service itself does not contain any
code to manage wake-ups. Therefore proximity sensor based wake-up
relies on the sensor driver acquiring a timed wake lock when the
sensor reports a negative result. This behavior is not very well
defined in the sensor HAL so there is a chance that it will not
work reliably on all devices.
This change adds a new config.xml resource to specify whether the
device should be allowed to suspend when the screen is off due to
positive proximity. Devices that support this feature should set
the "config_suspendWhenScreenOffDueToProximity" resource to "true" in
their resource overlays. The feature is disabled by default.
Bug: 9760828
Change-Id: Ic65ab7df0357271b133e2e44f5e35e7756e1e9e0
This is a regression in the new power manager. Apparently
some apps try to use ON_AFTER_RELEASE with partial wake locks
which doesn't make sense. Ignore the flag just like we used to
prior to JB MR1.
Bug: 10336375
Change-Id: Ib307eb60201612ba9bb03dc4da3365aba0b4848d
It turns out that on some devices the sensor event timestamp
may be non-monotonic. This may cause the detector to hold
a wakelock indefinitely if the time jumps backwards. These
timestamps are not well tested in general so there may be
other artifacts as well. Use elapsed realtime instead.
Bug: 9926451
Change-Id: Idb0b316e22b23aac86837bd25b953daf49f9b758
- Deprecates SurfaceTexture.OutOfResourcesException, it wasn't used
- Make all JNI code throw only Surface.OutOfResourcesException
- Get rid of redundant SurfaceControl.OutOfResourcesException
Bug: 10566539
Change-Id: I58126260771b9ccff6a69c672ce7719b9f98138d
We now keep track of all of the active start operations per
non-system process, so they can be cleaned up if the process
goes away.
Change-Id: I9d05f1e0281c47dbe1213de014f0491f1359685c
The display wake lock and other internal state could become
out of sync if we happened to execute the power manager's update
function concurrently due to the missing lock.
This bug can be trigged due to display state changes or proximity
sensor updated. Although it would be extremely rare, we have
some evidence of this happening on at least a few devices resulting
in rapid power drain with the screen off or a crash.
Bug: 9880044
Change-Id: I3c674ce429621a50cbb36c3a01883d5f388205b2
We now keep track of all the threads that are stopped, and
print stacks for all of them. Also more threads are now adding
themselves to the watchdog.
Unfortunately the stack we get from threads is far less useful
than the stacks from the ANR report, because these don't include
any information about the lock the thread is blocked on and what
thread is holding that lock. For example, here is a test of the
log output from causing a hang in the system process:
W/Watchdog( 5205): *** WATCHDOG KILLING SYSTEM PROCESS: com.android.server.am.ActivityManagerService, main thread
W/Watchdog( 5205): foreground thread stack trace:
W/Watchdog( 5205): at com.android.server.am.ActivityManagerService.monitor(ActivityManagerService.java:14333)
W/Watchdog( 5205): at com.android.server.Watchdog$HandlerChecker.run(Watchdog.java:142)
W/Watchdog( 5205): at android.os.Handler.handleCallback(Handler.java:730)
W/Watchdog( 5205): at android.os.Handler.dispatchMessage(Handler.java:92)
W/Watchdog( 5205): at android.os.Looper.loop(Looper.java:137)
W/Watchdog( 5205): at android.os.HandlerThread.run(HandlerThread.java:61)
W/Watchdog( 5205): main thread stack trace:
W/Watchdog( 5205): at com.android.server.am.ActivityManagerService.broadcastIntent(ActivityManagerService.java:12252)
W/Watchdog( 5205): at android.app.ContextImpl.sendBroadcastAsUser(ContextImpl.java:1158)
W/Watchdog( 5205): at com.android.server.DropBoxManagerService$3.handleMessage(DropBoxManagerService.java:161)
W/Watchdog( 5205): at android.os.Handler.dispatchMessage(Handler.java:99)
W/Watchdog( 5205): at android.os.Looper.loop(Looper.java:137)
W/Watchdog( 5205): at com.android.server.ServerThread.initAndLoop(SystemServer.java:1050)
W/Watchdog( 5205): at com.android.server.SystemServer.init2(SystemServer.java:1125)
W/Watchdog( 5205): at com.android.server.SystemServer.init1(Native Method)
W/Watchdog( 5205): at com.android.server.SystemServer.main(SystemServer.java:1116)
W/Watchdog( 5205): at java.lang.reflect.Method.invokeNative(Native Method)
W/Watchdog( 5205): at java.lang.reflect.Method.invoke(Method.java:525)
W/Watchdog( 5205): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:774)
W/Watchdog( 5205): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:590)
W/Watchdog( 5205): at dalvik.system.NativeStart.main(Native Method)
I/Process ( 5205): Sending signal. PID: 5205 SIG: 9
Change-Id: I8ff9892d8d072d8dc599a73de4bdb75e3b1a6e97
Instead of calling the reboot system call ourselves, send
a message to init asking it to reboot the system. Init is in
a better position to make sure the system is cleanly shutdown.
Get rid of CAP_SYS_BOOT from system_server.
Bug: 8646621
Change-Id: I200722412844ad8d99e35a442021c6263c3ebc05
1. Remove Sensor Event Pool.
2. Allocate fixed array values for each Sensor added.
- Needed for backward compatibility.
3. Use SDK checks for backward compatibility for
rotation vector.
b/8165631
Change-Id: I2d2cf10d3460478ed7af8e6188343f4bb033503c
A Surface can trivially be created from a SurfaceTexture.
Update ElectronBeam to use this new API.
Bug: 6940974
Change-Id: I20459443d0d853e3f8ae23104c08d185c336abea
SurfaceControl is the window manager side; it can
control the attributes of a surface but cannot push buffers
to it. Surface on the other hand is the application (producer)
side and is used to push buffers to the surface.
Change-Id: Ib6754c968924e87e8dd02a2073c7a447f729f4dd
The broadcast of ACTION_SHUTDOWN has a timeout of 10 seconds. To
reduce the risk of hitting the timeout and speeding up the
shutdown sequence in ShutdownThread we set the priority of the
BroadcastReceivers to FLAG_RECEIVER_FOREGROUND.
We have seen that this change reduces the shutdown time when
the system is under heavy load.
Change-Id: I22cbf6af8cf6fc4bdefaa1c3da8a7eed7e7b7674
On some devices, we need to apply heuristics to determine whether
the device is docked on a wireless charger because the charging
circuits do not provide sufficient information to know whether
the device is on the charger unless it is actually receiving
power.
The previous heuristics only considered the battery level to
suppress spurious dock signals.
The new heuristics also take into account whether the device
appears to have moved from its previous position on the dock.
Bug: 7744185
Change-Id: I5ba885dac25b37840b6db46b8a0f30968a06776c
Change the power manager to use two different kernel wakelocks
to distinguish between an application or the display keeping the
CPU alive. This may help make the output of "dumpsys batteryinfo"
easier to interpret.
Bug: 7726759
Change-Id: Iaff96ad74030d00200617b459679ea16390a8da5
Only plays a tone if the battery level is below 95% which
is the same heuristic used when determining whether to turn
the screen on.
Use new low battery and wireless charging sounds on Mako.
Bug: 7371658
Change-Id: Ia4527ec398d024ee418a4287e1fcbf0ec83bcc24
If a rotation occurred while the electron beam surface was showing,
the surface may have appeared in the wrong orientation. We fix this
problem by adjusting the transformation matrix of the electron beam
surface according to the display orientation whenever a display
transaction occurs.
The rotation itself is allowed to proceed but it is not visible
to the user. We must let this happen so that the lock screen
is correctly oriented when the screen is turned back on.
Note that the electron beam surface serves two purposes.
First, it is used to play the screen off animation.
When the animation is finished, the surface remains visible but is
solid black. Then we turn the screen off.
Second, when we turn the screen back on we leave the electron beam
surface showing until the window manager is ready to show the
new content. This prevents the user from seeing a flash of the
old content while the screen is being turned on. When everything is
ready, we dismiss the electron beam.
It's important for the electron beam to remain visible for
the entire duration from just before the screen is turned off until
after the screen is turned on and is ready to be seen. This is
why we cannot fix the bug by deferring rotation or otherwise
getting in the way of the window manager doing what it needs
to do to get the screen ready when the screen is turned on again.
Bug: 7479740
Change-Id: I2fcf35114ad9b2e00fdfc67793be6df62c8dc4c3
Turning off animations in the Developer options creates a ValueAnimator
duration scale of 0. This is used as the denominator in RampAnimator
which, if the numerator is also 0, sets mAnimatedValue to NaN. Rounding
NaN to the nearest int produces 0 which is then assigned to
mScreenBrightness in DisplayPowerState.
A copy mistake which assigned mTransitionAnimationScale as the default
value for mAnimatorDurationScale in WindowManagerService is also
fixed here.
Bug 7515609 fixed.
Change-Id: I39f8d0a7abdd5a1fe70d757fe95fbddaf7a0ed51
ACQUIRE_CAUSES_WAKEUP is supposed to be ignored if combined with
PARTIAL_WAKE_LOCK. Instead it was being carried out for any values
of the WakeLock level.
This change reverts behavior to closely match
previous releases of the framework by only honoring
ACQUIRE_CAUSES_WAKEUP for screen wake lock levels. The only
difference being that in previous releases ACQUIRE_ could have been
combined with PROXIMITY_SCREEN_OFF_WAKE_LOCK (it never was) and
now such a combination will ignore the ACQUIRE_ flag.
Bug 7532258 fixed.
Change-Id: I46e848d8fd1b57e54c63141bf3d4f353986b5bdf
This change removes the modulation of the screen brightness
by the electron beam level. The screen brightness remains
constant while the electron beam animation is playing.
Previously we were multiplying the screen brightness by the
electron beam level so as to animate both at the same time.
The problem is that when the screen brightness is already dim
to begin with, it may not be possible to see the electron beam
animation because the modulated screen brightness rapidly
converges on 0. This may manifest give the appearance of
an abrupt transition or a flash as the screen turns off.
Bug: 7387800
Change-Id: I27b90f0098bbdc3de1d66fad819548d1301405cd
Reverts a previous change that made the screen dim slowly instead.
The quick transition does a better job of attracting the user's
attention to the fact that the screen is about to turn off
unless the user touches the screen.
Bug: 7386034
Change-Id: I81e4d8939f6791b96352004984a9e5b2aab79788
Reintroduced the stability time heuristic which requires brightness
to remain significantly above or below the currently accepted
ambient brightnes before effecting a brightness change. The
heuristic has the nice property of preventing light sensor noise
from causing oscillations in brightness even when the noise has
a relatively large magnitude (such as in low light environments).
The time bound and filter thresholds are current set so that
brightness increases typically occur within 5 seconds of a change
in the ambient environment. Decreases take somewhat longer and
typically occur within 10 seconds.
Changed the timing for brightness animations when the screen is
being dimmed due to a pending user activity timeout. The screen
now dims slowly but then brightens rapidly when touched.
Previously the screen dimmed quickly and brightened slowly which
felt somewhat unresponsive.
Fixed a problem where a brightness change might not occur because
the light sensor had not reported a new value in a long time.
Now we synthesize measurements when needed to ensure that a
transition will take place if appropriate.
Bug: 7387800
Change-Id: I998df2fec59922042a41a1ba4af97ea52c0bd02a
Reduce latency of screen on/off and improve how it is synchronized with
backlight changes. Screen state changes are no longer posted to vsync
which should save time. What's more, the state change occurs on a
separate thread so we no longer run the risk of blocking the Looper
for a long time while waiting for the screen to turn on or off.
Bug: 7382919
Bug: 7139924
Change-Id: I375950d1b07e22fcb94efb82892fd817e2f780dc
So that:
- the values can be shared (to fix assoc bug)
- the values can be customized in product overlays
Bug:7373284
Change-Id: I37f037082523a3d975f6014f36afa28c60117372
Apply additional hysteresis controls to prevent repeated brightness
changes within a short interval.
Bug: 7266090
Change-Id: I73122457f6f3200c80188d3716ce2baf38f6a0a6
If the user has requested that dreams start when docked and a user
activity timeout occurs, then start dreaming assuming all of the
other usual conditions are appropriate for dreaming (the device is
powered, etc.).
Previously dreams only started when the device was initial docked
but not if the device fell asleep while remaining docked.
Bug: 7281240
Change-Id: I72c3f854fd1ae8e6615f4fa6e4c4ecd8de37c84b
If the user activity timeout expired and the battery appears
to be draining faster than it is charging then stop dreaming
and go to sleep.
Bug: 7312455
Change-Id: I1b9d89e5b2647c72c455d2792e3778a2fe6a4e34
On some devices it can take hundreds of milliseconds to get a
brand new EGL surface performing in tip-top shape. To get it
ready make it do a few pushups before the show begins.
Bug: 7318962
Change-Id: I7ae92ce100c368327042a29ffa65faee9b567c8d
This fixes a problem where the screen times out shortly after
boot before the user has had a chance to interact with the device.
Now we wait until the boot animation has completed then set
boot completed, poke user activity and start the countdown.
Bug: 7316397
Change-Id: Ie5a0b1012d265e655d33cc8fba49ca349f48f1de
A dream may itself hold a wake lock in order to keep the screen
bright as it runs. However this wake lock also causes the device
to stay awake even when it is not plugged in which is undesirable.
This change makes full wake locks behave differently when napping
or dreaming. The wake lock still keeps the screen bright but
it does not prevent the device from falling asleep. This is
similar to our policy of ignoring full wake locks completely when
the device is manually put to sleep by the user.
Bug: 7295909
Change-Id: Id99e82d2143ae1a81629281d6407d7527efb8137
Fixes an issue where the dim surface alpha was not actually being
animated like it was supposed to.
Bug: 7224614
Change-Id: Iffd54367ca97ae7fd4b9603807f4e036750442b2
Always use the ElectronBeam now, even when we are only animating
the backlight so that we will have a black surface remaining
on the screen after the screen turns off.
When turning on the screen, keep the black surface showing until
we unblock screen on then dismiss it as usual.
This change eliminates the flashing of old display content when
the screen is turned on. It also helps to conceal some of the
latency of turning the screen on. We always turn the screen on
immediately (even when screen on has nominally been blocked) and
rely on the black surface to hide the screen contents until the
last moment. Dismissing the black surface is practically
instantaneous compared to turning the screen on.
Bug: 7299370
Bug: 7139924
Change-Id: I57d13287acd05bd0a48811095bb02dc7bc7cbeb6
Defines the lower end of the allowable screen brightness range
as the lesser of the dim level, the user brightness setting
minimum value and the lowest auto-brightness level.
Bug: 7295909
Change-Id: I7a72b4611631f9e51578205ff12898c5bae02b1b
Fixed a race between the UiModeManagerService and PowerManagerService
both of which are trying to wake the device when docked / powered.
Bug: 7281240
Change-Id: Ia41fef48f17f2a2eb56549437d295f9a86c95af2
