When updating the RegisteredServicesCache, don't remove any packages
that are not in the list of modified packages.
Bug: 19228972
Change-Id: Id4f264403b7ceca9005854dfbbc25abfd7b54889
Issue #18983662: API Reivew: clarify Intent docs for URI_ANDROID_APP_SCHEME
Issue #19019830: Bump up battery stats checkin version
Change-Id: I0bd8f32b9d8d5978bd01d421ea2232d20def340a
This prevents our lint tooling from complaining that we're passing
invalid values when trying to get the MediaProjectionManager.
Bug: 18830590
Change-Id: I34633248e895b0ac7f5083e18a7d2385ca6f8adb
...testCallActivityOnNewIntent test fails with LMP-MR1 Release.
Check for null.
Also fix some small issues with converting intents to/from intents.
Change-Id: Ic391cc57552635935af9a271b2d09353257f6d14
This reverts commit 6aee1d2ba5.
But leaves in some of the improved documentation.
Bug: 18281970
Bug: 18573576
Change-Id: I320f2229456ac039bc8f3cd8bc8b4ea6cf0e80eb
...is installed with <provider> with empty string.
Don't allow empty authorities, just like we don't allow null authorities.
Change-Id: I5c64592a639efe4dba848bd6f0efe4257f1565a2
This is a landmine for developers. If they need to obtain an unthemed
drawable, they should be using an explicit null theme.
BUG: 18579576
Change-Id: Ibca6b4c3e8e50dca144571244e035caec6fa91f8
Apps delivered as multiple split APKs must have identical package
names, version code, and signatures. However, developers may want
to iterate quickly on a subset of splits without having to increment
the version code, which would require delivery of the entire app.
This change introduces "revision codes" which can vary between
split APKs belonging to the same app. An install is valid as long
as the normal version code is identical across all splits. Splits
can be added/removed to an app over time, but if a split is present
across an upgrade the revision code must not decrease.
Since system apps could have been updated with splits, only revert
to the built-in APKs if the version code is strictly greater than the
data version. Also fix bug to enable inheriting from system apps
when adding splits.
Bug: 18481866
Change-Id: I34d8e14c141a8eb95c33ffe24b4e52d6af5c8260
The animation scaled was not being factored in early enough in the
activity lifecycle. Also, setCurrentPlaytTime() was not accounting for
the scaled duration correctly. Finally, added setCurrentFraction() as
a more general-purpose seeking facility.
Issue #18222006 Animator duration scale ignored in some situations
Issue #17951668 add ability to seek fraction, not just time
Change-Id: Idad401f5ff5026d7046c36eee09d78a4793215dc
All but a few lines of this is for issue #16013164, which allowed
apps to do some operations as the media uid by having it call
back to them to open a file. The problem here is with the tempory
identity stuff in the activity manager, allowing us to make the open
call as the original caller... ideally we should figure out a way
to just get rid of all of that, but the solution here is actually
easier (even though it doesn't look it) -- we now hand a token over
to the openFile() call that it can use when doing permission checks
to say "yes I would like the check to be against whoever is responsible
for the open". This allows us to do the uid remapping for only this
one specific set of permission checks, and nothing else.
Also fix issue #17487348: Isolated services can access system services
they shouldn't be able to. Don't send any system service IBinder objects
down for the first initialization of an isolated process.
Change-Id: I3c70e16e0899d7eef0bae458e83958b41ed2b75e
It seems we were sort of trying to do this by forcing the AsyncTask
static initializer to run at certain times but it was not sufficiently
reliable. In particular, this resulted in occasional system
server crashes.
Bug: 18192406
Change-Id: Ief73210c60e7680fbed6df74e3e58809b7ec7e4d
There was a window of time in Lollipop where we persisted certificates
after they had passed through a decode/encode cycle. The well-written
OpenSSL library was liberal when decoding (allowing slightly malformed
certs to be parsed), but then strict when encoding, giving us
different bytes for effectively the same certificate.
A related libcore change (0c990ab4a90b8a5492a67b2b728ac9a4a1ccfa1b)
now returns the original bytes verbatim, fixing both pre-Lollipop
installs and installs after that change.
This change recovers any apps that had been installed during the
window of time described above by doing a one-time check to see if
the certs are effectively equal.
Bug: 18228011
Change-Id: Ib82bd6db718d0490d7a26c9c1014b7c8457a7f2d
Also fixes dialog padding in landscape mode and a bug in the
ColorStateList method used to apply a selected color.
BUG: 18251582
Change-Id: Id5b8c7893ec42fd4d5f4a7520e6ac170839d3143
This expands the use of EXTRA_REFERRER to be relevant anywhere,
allowing apps to supply referrer information if they want. However,
if they don't explicitly supply it, then the platform now keeps
track of package names that go with Intents when delivering them
to apps, which it can be returned as the default value.
The new method Activity.getReferrer() is used to retrieve this
referrer information. It knows about EXTRA_REFERRER, it can return
the default package name tracked internally, and it also can return
a new EXTRA_REFERRER_NAME if that exists. The latter is needed
because we can't use EXTRA_REFERRER in some cases since it is a Uri,
and things like #Intent; URI extras can only generate primitive type
extras. We really need to support this syntax for referrers, so we
need to have this additional extra field as an option.
When a referrer is to a native app, we are adopting the android-app
scheme. Since we are doing this, Intent's URI creation and parsing
now supports this scheme, and we improve its syntax to be able to build
intents with custom actions and stuff, instead of being all hung up
on custom schemes.
While doing this, fixed a problem when parsing both intent: and new
android-app: schemes with a selector portion, where we were not
respecting any scheme that was specified.
Change-Id: I06e55221e21a8156c1d6ac755a254fea386917a2
Fake the Uri for grant check, if we're checking access to
a singleUser provider. Inject the userId in the authority
so that the grant can be matched properly.
Bug: 18194892
Change-Id: I4a55ce593ac21722f394e89e13350aa205d76336
When we fix uris by adding the user id they belong to, the extras
of the intent are unpacked and repacked. This must not happen
inside the system process. It happened when ResolverActivity was
handling an activity intent coming from a different user.
BUG:18198630
Change-Id: I869897013bb2e5522584b404e87a8f20e7943b60
