An earlier fix made it possible to call requestLayout() during layout
(which is not recommended in most cases outside of a ListView) without
ending up with blank content and internal layout flags in a confused state.
However, that fix incorrectly detected a problem in some cases (such as
ListView practices of adding views during layout) which were actually okay;
as long as you make sure to measure and layout your children properly
before returning from layout(), then it's not a problem. We were improperly
spamming the log with supposed problems, and causing more overhead in correct
cases by running a full request/measure/layout pass after the first layout
pass, all of which is unnecessary in cases where the containers know what
they're doing.
This new fix changes the logic to only cause the second layout pass (and third,
posted to the next frame, if things are really done incorrectly) if the layout-request
flags are still set on the requesting views after the full layout pass is complete.
This situation causes the blank screens we've seen in buggy apps, and is exactly
what we should avoid. However, correct cases (e.g., ListView) will not have these
problems because they run measure/layout correctly after the request calls, which
clears these flags. The upshot is that buggy cases will be detected and compensated for
(by clearing the flags and then running a second request/measure/layout pass, as in the
original fix) and non-buggy cases will be noop'd, going back to their previous, working
logic flow.
The bug below is one of the buggy apps to demonstrate this problem. I noticed that the
original problem (blank screen) is no longer reproducible. I suspect that logic was
added to the app to force a refresh after it is attached. You can still detect the problem
(and the fix) by seeing that prior to the fix (say, on mr1.1) there is a delay of about
a second between the end of the progress bar updates and the showing of content on a
screen that used to just remain blank. With the fix (both the previous version and this
one), the content is updated immediately, because we now handle the buggy request-
during-layout situation in the same frame as it occurs.
Issue #6914123 News and Weather app sometimes loads to a blank screen
Change-Id: I4c34817cc3dd44ba422ff50de4321624c0824d83
1. This patch takes care of the case where a magnified window is covering an unmagnigied
one. One example is a dialog that covers the IME window.
bug:7634430
2. Ensuring that the UI automator tool can connect and correctly dump the screen.
bug:7694696
3. Removed the partial implementation for multi display magnification. It adds
unnecessary complexity since it cannot be implemented without support for
input from multiple screens. We will revisit when necessary.
4. Moved the magnified border window as a surface in the window manager.
5. Moved the mediator APIs on the window manager and the policy methods on the
WindowManagerPolicy.
6. Implemented batch event processing for the accessibility input filter.
Change-Id: I4ebf68b94fb07201e124794f69611ece388ec116
All three of these are interrelated!
* Allow broken MeasureSpec values. The long-standing implementation
of MeasureSpec.makeMeasureSpec has been to add both values rather
than masking/or-ing the values together. Some old code relied on
this, such as if it mixed up size/mode params.
* Disable ImageView adjustViewBounds allowing the view to grow beyond
its initial size. A bug in RelativeLayout in the presence of the
above MeasureSpec fix causes this not to work properly in apps.
* Allow RelativeLayout to send overflowed/bogus MeasureSpec values
when measured with MeasureSpec.UNSPECIFIED mode. Some apps have
custom child views that do not properly handle UNSPECIFIED
measurements, but the exact overflow semantics caused this to
generate AT_MOST $REALLYBIG MeasureSpecs for those views instead if
they were placed inside a RelativeLayout in a scrolling container.
Change-Id: I977a5f1ba5637f0cba3d26a70139e2bcd021fc9c
RecentsActivity screenshots are called for very quickly after
WindowStateAnimator prepareSurface(). Without enough delay the
Surface.setLayer call does not propagate to the SurfaceFlinger
and the screenshot is incorrect (black) because it stops sampling
the layers too early.
This fix calls Surface.setSize() for each sampled Surface in
screenshots. setSize forces the SurfaceFlinger to process all
transactions queued before returning from closeTransaction.
Bug 7552304 fixed.
Change-Id: I1911dfa0b09cab713c55f5ba0c612496337a77df
Conflicts:
services/java/com/android/server/wm/WindowManagerService.java
Improves the throughput of IME event handling by ensuring that
input events do not get serialized behind UI traversal and
drawing messages such as when the UI is animating.
Added support for creating an asynchronous Handler as part of a
HandlerCaller. It turns out we should be using an asynchronous
Handler not only in IME dispatch but also in accessibility and
wallpaper events where HandlerCaller is used. So fixed those
services to also use an asynchronous Handler.
Change-Id: I0b19140c9d5ca6ee300c1a150c48312fd55ed8eb
Fixes the following problems with safe headphone volume warning message:
- Do not display the warning dialog when screen is off.
- Use the same 3 second timeout as for the volume slider to dismiss the dialog.
- Do not dismiss the warning dialog when touching outside of the slider window
but inside the warning window.
- Disable the volume slider when the warning message is displayed.
- When setting volume directly (touching the volume slider), and the warning
is displayed, save the requested volume and apply it if acknowledged by the user.
- Do not display the warning message when restoring safe volume after 20h of
cumulative listenening
Bug 7658641.
Change-Id: Ib3d1315193a433dad918aa5df78fa071062b2394
Process mode functor execution can be expensive, and cause dropped frames if it
runs between two expensive frames (when there isn't cpu time to spare). Avoid
this by delaying the process mode by an additional 4 ms every time we hit a draw
bug:7670326
Change-Id: I27f42458d4a815183a4b24c7748e05bc361fb943
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
Apps detaching/attaching large subtrees would waste a few milliseconds
dealing with dirty display lists. This change removes the need to do
ArrayList.remove() on every detachedFromWindow().
Change-Id: Icee72516c40d48ff0fd9d6f3128589f99bf61428
Sometimes a client needs to hold onto an accessibility node info and
this info may get into a stale state. The clent has to be able to
request a refresh of the info. This change adds a refresh call to
AccessibilityNodeInfo.
bug:6711796
Change-Id: I580a9a5d9fd1f705ea0a2cf4d3ff65543714c9c3
There are two things going on here:
(1) In secondary users, some times theme information such as whether
the window is full screen opaque was not being retrieved, so the window
manager didn't know that it could hide the windows behind the app.
This would just be a performance problem, except that:
(2) There appear to be a number of applications that declare that they
are full screen opaque, when in fact they are not. Instead they are
using window surfaces with an alpha channel, and setting some pixels
in their window to a non-opaque alpha level. This will allow you to
see whatever is behind the app. If the system happens to completely
remove the windows behind the app, and somebody is filling the frame
buffer with black, then you will see what the app intends -- those
parts of its UI blended with black. If one of those cases doesn't
hold (and though we have never guaranteed they would, in practice this
is generally what happens), then you will see something else.
At any rate, if nothing else than for performance reasons, we need to
fix issue #1.
It turns out what is happening here is that the AttributeCache used
by the activity manager and window manager to retreive theme and other
information about applications has not yet been updated for multi-user.
One of the things we retrieve from this is the theme information telling
the window manager whether an application's window should be treated
as full screen opaque, allowing it to hide any windows behind it. In
the current implementation, the AttributeCache always retrieves this
information about the application as the primary user (user 0).
So, if you have an application that is installed on a secondary user but
not installed on the primary user, when the AttributeCache tries to retrieve
the requested information for it, then from the perspective of the primary user
it considers the application not installed, and is not able to retrieve that
info.
The change here makes AttributeCache multi-user aware, keeping all of its
data separately per-user, and requiring that callers now provide the user
they want to retrieve information for. Activity manager and window manager
are updated to be able to pass in the user when needed. This required some
fiddling of the window manager to have that information available -- in
particular it needs to be associated with the AppWindowToken.
Change-Id: I4b50b4b3a41bab9d4689e61f3584778e451343c8
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
An earlier fix to allow requestLayout() to be called during layout
didn't handle some of the requests properly, leaving some nodes
stranded with layout requests that didn't propagate all the way
up the hierarchy. The fix is to do, on the second layout pass, exactly
what we do in a normal layout pass: run measure, then layout.
Issue #7657033 Checkboxes not being updated immediately in Settings
Change-Id: I90be3992d3441e8f43629d26c8386c81a7c31482
1. Removed the support for infinite pool size which nobody was using and
does not make sense.
2. Update some classes in ViewGroup to use the poolable APIs.
Change-Id: Ifdb8c10968cd06fe53085ec9d3d649f7c9a944b7
