If present, the system property "ro.config.lock_wallpaper" provides a
filesystem path to a decodeable image file to use as the system's
out-of-the-box lock wallpaper imagery. In the absence of this
system property, or if the indicated file is absent or unreadable,
then the new framework resource
com.android.internal.R.drawable.default_lock_wallpaper is consulted to
locate a usable asset. This mechanism parallels the existing one for
the default system wallpaper.
By default there is no specific lock wallpaper asset; the resource is
defined to be @null in the standard config.xml file. A product that
wants to define such a factory-default lock-only wallpaper image
will provide the asset as part of its framework resource overlay.
Bug 27828056
Change-Id: Iebf3706222370d0a0a4baf88d71a59ead07a25c7
Preallocate storage lists and avoid TextUtils and its string
builder for a common code path.
Optimize list join helper to not have a check in the loop.
Bug: 28801010
Change-Id: Iafc582031f973d718252b34bcda6405a77425628
am: 32b54f2e42
* commit '32b54f2e42c4ff793c418c29c0ce9ef0be2a4a16':
Mark occluded home stack as invisible.
Change-Id: Iae4279835f345b2b294acca20760634ba031f0bd
During the PiP animation, we have two basic requirements:
1. We need to scale windows to the pinned stack bounds.
2. We need to halt resize and movement notifications to the client.
As we end the animation, we need to disable these states at differing
times. First we need to deliver a final resize and movement notification
to the client for it's new position. However, Surfaces may not
immediately resize (in particular in the case of child windows,
it may be some time!), furthermore Surfaces may resize at different
times so we need to persist scaling on a Surface by Surface
basis after reenabling resize notifications.
Bug: 28559097
Change-Id: I6d52a3e213e08a34f4c0eea892b2a84cd4c20e18
- The home stack is still visible when a translucent activity (like
dialer) is on top, which caused us to use the logic path that just
tries to launch the next task. However, that path does not reload
the stack state (since the activity stack generally doesn’t change
while Recents is visible) so it was always launching the already top
activity. The new check ensures that we start the activity anew
as if it was coming from an occluding app.
Bug: 28767764
Change-Id: Iec0fdc0957e5070cec532c5de5cba3454c906a3b
am: 718ba309cf
* commit '718ba309cfc9bbc3bbf785bbe5dfc1049ce02d20':
Adjust Notification APIs per API council
Change-Id: I282bb2b6e4718f7b1afb3eb418a8d37deaa457b0
Since LocaleList needs to depend on android.os.Parcelable, we cannot let
that class belong to "android.util" package, which causes layering
violation.
Bug: 28819696
Change-Id: Ia8de2ee9df3dd0a42b1fe84574439519b680fe18
Also fixes a slight bug where a CharSequence extra
was retrieved as a string.
Change-Id: I8a40ab1934b8a20355c3cd4afd66a4a7b91fb517
Fixes: 28775580
Fixes: 28775582
Hiding the APIs for now since we're not releasing freeform yet and it's
better not to expose them now in case we'll decide to change them later.
Bug: 28774476
Change-Id: Ic2de33c5a611a515fc1c72535587ebf2e0a03a7f
There are few paths I can see to get a null intent down into
the framework at this point. Add in some checks and reports
at those places to mitigate and report such problems.
Change-Id: If235bf342558321d3fabe9363fcebb2bcea18df1
- Added ActivityOption to mark a starting activity as a taskOverlay
activity. That is the activity will always be the top activity of the
task and doesn't cause the task to be moved to the front when it is added.
- Only set the starting window state of the ActivityRecord to shown if
window manager actually showed the starting window for the activity.
Avoids incorrectly trying to remove starting window for an activity that
didn't show any.
- When starting additional activity in a task, transfer the starting
window from the top most activity with a starting window. It is possible
the top most window does have a starting window like in the case of the
forcedResized activity.
- Only ensure visiblity of an activity we are starting in a task whose top
activity is a task overlay. They need to start in the visible-paused state
and not the resumed state which just causes extra churn in the system.
- Always add additional starting activities in a task with an overlay
activity below the overlay activity.
Bug: 28751186
Change-Id: I3624a4313ae9c406d42c67a3537f67ad685791af
We don't need to set up JIT profiles and register usage etc when
the package context we're trying to construct doesn't request code.
This will correct accounting for packages which are only used for
resources.
bug: 28519185
Change-Id: I849675efa76c8100ae937de478b52254babe384c
We need to make IIntentSender oneway... but when the system is
calling that for itself, it needs to be able to return a result code.
Solution: instead of directly calling the interface, we have a new
IPC through the activity manager. If the thing being used is the
activity manager impl, it can do the synchronous send and return
the result directly in place. If not, you only get asynchronous
sending and thus never a failure result back (too bad for you!).
Change-Id: I4096e5b00063e8dba66230585a2dfe67e35e8092
