The behavior of mLinkUp has previously changed so that it only
represents the link state. This changes fixes
interfaceLinkStateChanged() so that it triggers a reconnect based
only on the present link state.
Change-Id: I950e04e1f5b5019d59d3b9530f369f8b8f13134a
Signed-off-by: Adam Hampson <ahampson@google.com>
The system process has no ApplicationContext and consequently was
returning null. Use the base Context in these cases.
Bug 7673699 fixed.
Change-Id: Ie2ab856bb0baefff44775a12bef7802320f72656
If you install a lockscreen widget app on a secondary user, lockscreen fails to find it.
There were several places where the correct context and userId were required under the
covers - AppWidgetHost, AppWidgetHostView and RemoteViewsAdapter.
Set the user id in the required places and use it to query the package information.
Bug: 7662835
Change-Id: Ife482c8ab2a2e601650b7cfe2660e88d3b8f2050
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
Bug: 7660973
RemoteViewsAdapter will now store the userId as part of the cache key
when caching remote views to optimize for orientation changes.
Change-Id: I7c4e52b3995d4f56ebfa35aa9516327e182ad892
