Android wear emulators have never had support for enabling both gpu
emulation and also having a round clip overlay present. Fix this by
supporting a drawable overlay when the ro.emulator.circular system
property is set.
Bug: 13415409
Change-Id: I6e0840ebe5c77adb786a7ba7ec6af348308ca46a
Issue #17394151: WallpaperService / Engines need to get notified
of WindowInsets
Issue #17394203 Wallpapers need a system API to be shifted in order
to support burn in protection
Adds a new API on WallpaperManager to set additional offsets to
make wallpapers extend beyond the display size.
Insets are now reported to wallpapers, to use as they may. This
includes information about the above offsets, so they can place
their content within the visible area. And to help with this, also
expose the stable offsets APIs in WindowInsets which is also very
useful information for the wallpaper.
Another new API on WallpaperManager to set a raw offset to apply
to the wallpaper window, forcing it to move on the screen regardless
of what the wallpaper is drawing.
Fix wallpapers when used with overscan enabled, so they still extend
out across the entire screen. Conveniently, the above new window
insets information is very useful for this case as well!
And a new wallpaper test app for all this stuff.
Change-Id: I287ee36581283dd34607609fcd3170d99d120d8e
When deriving AudioAttributes from a Notification instance,
and having to use the legacy stream type field, make sure
it has a valid value, or use the default notification
attributes.
Bug 17408227
Change-Id: Icd1a122b33b8eceb1f6a177699885b0fb8a99b7c
For restore use-case, session creation needs to complete quickly, so
delay ASEC allocation until session is opened. When preflighting
size checks, only consider external when we have a known size for the
container. Also relax size checks when using MODE_INHERIT_EXISTING
on external, since we don't know how much of existing app will be
copied over.
Consider session as "active" while commit is ongoing, until we're
either finished or pending user interaction.
Always publish first client needle movement away from 0. Use 25% of
internal progress to reflect ASEC allocation.
Avoid CloseGuard messages about leaking PFDs.
Bug: 17405741, 17402982
Change-Id: I6247a1d335d26621549c701c4c4575a8d16ef8c2
In touch exploration mode an accessibility service can move
accessibility focus in response to user gestures. In this case
when the user double-taps the system is sending down and up
events at the center of the acessibility focused view. This
works fine until the clicked view's center is covered by another
clickable view. In such a scenario the user thinks he is clicking
on one view but the click is handled by another. Terrible.
This change solves the problem of clicking on the wrong view
and also solves the problem of clicking on the wrong window.
The key idea is that when the system detects a double tap or
a double tap and hold it asks the accessibility focused node
(if such) to compute a point at which a click can be performed.
In respinse to that the node is asking the source view to
compute this.
If a view is partially covered by siblings or siblings of
predecessors that are clickable, the click point will be
properly computed to ensure the click occurs on the desired
view. The click point is also bounded in the interactive
part of the host window.
The current approach has rare edge cases that may produce false
positives or false negatives. For example, a portion of the
view may be covered by an interactive descendant of a
predecessor, which we do not compute (we check only siblings of
predecessors). Also a view may be handling raw touch events
instead of registering click listeners, which we cannot compute.
Despite these limitations this approach will work most of the
time and it is a huge improvement over just blindly sending
the down and up events in the center of the view.
Note that the additional computational complexity is incurred
only when the user wants to click on the accessibility focused
view which is very a rare event and this is a good tradeoff.
bug:15696993
Change-Id: I85927a77d6c24f7550b0d5f9f762722a8230830f
When the top activity is finishing we don't want to be comparing
it for matches to launching activities. This was keeping curTop
from matching itself when launching a lower task.
Fixes bug 17383648.
Change-Id: I837ac087ef965d99d12c98ab1c779de46716e204
The requirement that the top app be resumed in order to request
background visibility was too strict. In particular when the
background app is pausing the top app will be stopped waiting for
pause to complete. This is an appropriate time for the background
app to request visibility but we were rejecting that request.
Also, there is no need for the top app to have an active thread
except to notify it of the changed state.
Fixes bug 17383876.
Change-Id: I52f910baf6c109565694e053445516e1e5fd1c48
Surfaces were being modified after destroy(). The check for mSurface
being null was not done while holding window the window manager lock.
This change adds locking to the surface modification methods.
Fixes bug 17383628.
Change-Id: I12ebbddc0f2cd7b43659370fac2c4fb053999bb5
When lingering completes ConnectivityService would log an error message
saying the Network still had NetworkRequests. Fixed by ignoring
listening NetworkRequests which aren't a problem.
Change-Id: Ie78a1f91c47b012eae28a377dd77bee2cfcbde3b
Add a new activity attribute, resumeWhilePausing, that allows an
activity specifying it to immediately start running without waiting
for the previous activity to pause. The recents activity is updated
to use this.
The implementation of this is ultimately fairly simple -- if we are
in the path of resuming such an activity, and find that we first need
to pause the existing activity, then within the activity manager we
do the regular pause flow but act like it has immediately finished
pausing right then so that we can immediately go on to the resume.
To make this clean, we tell the activity when asking it to pause that
it should not come back and tell us it is done, because we aren't in
any way waiting for it.
One potentially important change I needed to make here is the pause
callback no longer provides the saved persistent state, because we
now can't count on that callback happening. I don't think there was
really any utility in this anyway -- all modern apps will have their
save state flow happen as part of stopping, not pausing, so we'll
only capture that saved state when the stop is reported back anyway.
And since we do send the saved state back when stopping, it would
always blow away whatever we had gotten at the pause.
Finally, update the documentation for AppTask.startActivity(), and
fix the implementation handling that to be cleaner -- we need to
deal with inTask first before getting in to "oh noes add NEW_TASK
if this isn't coming from a calling activity" flow.
Change-Id: Ia1da0fac90d7bdbaafdda2e34850d795ce17a39f
Don't restore it too soon, because the rarely-needed fallback path
will need to be executed as system, too.
Bug 17394246
Change-Id: Ic5e662d4eae331b016fc91ffd08647bd8d4d6ff3
Also change name to setStagingProgress() to make it clearer that
system may adjust the range. Start throwing from openSession() in
preparation for ASEC allocation moving.
Bug: 17405741
Change-Id: Id7da51a32d5d89cb512ddafbd7ceaafbcd41cac6
- Avoid writing to disk when querying UsageStats.
- Use new UnixCalendar to avoid issues with Locale and TimeZone.
Bug: 16951313
Change-Id: I2473b8ef8dc1e2f6be22d4c689b96e346bdcafd5
...in cases involving uninstalled apps, or apps whose install state
varies across different users.
Bug 17398315
Change-Id: I7297d82f8bf5d49c50a7fd53d795a706bf2d2313
