Not very clean, this has a special hack in the window manager to
redo layout when a dream window is shown. After MR1 we should clean
this up (and the various other special dream hacks).
Change-Id: Ic1a5a2b10a0a07b4a5dccdbf0736b614ec06dd4a
... and check for null returns. This prevents DisplayContent objects
from containing null Display references.
Bug: 7368565 fixed.
Change-Id: I830fb4c1349204c366193657a95a92c48ccee66c
When a window is attached to another window use the parent window's
attributes to determine whether the child window should be shown
to all users.
Bug: 7328633 fixed.
Change-Id: I9601c149af87f624378e6895063bb3179d4f845e
1. Sometimes unlocking the device when the IME is up and triple tapping on the keyboard
toggles screen magnification. The core reason is that when the kayguard window is
shown we hide all other windows and when it is hidden we show these windows. We did
not notify the screen magnifier for windows being shown and hidden. Also when the
windows are shown we may reassign layers to put the IME or the wallpaper in the
right Z order. The screen magnifier is now notified upon such layer reassignment
since window layers are used when computing the magnified region.
bug:7351531
Change-Id: I0931f4ba6cfa565d8eb1e3c432268ba1818feea6
Speed up of wallpaper loading on Manta means this workaround is no
longer necessary.
Bug 7354440 fixed.
Change-Id: Ic0ad3c689abb5342fb29c824857db9d5c2d45008
This change makes WindowManager use the new eAnimation flag when animating
windows. This prevents some of the window updates from being combined with
updates from prior animation frames.
Bug: 7353840
Change-Id: I5a9f8fa2c1a2f5f08363a45cd9f28bb97cd77080
Add Keyguard to list of windows that can't be hidden by keyguard.
Don't assign Configuration to window until layout has had a chance
to compare it to window's existing Configuration.
Bug: 7094175
Change-Id: I99a9fd4af9a31871fe130db7b6bdf49bd51a6092
Removal of the mExiting test in a previous CL was a mistake leading
to z-order errors. In particular the auto complete dialog was on top
of the IME and was being dismissed due to touches on the IME.
Restoring mExiting alone missed cases where apps were exiting which
don't set mExiting. Adding a test for membership in mClosingApps
fixes that.
Bug: 7327220 fixed.
Change-Id: I3965b8a07080d1347bdada51ffeafe6ef2e32c8e
The bug cropped up again. Need these statements to pin it down.
This reverts commit f1f3b49b949af72692f7f85a1c1ef220e8630e30
Change-Id: Ie0548232daff32ee2541249b0950e23bd98c08d2
More pixels take longer. Timeout was occurring before Status and
Navigation Bars were finished drawing causing them to animate in
during rotations.
Bug 7307718 fixed.
Change-Id: Iccf27b6172d0c9831690cc2fcf93027a40b705d8
The query WindowState.isDisplayed did not take into account being
displayed due to app animations.
When an existing input method target was animating away the logic
for detecting if it was still on screen was faulty. This led to
assigning the input method to a layer below its target and obscuring
the input method until the animation was complete.
Bug: 7296703 fixed.
Change-Id: Ib00db4f21b726ed57d25d6a1e796b65a7d45ee97
During app freezes resized windows were being dropped if the freeze
window timed out. This fix adds windows to the list of resized
windows but does not notify the clients of the resize until freezing
is completed.
Bug: 7094175 fixed.
Change-Id: Iee1f5f532a0e661fbf900e4540146ae4b645d68e
The new attribute allows an Activity such as the alarm to appear
on all users screens.
Bug: 7213805 fixed.
Change-Id: If7866b13d88c04af07debc69e0e875d0adc6050a
7296314 Crashing dreams are stuck
7296510 Transition from lock screen to dreaming is really bad
The window layer for dreams is now moved down below the keyguard,
so that some of the expected stuff like crash and ANR dialogs can
be seen on top of them. While doing this, I reorganized how we
define the layers so the constants are just in the switch statement,
so it is much less crazy-making trying to read how things go
together.
We now have some special cases for when a dream is being shown
to turn off its animation if the keyguard is currently shown.
Since we know it will be hiding the keyguard we need it to be
shown immediately so that you don't see whatever is behind it.
Cleaned up some handling of when the lock screen is displayed
while a FLAG_SHOW_WHEN_LOCKED window is displayed, so that the
lockscreen doesn't transiently get shown and mess up the fullscreen
or system UI state. This also fixes problems with any normal
activity that is doing this.
Hid the methods on DreamService for setting lights out mode. It
doesn't make sense to have such methods on DreamService, because
you can just as well do that on your own View that is showing the
dream content, and when you can do that you can fully participate
in the (required) interactions about it such as being told when
the mode goes away.
The DreamService method for going fullscreen now uses the window
flag for doing this, which is what you want, because you want this
state to persistent on that window and not get knocked out if
something above the window tickles the system UI state.
Also fixed the problem where dreams that hid the status bar would
have a jerky animation when going away, since they were causing the
activity behind them to be layed out without the lock screen. This
is a kind-of ugly special case in the window manager right now to
just not layout windows that are behind a dream. Good enough for MR1.
Change-Id: Ied2ab86ae068b1db0ff5973882f6d17b515edbcd
Created a new flag that indicates that a window should be shown
to all users. For the flag to be valid the owner of the window
must have system permissions.
Also separated system window types into those that show to all
users (e.g. StatusBar, Keyguard, ....) and those that appear only
to the owning users (e.g. Drag, ANR, TOAST, ...). Those that appear
only to their owner can override their default behavior using
the new flag (e.g. LowBattery).
Fixes bug 7211965.
Change-Id: I1fdca25d57b7b523f0c7f8bceb819af656c388d4
Add a new call to the activity manager for the input dispatcher
to report about any pid having an ANR. This has a new feature
where it can also tell the activity manager that it is above the
system alert layer, so the activity manager can pop its ANR dialog
on top of everything if it needs to. (Normally we don't want
these dialogs appearing on top of the lock screen.)
Also fixed some debugging stuff here and there that was useful
as I was working on this -- windows now very clearly include
their uid, various system dialogs now have titles so you know
what they are in the window manager, etc.
Change-Id: Ib8f5d29a5572542cc506e6d338599ab64088ce4e
Setting hidden prior to test guarantees the test will fail. This
then causes the exit animation to not be loaded and consequently
the window is immediately hidden. Then, when the window is removed
later it reappears in order to animate away. The consequent flash
is undesirable.
Bug: 7242373 fixed.
Change-Id: I56966bd9060124be372702090f86b29b4deea8c0
Removing one window causes its subwindows to also be removed.
We have to be careful when traversing the window list
because multiple windows may be removed at a time so we
don't get IndexOutOfBoundsException due to the window
list changing in unexpected ways.
Bug: 7273702
Change-Id: I0ed9ba00c325ad178ab28919ce2e763cb6fd38ba
Includes telephony, WindowManager, PackageManager, and debugging
settings. Update API to point towards moved values.
Bug: 7231764, 7231252, 7231156
Change-Id: I5828747205708872f19f83a5bc821ed0a801cb79
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
WindowManager was notifying DisplayManager of content if any window
existed on a display. Now the window must be visible and we must not
be showing a Dream or the Keyguard.
Bug: 7214060.
Change-Id: I9ce4a49aabfbac22ff1e39a837199ce35b9f7503
...#testScreenLayout failures on JO
This doesn't actually fix it; I have concluded that the test is broken
(the platform is correctly reporting that this is a NOT LONG device
because in portrait once you account for the status bar and system
bar our size is 880dp high and 600dp wide, which is not enough for us
to be in the LONG config).
However while working on this I noticed that the code for computing
the configuration of the external display was wrong. I have fixed
that by putting this code for computing these parts of the configuration
in a common place that both the window manager and external display
code can use.
Change-Id: Ic6a84b955e9ec345a87f725203a29e4712dac0ad
- Restore test of hidden to isGoneForLayoutLw(), without that
we return false when setAppVisibility(true) is called which leads
to early layout of windows. Particulary on return from full screen
to non-full we lay out once before recognizing that the status bar
should be back and then again once the status bar appears causing
a jump. Fixes bug 6470541.
- Add a new test for configuration size changes to gone or hidden
windows. This forces a layout call to these windows which informs
them of the new size even though they are not shown until later.
In particular this keeps windows that were in the background
during a rotation from using their old boundaries on return.
Fixes bug 6615859.
- Consolidate WindowState.mConfiguration tests into WindowState.
Change-Id: I7a82ce747a3fcf7d74104dc23f1532efe64bd767
Fixed one setting that was migrated but not marked deprecated.
Removed a hidden setting that is no longer used by the new
power manager service.
Bug: 7231172
Change-Id: I332f020f876a18d519a1a20598a172f1c98036f7
