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
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
Dream manager now fires broadcast intents when entering + exiting
dreamland (except when testing).
Power manager can now listen for dreams ending, using polling only
as a backstop.
Also:
- Bullet-proof dream-manager/dream against known failure modes
- Add new read/write dream permissions
- Refactor dream-manager to delegate work + state management into
a new DreamController class, via a handler
Bug:6999949
Bug:7152024
Change-Id: I986bb7812209d8c95ae1d660a5eee5998a7b08b1
Disable backlight before turning off the screen.
Enable backlight after turning on the screen.
Bug: 7016215
Change-Id: Idb763f85f7a40e852483c57e0a0d1b27eb943f08
This is the one relevant setting that moved from System to Global,
a move that we do not automatically redirect on writes.
Change-Id: I7b26d0c364695c4a10a7cd477db3dfcfe89d7ef5
Added more complete support for logical displays with
support for mirroring, rotation and scaling.
Improved the overlay display adapter's touch interactions.
A big change here is that the display manager no longer relies
on a single-threaded model to maintain its synchronization
invariants. Unfortunately we had to change this so as to play
nice with the fact that the window manager wants to own
the surface flinger transaction around display and surface
manipulations. As a result, the display manager has to be able
to update displays from the context of any thread.
It would be nice to make this process more cooperative.
There are already several components competing to perform
surface flinger transactions including the window manager,
display manager, electron beam, overlay display window,
and mouse pointer. They are not manipulating the same surfaces
but they can collide with one another when they make global
changes to the displays.
Change-Id: I04f448594241f2004f6f3d1a81ccd12c566bf296
You can now use ALL and CURRENT when sending broadcasts, to specify
where the broadcast goes.
Sticky broadcasts are now correctly separated per user, and registered
receivers are filtered based on the requested target user.
New Context APIs for more kinds of sending broadcasts as users.
Updating a bunch of system code that sends broadcasts to explicitly
specify which user the broadcast goes to.
Made a single version of the code for interpreting the requested
target user ID that all entries to activity manager (start activity,
send broadcast, start service) use.
Change-Id: Ie29f02dd5242ef8c8fa56c54593a315cd2574e1c
Split the DisplayManager into two parts. One part is bound
to a Context and takes care of Display compatibility and
caching Display objects on behalf of the Context. The other
part is global and takes care of communicating with the
DisplayManagerService, handling callbacks, and caching
DisplayInfo objects on behalf of the process.
Implemented support for enumerating Displays and getting
callbacks when displays are added, removed or changed.
Elaborated the roles of DisplayManagerService, DisplayAdapter,
and DisplayDevice. We now support having multiple display
adapters registered, each of which can register multiple display
devices and configure them dynamically.
Added an OverlayDisplayAdapter which is used to simulate
secondary displays by means of overlay windows. Different
configurations of overlays can be selected using a new
setting in the Developer Settings panel. The overlays can
be repositioned and resized by the user for convenience.
At the moment, all displays are mirrors of display 0 and
no display transformations are applied. This will be improved
in future patches.
Refactored the way that the window manager creates its threads.
The OverlayDisplayAdapter needs to be able to use hardware
acceleration so it must share the same UI thread as the Keyguard
and window manager policy. We now handle this explicitly as
part of starting up the system server. This puts us in a
better position to consider how we might want to share (or not
share) Loopers among components.
Overlay displays are disabled when in safe mode or in only-core
mode to reduce the number of dependencies started in these modes.
Change-Id: Ic2a661d5448dde01b095ab150697cb6791d69bb5
Cleaned up the implementation of Surface and SurfaceSession
to use more consistent naming and structure.
Added JNI for all of the new surface flinger display API calls.
Enforced the requirement that all Surfaces created by
the window manager be named.
Updated the display manager service to use the new methods.
Change-Id: I2a658f1bfd0437e1c6f9d22df8d4ffcce7284ca2
The system depends on receiving reliable vsync signals from
surface flinger during the boot process. If it doesn't get them
because the screen is off then a hang may occur.
This isn't a problem when surface flinger manages the screen
blanking itself but it is a problem for devices that still
rely on early-suspend. When early-suspend is involved, the
screen may be off without surface flinger knowing. This is a
problem because surface flinger will only synthesize fake
vsyncs when it knows the screen is off, otherwise relying
on the hardware to generate vsync signals itself. Unfortunately,
the hardware won't generate vsync signals if the screen was
turned off by early-suspend, so we have a problem.
Bug: 6975688
Change-Id: Iaf4527f716bf4ea72cc3e6fdaf060855697b02f2
There are potentially very many Handlers owned by services
that should not be blocked by barriers introduced by UI traversals
occurring on the same thread (if that ever happens).
Add some convenience constructors to make it easy to switch
these Handlers over to being async.
Bug: 7057752
Change-Id: I64d9bffe81e7c52ada4cfad4e89d4340153f4688
