Since this is a backport, there is only one rule that guards intent
filter priorities:
1) Updates will NOT be granted a priority greater than the priority
defined on the system image.
NOTE: I had to bring in pieces of ag/526831 so intent filters could
be collected and matched
Bug: 27450489
Change-Id: Ifcec4d7a59e684331399abc41eea1bd6876155a4
Since this is a backport, there is only one rule that guards intent
filter priorities:
1) Updates will NOT be granted a priority greater than the priority
defined on the system image.
Bug: 27450489
Change-Id: Ifcec4d7a59e684331399abc41eea1bd6876155a4
Since this is a backport, there is only one rule that guards intent
filter priorities:
1) Updates will NOT be granted a priority greater than the priority
defined on the system image.
Bug: 27450489
Change-Id: Ifcec4d7a59e684331399abc41eea1bd6876155a4
BUG:26094635
If the caller to ContentResolver#getCurrentSyncs does not hold the
GET_ACCOUNTS permission, return a SyncInfo object that does not
contain any Account information.
Change-Id: I5628ebe1f56c8e3f784aaf1b3281e6b829d19314
(cherry picked from commit b63057e698)
BUG:26094635
If the caller to ContentResolver#getCurrentSyncs does not hold the
GET_ACCOUNTS permission, return a SyncInfo object that does not
contain any Account information.
Change-Id: I5628ebe1f56c8e3f784aaf1b3281e6b829d19314
(cherry picked from commit b63057e698)
During system boot, we prune app-ops belonging to apps that have
been uninstalled. However, apps installed on adopted storage devices
haven't been scanned at this point, so they appear to be uninstalled.
To avoid pruning app-ops for these apps, we need a getPackageUid()
variant that also considers "uninstalled" apps for which we still
have PackageSetting values.
Bug: 25206071
Change-Id: I1820f674d45c5ddc1c5f10ed7d859e7025005e28
There was a bug causing PackageManager to think apps on adopted media
were actually in an ASEC, causing it to skip ABI derivation. This
change fixes the issue by copying the volume UUID into place early
in the scanning process.
Also fixes two places where we had incorrectly been including apps
on adopted media; switched them to check only for ASECs.
Bug: 24583803
Change-Id: If66d1bce02824a4d8e22f741b04a2abda0378cfb
ActivityInfo was missing initialization for the
documentLaunchMode flag in the copy-constructor
and the Parcel constructor. The copy-constructor
is used in multi-user/profile mode to create a
seperate instance of the ActivityInfo per uid
and this was manifesting in the linked bug.
Bug: 21590916
Change-Id: I6f71d94ec32ec6326d23c9b62e9d8d319e2fa25e
(cherry picked from commit 3e2e011785)
Update storage related docs on Context to be consistent, and to call
out relevant Environment methods. Start calling it "shared" storage,
and only mention external for historical reasons. Mention that there
isn't much benefit to using emulated storage over private data
directories to help guide developers to safer locations.
Point out which paths can change over time, so developers know to
only persist relative paths.
Update Environment docs to reflect how they behave for the new
class of adopted storage devices.
Bug: 24251945
Change-Id: Ie5ab337649b4740dfd7594997bbb19c4969cfd2f
Previously, size of of oat directory was not counted by the getsize command,
because base APK location was passed as apkpath argument.
Bug: 23896047
Change-Id: Ic7b6b725785ff2e2a0cf3887ba68c162b23b1212
...from Camera360 to Hangouts }
In the short URI toString, include a small summary of the ClipData (instead
of just saying it has a clip data). This makes it a lot easier to understand
what is happening when you look at the log of activity starts.
Also separate out the activity manager dump of URI permission grants from
its dump of providers, so it is easy to just look at that state.
Change-Id: I68093d9f279944e1aa9a29347075f237f4f55ed3
..in link-opening behavior. If a candidate is marked as "ask
every time," then the user is guaranteed to get a disambiguation
prompt including that candidate even when some other candidate
app is in the "always prefer this over a browser" state.
Bug 23147746
Change-Id: I904d8697a992b3f16f32b1c1b49c2bf9424c7137
We don't differentiate between null conifguration and
Configuration.EMPTY, but if ResourceKey uses both, it will produce
different hashes and won't be equal. This CL makes ResourceKey always
hold a non null reference to the Configuration object.
We started delivering the configuration overrides in
Ib2c7be0b427f5ce05e7a362bcdd496ddbc9164f0, which changed behavior from
using always null, to using both null and Conifguration.EMPTY for empty
confgiuration. Now we will switch to using only one value, which is
Configuration.EMPTY.
Bug: 22620824
Change-Id: I090fd90ac21a6b3ebc7f2974a91dd7c861af10d7
