1. The screen magnification feature was implemented entirely as a part of the accessibility
manager. To achieve that the window manager had to implement a bunch of hooks for an
external client to observe its internal state. This was problematic since it dilutes
the window manager interface and allows code that is deeply coupled with the window
manager to reside outside of it. Also the observer callbacks were IPCs which cannot
be called with the window manager's lock held. To avoid that the window manager had
to post messages requesting notification of interested parties which makes the code
consuming the callbacks to run asynchronously of the window manager. This causes timing
issues and adds unnecessary complexity.
Now the magnification logic is split in two halves. The first half that is responsible
to track the magnified portion of the screen and serve as a policy which windows can be
magnified and it is a part of the window manager. This part exposes higher level APIs
allowing interested parties with the right permissions to control the magnification
of a given display. The APIs also allow a client to be registered for callbacks on
interesting changes such as resize of the magnified region, etc. This part servers
as a mediator between magnification controllers and the window manager.
The second half is a controller that is responsible to drive the magnification
state based on touch interactions. It also presents a highlight when magnified to
suggest the magnified potion of the screen. The controller is responsible for auto
zooming out in case the user context changes - rotation, new actitivity. The controller
also auto pans if a dialog appears and it does not interesect the magnified frame.
bug:7410464
2. By design screen magnification and touch exploration work separately and together. If
magnification is enabled the user sees a larger version of the widgets and a sub section
of the screen content. Accessibility services use the introspection APIs to "see" what
is on the screen so they can speak it, navigate to the next item in response to a
gesture, etc. Hence, the information returned to accessibility services has to reflect
what a sighted user would see on the screen. Therefore, if the screen is magnified
we need to adjust the bounds and position of the infos describing views in a magnified
window such that the info bounds are equivalent to what the user sees.
To improve performance we keep accessibility node info caches in the client process.
However, when magnification state changes we have to clear these caches since the
bounds of the cached infos no longer reflect the screen content which just got smaller
or larger.
This patch propagates not only the window scale as before but also the X/Y pan and the
bounds of the magnified portion of the screen to the introspected app. This information
is used to adjust the bounds of the node infos coming from this window such that the
reported bounds are the same as the user sees not as the app thinks they are. Note that
if magnification is enabled we zoom the content and pan it along the X and Y axis. Also
recomputed is the isVisibleToUser property of the reported info since in a magnified
state the user sees a subset of the window content and the views not in the magnified
viewport should be reported as not visible to the user.
bug:7344059
Change-Id: I6f7832c7a6a65c5368b390eb1f1518d0c7afd7d2
After finding a window in the window list we turn around and look in
the AppWindowToken.windows list for it. If it is a child of a window
in that list we should use the parent windows index as the search
result. Instead we gave up and ended up inserting the window at the
beginning of the windows list.
Bug 7357465 fixed.
Change-Id: If77f343b8597bfbb0b7fa41dedf7972d78d03020
There is this stupid fudge factor applied to window transformations
when doing a screen rotation animation. We need this when rotating,
but when not rotating it causes very visible artifacts. Historically
the non-rotation case only happened due to configuration changes, so
wasn't that big a deal. Now however that we use this when switching
users, it is more annoying. So get rid of it for such cases.
Change-Id: I6b343866c1bad9b16984b4a629917c2f1bb37b9e
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
- If a window was hidden while the configuration changed and then
changed back WindowManagerService would not know that the change
had ever happened and wouldn't notify the window of this. Most
windows wouldn't care but because Keyguard inflates layouts while
it is hidden...
Bug 7094175 fixed?
Bug 7501099 fixed!
Change-Id: If27f5f1d333602dac7719dd39dbdf3fe7954aa06
Creating new surfaces for applications clears the allDrawn flag in the
AppWindowToken. If the app windows were animating when this happened
the animation would complete immediately resulting in jank. This fix
defers clearing allDrawn until the animation completes.
Bug 7326635 fixed.
Change-Id: I5abe3b9ecfbefb476de6a6c8acc394373cc11751
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
Fixes for two dimming problems.
- Dimming was turning off at the start of animation because it was
dependent on hiddenRequested which becomes true while the view is
still visible.
- Looking for windows with FLAG_DIM_BEHIND set stopped at the first
obscured window. But Z-order shuffling due to Animation.setZAdjustment
causes the window list order to be different than the display order.
Consequently windows that are being shown are declared obscured by
handleNotObscuredLocked().
Bug 7396404 fixed.
Change-Id: Ic59150964d3950e29b115da5f6c0f07a64190d44
Many media files and source code files were marked as executable in Git.
Remove those.
Also a shell script and python script were not marked as executable.
Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
This adds a means of determining when the device is in safe mode,
as required by keyguard to disabled some features.
Change-Id: I31d357e6738c92e1837f9e0263e5f3f4de66315a
The gnarly stuff where we keep track of the old input method
window as if it was still there was sitting around leaving things
in a stuck state. Now we clear this out at key points in the
window manager (freezing screen, user change), and the input
method manager service is less aggressive about asking the window
manager to do it.
Also fixed a problem that was causing flickers during some
wallpaper transitions -- when we are animating two things on
top of the wallpaper and one of them disappears, we need to
make sure the wallpaper target points to whatever the current
target should be (if any), not left pointing to the old target
that has gone away.
Change-Id: I2fb9600f569a5bd5e3528aaf24cde9340af56cb0
...lockscreen sometimes and remains black / blank
The problem was that we were using the animation-side wallpaper state
in cases where it was not updated yet.
The mWallpaperTarget variable is propagated over to the animation
side when the main window manager state updates. On the animation
side, this is used by hideWallpapersLocked() to determine if the
current wallpaper should be hidden.
The problem is that various paths to hideWallpapersLocked() can
come from the layout side of the window manager instead of the
animation side. This causes the problem here because in this case
the wallpaper state may not have yet been propagated to the
animation side, so it could incorrectly decide to hide the wallpaper
because it thinks there is not a target when in fact a target is
set in the layout side. This won't get fixed until some time way
later that the layout side decides that a new window is being shown
that may need to have the wallpaper shown.
The fix here is pretty gross, but as safe as possible -- the
hideWallpapersLocked() function now uses either the animation or
layout wallpaper state depending on where the call to it is coming
from.
Change-Id: I9250bfeae6e11c1761760bcc696fdb33fb5c8a5f
...background for lockscreen sometimes and remains black / blank
There was a bunch of state not being put into the dumpsys output.
In particular, the current wallpaper target of the WindowAnimator
was not being included. I think the problem is that these targets
are not being updated from the main window manager state at some
point where they need to be.
Change-Id: Ic795047f6aea9b6f72d5550bccc9f8d76c6ecb67
A fix yesterday for #7428221 caused a regression where new orientations would
sometimes cause a flash through black on the way to seeing the real static wallpaper.
There is a fundamental problem in WindowManagerService where we show a window before
it has all of the layout/sizing information it needs, which is the cause of the black
flash. The regression yesterday was that we are now less aggressive about layout out
hidden windows, so we won't layout the window until after the window is shown with the
incorrect sizing info.
The fix/workaround is to back off the layout logic specifically for the wallpaper,
ensuring that we will lay it out on orientation changes, even when hidden. This means that
when we finally do show it, it will already have been drawn in the correct orientation/size.
Issue #7444971 Home jank regression
Change-Id: Ib20fdabc43ece9720b261bf04b272c5511e2d902
A recent change in WindowManager made background windows perform layout
(when they should really be left alone). This resulted in artifacts
where rotating the device and then going to a backgrojnd activity (launcher,
Recents) would briefly show that activity in the wrong size/orientation, then
flash to the correct one after a proper layout.
This fix is a simple workaround, leaving in the original fix that the code
change addressed (for keyguard orientation changes), while going back to the
previous (don't layout gone windows) for all other cases.
Issue #7428221 sometimes recents is drawn off-center and then fixes itself
Change-Id: I41b47933c2bd86f29133853d3387bb7294be8f48
Widgets that did not launch Activitys would not display the unlock
screens when they were tapped. Now any window that is shown with
FLAG_DISMISS_KEYGUARD set while the keyguard is locked will
cause the unlock screen to be displayed.
Bug: 7301530 fixed.
Change-Id: I90d11b52d2b63260bdb5f2b6eb7e98eb7a4d9331
...for lockscreen sometimes and remains black / blank
Add some debug output to try to track down what is going on.
Change-Id: I98a96c5da9c04b988e948f6fc2766d927db49ebf
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
