| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| | |
Change-Id: Idb3976edfae37293ed75cb5b869b4b42d8042bbe
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes it can take a long time to turn the screen on. That's not
good but what's worse is that the user will often get impatient
and press the power button again which effectively cancels the
process and makes the screen not come on at all. The user may
then conclude that the device ignored the power key press.
This change suppresses power key presses while we're already in the
process of turning the screen on so that at least the screen comes
on eventually, even if it's slower than we would like.
Bug: 17753363
Change-Id: I23083873e35a3dcfa5c20b6f870f53c18e465582
|
|
|
|
| |
Change-Id: Ifa6f06f7dfa63b740352ad7388f33911649afcb0
|
|
|
|
|
|
|
|
|
|
| |
When the status guard is not available, (e.g. when the window is not
drawing system bars) do not consume the insets when an action mode is
active.
Bug 17691453
Change-Id: I459622eaf161a96152fb9ac5f60bb9508aa4de89
|
|
|
|
|
|
|
|
|
| |
This checks if the phone app is currently getting or in a call when a
media key event is sent and sends it to the phone session instead of the
foreground app if it is.
bug:17527302
Change-Id: Ie5d6cf0c897da81d106f2b1a0561b79f4fc35e82
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Create the KeyguardServiceDelegate but don't bind until boot is done.
Until the keyguard is bound, the delegate will assume it should be
in a secure state.
Bug: 17464800
Change-Id: I91650d1e3e3ea993168855bc3444b905aac9aac3
|
|\ \ |
|
| |/
| |
| |
| | |
Bug: 17643810
Change-Id: I4747414224c3219bf91c0c83e969530cb20f96e5
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| | |
BUG: 17628875
Change-Id: I03bf6cfd68d0ca2904b43e00f68d07d497ff9879
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Rather than saying 'Alert', say 'Alert, ...' describing the contents
of the menu.
Bug: 17559783
Change-Id: I43b1b5ba9ce76b8c205f2d29f2f8ee7569517c19
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Once upon a time when the world was fresh and new, the heavens
had an easy rhythm. Day and night. Night and day. In the day,
the pixel fairies would cavort and play in the bright gardens
with narry a mark of shadow or gloom. In the night, they would
rest peacefully, dreaming no dreams and knowing no fear.
Then one night a fairy dreamed the first dream. At first
the dream was peaceful, full of colors and delight, hopes and
memories. Then all at once, jarringly, it awoke in bright
daylight. The pixel fairy knew fear, for the world had changed
and it was unprepared.
Time passed and the pixel fairies grew accustomed to their
fate, day and night, night and day, sometimes dreaming, until
there came a night when a fairy did not sleep. It roamed
the land in a dreamless doze, lost and afraid amid a grim haze
of grey and darkness. The fairy despaired. It wanted no
part of this place. It pretended for a time to be awake but
the bright daylight would not come. It pretended for a time to
be dreaming but the colors and memories would not come.
That is when the fairy wished for oblivion. Then just as
suddenly, it awoke in the daylight. It fell to the ground,
stunned as if it had forgotten how to walk in the too bright
daylight.
Though the world again grew softer and kinder in time, the pixel
fairies were never the same. For the night is dark and full
of terrors.
---
It used to be easy. Screen on and screen off could explain almost
everything about the state of the device but it's different now with
ambient display. We need to be able to wait for all windows to be
drawn even in the case where the device is still nominally asleep.
In truth, the window manager policy which drives a lot of these
interactions is a thicket of outdated assumptions.
Added a new method to tell the window manager policy when the screen
is being turned off so that it can correctly account for changes
to the interactive state (wakeUp and goingToSleep) and screen state
(screenTurningOn and screenTurnedOff). Now we can independently
poke keyguard during interactive state changes and we can apply
screen on blocking during screen state changes.
Moved the code which manages screen on blocking (which is what
ensures the UI has fully drawn before revealing screen contents)
from the power manager to the display manager since the display
manager is in a better position to accurately track the state of
the screen, particularly when the screen is being turned off.
Fixed a bunch of synchronization issues. Previously some work
had been moved to a handler without considering what might
happen if it became reordered relative to other work happening
elsewhere. Documented the desired behavior in the code to
prevent this from happening again.
There's still a bunch of stuff in here that isn't quite right,
particularly the assumption that there's only one screen, but
it's good enough for now. Hopefully there aren't too many bugs.
Bug: 17605802
Change-Id: Ic7319e09948c8a3cda014d7e169c964a3ad86f14
|
|/
|
|
|
|
|
|
|
|
| |
Bug: 16978006
Don't HWUI-accelerate KeyguardScrim
Aggressively trim memory as soon as a ViewRootImpl
dies or has its visibility changed.
Change-Id: Ie1b7c9d30653456bd2e9f309128174f972999368
|
|
|
|
|
|
|
|
| |
This allows us to ensure windows are fully drawn before unblocking
screen on while dozing.
Bug: 17516245
Change-Id: Ibe63c212b8db855ce26a34a8169f33764b266ee6
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Bug 17430536
Change-Id: I962dfa10d3cb4f735dcaa68f17e7ff278d1580a2
|
|/
|
|
|
| |
BUG: 17567245
Change-Id: I3c37d228e3a9d3060a4fd1a86abf2ffbf91802e8
|
|\
| |
| |
| | |
into lmp-dev
|
| |
| |
| |
| |
| |
| | |
BUG: 17262483
BUG: 17513621
Change-Id: I74764570a11da162a224e94978e21e52d17e2e84
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Bug: 17516789
This change corresponds to a sudden influx of bad surface crashes.
Reverting to see if stability returns as this was an optimization
CL
This reverts commit 29ff1bc57ac2c995c56f15ed6e56e5fb247b2a44.
Change-Id: I7835e89017161d94ad05fe46d81bd437c3dae3a7
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| | |
This was a result of using the wrong systemUiVisibility listener.
Instead, DecorView now follows the structure in ActionBarOverlayLayout,
where we use onWindowSystemUiVisibilityChanged for everything.
Bug: 17494017
Change-Id: I1be9165c5ff80021f3a7889d3811cf0c54f68e71
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes two bugs introduced by change
I7bd32531130d199c0734ffcb800194e77b7e16c3:
When the system window insets consumed by DecorView
change as a result of changing flags, the insets must
be redispatched to the hierarchy.
Also fixes a bug where, as a result of removing the wrong
implication of the SYSTEM_UI_FLAG_LAYOUT_STABLE flag by
FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS, the status bar was
being forced to black when returning from recents.
Bug: 17489047
Bug: 15046646
Change-Id: I127b0ff3b17c4873a7c28d67020f84298ed09db2
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In the past it's been a recommended approach to avoiding overdraw for
apps to set their window background to null at runtime if their
content view fully covers their window surface. The problem with this
is the IME.
The IME can force a resize of the window at unexpected times and
unless an app has been configured to fit system windows and manually
cover the padded area that the IME window covers, the asynchronous
nature of the IME-show process can leave surface buffer garbage
visible to the user. In previous platform versions this wasn't an
issue since pre-renderthread we would always animate a crossfade from
the closed to open state. This animation was always a bit of a hack
since it could break the contract of requestLayout/invalidate on the
view hierarchy - it could result in a draw happening into the saved
"before" state of the crossfade before a pending layout.
Now that this has been cleaned up the buffer garbage is sometimes
visible.
To prevent this, PhoneWindow now detects the state of a null window
background and draws solid rects into the area not covered by a
window's content. Which color is determined by the window context's
theme, though this is not a public API available to apps.
Bug 17006497
Change-Id: I714439a1608c4ae135f3d9d49bb165330d9fbe9f
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
500 msec is apparently not enough time to push the pixels around on
a Volantis (or Manta, or occasionally Deb). Increasing the timeout
eliminates turning the screen on before the surface is completely
drawn.
Optimizing the drawing path so that we can return the timeout to
500ms has been filed as b/17496306.
Fixes bug 16849724.
Change-Id: Ic0fca68bc41caa67dba973b5c40915756dc4730f
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Changing package from android.telecomm to android.telecom
- Changing package from com.android.telecomm to
com.android.server.telecomm.
- Renaming TelecommManager to TelecomManager.
Bug: 17364651
Change-Id: I192cb5d189f55db012ea72ee82ccc5aedbc21638
|
|\ \ \
| | | |
| | | |
| | | | |
hierarchy" into lmp-dev
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
For windows with L-bars, the window size has been extended
to include the area below the nav bar. This change makes
DecorView hide that fact from the rest of the view hierarchy,
unless it has explicitly ask to extend below the navigation bar.
Bug: 17421744
Change-Id: I7bd32531130d199c0734ffcb800194e77b7e16c3
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* changes:
Show all windows from activity that hides keyguard
Make sure FLAG_DISMISS_KEYGUARD brings up bouncer
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Popup windows from the activity hiding the keyguard weren't being
shown. This change retrieves that activity from PhoneWindowManager
and applies the show or hide call to the windows that match the
activity.
Fixes bug 16479813.
Change-Id: Ia6fe97240aec85c5233eee9038138f7d48095a6e
|
| | |/ /
| |/| |
| | | |
| | | |
| | | | |
Bug: 17449741
Change-Id: I682b9acb1d8bca8a83953a59c9548f9f0ca56f4b
|
|\ \ \ \
| |_|_|/
|/| | |
| | | | |
lmp-dev
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Bug 17006497
Window content transitions were being enabled by default in
the Material Theme so that Activity Transitions could be
enabled by default. Unfortunately, this gave the effect that
many applications did not want -- the default transition between
window content is a fade out/in. Here, a new attribute is
added: windowActivityTransitions that is enabled by default
in the Material theme and windowContentTransitions is disabled
by default in all themes.
Change-Id: Iab453d608f00a48ff7ab7f09ce84b52cf5f20294
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
An earlier fix in L disabled hw acceleration for the starting window
after the system process became hw accelerated. This was done to preserve
the old behavior of the starting window having some default behavior
(in particular, being filled with a default color). However, this ends up
being a memory and performance problem on some platforms (memory because
some platforms have backing store for software surfaces, performance
because it takes far longer to create a screen-size software surface than
a hardware surface).
The fix is to allow the starting window to inherit the hw acceleration
behavior of its process, and to detect when we are drawing the contents
of that starting window and to fill it with a default color (black).
Issue #17443449 use hardware rendering for app preview window
Change-Id: I8be8111d9e38c51fbbc07185acca065815ce26dc
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Issue #17394151: WallpaperService / Engines need to get notified
of WindowInsets
Issue #17394203 Wallpapers need a system API to be shifted in order
to support burn in protection
Adds a new API on WallpaperManager to set additional offsets to
make wallpapers extend beyond the display size.
Insets are now reported to wallpapers, to use as they may. This
includes information about the above offsets, so they can place
their content within the visible area. And to help with this, also
expose the stable offsets APIs in WindowInsets which is also very
useful information for the wallpaper.
Another new API on WallpaperManager to set a raw offset to apply
to the wallpaper window, forcing it to move on the screen regardless
of what the wallpaper is drawing.
Fix wallpapers when used with overscan enabled, so they still extend
out across the entire screen. Conveniently, the above new window
insets information is very useful for this case as well!
And a new wallpaper test app for all this stuff.
Change-Id: I287ee36581283dd34607609fcd3170d99d120d8e
|
|\ \ \
| |_|/
|/| | |
|
| |/
| |
| |
| |
| | |
Bug: 17367264
Change-Id: Id43fc182505e66c2794a76d74e2ac9a6d4f9d569
|
|/
|
|
|
|
|
|
|
|
| |
The new key interception policy removed the wake status from key
presses while in the device was dozing. Since we still want to wake
from these keys by going from doze -> fully interactive, just don't
remove the wake status and allow the device to be woken up as normal.
Bug: 17422475
Change-Id: I835e51cc9c557d8ce2e8f8502d84f04aae138e79
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We need to allow for event dispatching in non-interactive states so
that we can enable a richer set of interactions when a device is
dozing (i.e. is in a low power state with an Always-on-Display).
Bug: 17167296
Change-Id: I8ae0f544a8106cb91ff38c2309b8b57cbe2f2c72
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| | |
This lets Now and other assistance apps know to start up expecting a
specific type of input (e.g. keyboard).
Bug: 16355810
Change-Id: I158e416ef8310a01cb22b19fd5b6850d2429e266
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
17200185
* commit '0641ab3dd0282edc272f425a245ede63a78dd222':
Add clear_top flag to settings action intent. Bug: 17200185
|
| |\ \
| | | |
| | | |
| | | |
| | | | |
* commit '636f3eac6d3ae69e7cc1dd159fe7cdbb043ce2df':
Add clear_top flag to settings action intent. Bug: 17200185
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Bug: 17200185
Change-Id: I156a8726055452b56d8ccd52010cdea8baaa79c3
|