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
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
This fixes an issue where the device would not lock immediately
when the user quickly pressed power off / power on even if
configured to do so. We were suppressing the screen off
and wake up broadcast in this case.
Now we make sure to always send at least one broadcast to
indicate the transition. We still collapse back-to-back
full cycle transitions though so as not to end up enqueuing
useless broadcasts.
Bug: 7061116
Change-Id: I7211c5fd963c271c2b0aceb4d2f746063c629079
7267494 Calendar is not syncing
Check for whether a content provider is dead before returning
it. This is kind-of a band-aid, but probably the right thing
to do; I'm just not sure exactly the full details of why this
problem is happening. Hopefully this "fixes" it, though I don't
have a way to repro to tell.
7212347 System power off dialog is only visible to user 0
Make it visible. Also turn on some battery debugging stuff and
clean it up so we can just keep it.
Change-Id: I5add25bf2a763c8dfe1df23bc5c753a9ea5d157a
Previously dreams could not be started unless plugged in.
Now we allow them to start but they will eventually stop
if a user activity timeout occurs and no screen wakelocks
are held.
Bug: 7253639
Change-Id: I84703e144ca6d4aba1ef9437f04a201c3dde8a49
Take into account whether the screen off timeout is very short.
If so, we use a shorter dim timeout. Don't allow the dim
time to be more than 20% of the total screen on time so that
the screen remains bright at least 80% of the time even when
the timeout is short.
Bug: 7273646
Change-Id: Iccea764b90f0d8b1df7009d26160c6bcf6eabe5b
We can't accurately detect whether the device is resting
on a wireless charger unless it is actually charging.
So we need to tweak the screen on when plugged / unplugged
policy accordingly to avoid spurious wakeups.
Bug: 7234284
Change-Id: I624b559e2e92b8813b12090bc20eca5f5158997e
Some of the BatteryService state was being locked
sometimes and it wasn't at all consistent.
Bug: 7158734
Change-Id: I46e75f66fde92c5a577a80a6bd99c9573066f3c1
Added a new WindowManager.LayoutParams inputFeatures flag
to disable automatic user activity behavior when an input
event is sent to a window.
Added a new WindowManager.LayoutParams field userActivityTimeout.
Bug: 7165399
Change-Id: I204eafa37ef26aacc2c52a1ba1ecce1eebb0e0d9
Clearly isolated the DreamManagerService and DreamController
responsibilities. DreamManagerService contains just enough logic to
manage the global synchronous behaviors. All of the asynchronous
behaviors are in DreamController.
Added a new PowerManager function called nap() to request the device
to start napping. If it is a good time to nap, then the
PowerManagerService will call startDream() on the DreamManagerService
to start dreaming.
Fixed a possible multi-user issue by explicitly tracking for
which user a dream service is being started and stopping dreams
when the current user changes. The user id is also passed to
bindService() to ensure that the dream has the right environment.
Fix interactions with docks and the UI mode manager. It is
important that we always send the ACTION_DOCK_EVENT broadcast
to the system so that it can configure audio routing and the like.
When docked, the UI mode manager starts a dock app if there is
one, otherwise it starts a dream.
This change resolves issues with dreams started for reasons other
than a user activity timeout.
Bug: 7204211
Change-Id: I3193cc8190982c0836319176fa2e9c4dcad9c01f
