* While parsing the packages.xml file, don't call getPackagesLPw(); we'll
never find a package unless something has gone horribly wrong. Instead,
build the PackageSetting like a sane person and add it to internal
structures.
* Add methods to create a proper copy of the PackageSetting object and
not just the data from one class in the middle of the hierarchy.
* Stop converting Sets into Lists back into Sets when creating
IntentFilterVerificationInfo objects
* Remove the name argument when adding a package setting; it should always
be the name in the package setting
Bug: 30219944
Change-Id: I7fa2c540621fb5d70a59b15919bfd31d8465e25d
When fetching system services early during boot, if the underlying
binder interface hasn't been published yet, we end up caching a
manager class that is broken for the remainder of the process
lifetime, and innocent downstream callers end up using the broken
cached manager.
Fix this by using an explicit exception to quickly abort manager
creation when the underlying binder is missing. The exception is
only used to skip the remainder of the manager creation, and it
doesn't actually crash the process.
Bug: 28634953
Change-Id: I0cb62261e6d6833660704b93a11185aa11a2ac97
Simply getting package settings could changes stored state. Break out
the majority of the method to modify local variables and not change
any stored state. The top-level getPackageLPw() method will still
mutate stored state. This will be changed in a future CL.
Also add a set of tests to verify the behaviour of updatePackageSetting()
Bug: 30219944
Change-Id: I3360a36ce238e816246ee8ca7ecabfbbcdf0b89d
System content providers like SettingsProvider run as singleUser but
on receipt of a call make decisions based on the calling user ID.
This is right up until the caller is a system service or a cross-user-
-aware app like Settings, where putStringForUser etc. provide a
workaround for most settings but not for the few files SettingsProvider
exposes.
Change-Id: I90060c9c13e274edd71f8a16ab3a026a58b98e3e
The previous patch (ef23bf19 Allow leading slash in path...) made
a single slash path unmatchable.
To solve it, this patch stops removing a slash character if the path
only has a slash character.
Now, a single slash is a matchable path for a URI without path string.
Bug: 29524484
Change-Id: I90b357aa48be1a3e0cf36e75ed2a9d6532908972
In the new design, the ephemeral installer can be returned from
queryIntentActivities which means any intent resolution could potentially
return the installer. Additionally, the new design calls for a platform
defined broadcast receiver that receives the status from the ephemeral
installer. This receiver then starts the final intent -- either to launch
the ephemeral application or to launch the fallback.
For more detail, see go/ephemeral-design
Change-Id: I6644bbb4f180d2d22c63af04b9857577516344a9
- More unit tests
- LauncherApps.startShortcut() now supports sourceBounds
(again)
- Updated the javadoc.
Bug 30218829
Change-Id: Iae208ffd4911d149246ccfd0c4380544c2aafffc
