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
Cherry-pick I88b419c92940b7e536d48b26e5fc0f72f3c9e73d
This is a more complete solution for this issue that disables
location providers when expiring their last request *and* adjusts
update intervals when expiring any request. This should help
further limit battery drain when a high-frequency-update app
exits, as it allows the system to throttle the update interval
back down to something appropriate for the remaining listeners.
Bug: 7611837
Change-Id: I7629a90f4c693be4bf96d662bd3a8b06dae0b089
Cherry-pick of Id48151eb7de40164258cde7da220a4d6bb34b89a
Location providers were not being notified of the change in status
when the last UpdateRecord was removed due to numUpdates exhaustion
or request expiry. Oops! Enjoy some free battery life!
Bug: 7611837
Change-Id: I66303b355be4e4a56a81efb5406c9353b2588595
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
If your notification is set to MIN priority, it will never
attempt to interrupt the user, either by an icon (already
implemented), or (new in this patch) by LED, vibration, or
sound.
Bug: 7648785
Change-Id: Ia0f8e010e62029d8d8ef1955dd20b7c79fb68398
Implement a timeout between when the dream binds and
when the dream creates the service connection. If
the connection is not created within a certain amount of
time, stop the dream.
This fixes the current bug where a dream that crashes in
onCreate (or the ctor) can put the dream controller in a
bad state until the screen is turned off.
The timeout is equal to the service restart delay in
activity manager (ActiveServices) to avoid restarting
(and recrashing).
Bug:7596707
Change-Id: I3e11efc6af0b79ec4cb0fbc94e4e109c7602ddac
Bug: 7573552
Currently IMMS doesn't receive install/uninstall messages. Accordingly enabled IMEs' list is not refreshed properly.
Change-Id: I25e9798a65f528dd270cd6bb1f14b1d887194787
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
This was initially about the Clock widget crashing repeatedly on some
devices with multiple users. Turned out that there were race conditions
when switching users that could result in remote views of one user calling
back to the RemoteViewsAdapter in keyguard that in turn sent an incorrect widget id
to a different user's widget, resulting in a crash.
Since KeyguardHostView is instantiated in the same process for different users,
it needs to carry a user identity to pass along to AppWidgetService so that
remote views services were bound to the correct user and callbacks were attached and
detached properly.
Added some aidl calls that take the userId to do the binding properly. A more
complete fix might be needed in the future so that all calls from Keyguard carry
the user id.
Also, there was a problem in comparing host uid for secondary users, since Settings
for a secondary user has a different uid than keyguard. Not an issue on single-user
systems. Changed the host.uid comparison to accomodate for the secondary user.
Bug: 7450247
Change-Id: Idbc36e3c60023cac74174f6cb7f2b2130dd3052c
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
...android.os.Parcel.nativeAppendFrom(Native Method)
The failing stack trace is:
11-20 20:29:04.365 19154 19170 E AndroidRuntime: java.lang.IllegalArgumentException
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.nativeAppendFrom(Native Method)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.appendFrom(Parcel.java:428)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1613)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.location.Location.writeToParcel(Location.java:903)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeParcelable(Parcel.java:1254)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeValue(Parcel.java:1173)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeMapInternal(Parcel.java:591)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1619)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.location.Location.writeToParcel(Location.java:903)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeParcelable(Parcel.java:1254)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeValue(Parcel.java:1173)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeMapInternal(Parcel.java:591)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1619)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.content.Intent.writeToParcel(Intent.java:6660)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:763)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:230)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:777)
This is odd because where we do Bundle.writeToParcel(), we are just writing the Parcel
we have with its current length. There is no way this should be able to fail like this...
unless the Bundle is changed while we are running?
Hm.
It looks like the location manager is holding on to Location objects which have a
Bundle of extras. It is that Bundle of extras that the crash is happening on.
And the bundle extras can be changed as it operates. And there are places where
the raw Location object is returned from the location manager, which means the
caller can be olding on to a Location object whose extras can be changed at any
time by other threads in the location manager.
So that seem suspicious.
This change should take care of all these places in the location manager, by
making sure to copy the location object before it goes out of the location
manager.
In addition, add some code to the activity manager to not bring down the entire
system if there is a problem trying to send one of these broadcasts. There is
no need, we can just skip the broadcast as bad.
Change-Id: I3043c1e06f9d2931a367f831b6a970d71b0d0621
