Activity.setImmersive(boolean) / android:immersive="bool" are now public.
In addition, if the foreground activity is immersive then an update lock
will be held on its behalf. This lets applications such as movie players
suppress the display of intrusive notifications, OTA-availability dialogs,
and the like while they are displaying content that ought not to be
rudely interrupted.
The update lock aspect of this mode is *advisory*, not binding -- the
update mechanism is not actually constrained; it simply uses this information
in deciding whether/when to prompt the user. It's more a guideline than
a rule.
Bug 7681380
Change-Id: I3c412a84cbf3933e3bf0168f2c71c54a86e4b7e5
To minimize fix size, return only valid dreams from the service api.
Settings will "just work" with no changes.
Bug:7699398
Change-Id: I3eb88237a8ccc421fdb68d1de19820614b13d7b8
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
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
The actual handling occurs in updateScreenOn() on the other side of a
handler, which acquires the lock correctly.
Change-Id: Ibd359446dba8e88f81d34f1e10a6b5e150348f89
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
