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
createPackageContextAsUser shortcuts creating the context for
system and android packages, however it should still make sure
the ApplicationInfo for the package is for the correct user.
Bug: 17002733
Change-Id: Ie10008449f13a4464a9797937c4413d6aa119fbe
Bug 15863001
Bug 17289526
Changed SharedElementListener to SharedElementCallback
Renamed methods to use "on" prefix.
Adjusted javadoc to reflect usage in Fragments.
Change-Id: I7cc517c269a8e417cb5c3a0948bdd3b654d42472
A few protected => public changes and picking up another change
in ViewAnimationUtils that got missed.
Fixes bug 17389511.
Change-Id: I75027535eade6427c2d9067369426297c168e77e
Fix RemoteViews so that it loads resources from
user that created the RemoteViews but inflates
for the user applying the RemoteViews.
Fix Notification to rebuild RemoteViews with
same ApplicationInfo as original app.
Bug: 17302505
Change-Id: I39f21eef83d63e9e494ea35818e1eb969edd38d7
This reverts commit 5287e37687f117ac0b690100ad90842eff58d15a.
Reverting because only worked if settings cache had been populated
already.
Bug: 17302505
Change-Id: I4360606e9d9c6409951f0a02bd0b78c55085e0c6
Settings are stored by NotificationManagerService in the policy file,
and are communicated to NotificationListeners via a hidden API on the
RankingMap object.
Bug: 16324353
Change-Id: I2d5cf6782273744cbf9b309dec76780cc0a4c39e
Remote views may be inflated in another user so
explicitly use processes user id rather than the
user id of the context.
Bug: 17302505
Change-Id: I985c91745f03dd7e6b2ab6357600077664d8e6be
The isGrayscale family of methods is designed to identify
drawables and bitmaps that apps are using in the largeIcon
position to pose as small icons in order to get the
appropriate background treatment (a solid blue or gray block
in KK/JB, or geniune selvedge denim in ICS/HC).
We can optimize this search two ways:
(1) Reject immediately any largeIcon that is larger than
largeIcons should be (64x64dp). We could one day simply
reject, or resize, these in the notification manager,
but regardless these are not plausible smallIcon
subsitutes. This new constraint is commemorated in the
new name, isGrayscaleIcon().
(2) Shrink the bitmap even smaller before scanning it slowly
in Java. This lets native_drawBitmap do the heavy
lifting across the entire bitmap; we need only scan a
few pixels.
Bug: 16513124
Change-Id: I3a2b79130ed2465a4aedfbb5a556db7f8a7aa132
