Certain operations, such as clearing/destroying app data, or just
counting on-disk size, require us to know the CE storage directory
of a particular app. To facilitate these operations, offer a method
to get the inode of a CE directory, and accept that inode number
for later operations. Collect and store the inode number in
PackageUserState for future use when that user's CE storage is
still locked. This design means it's safe to clear/destroy app
data in both CE/DE storage at the same time.
Move most installd-related methods to a uniform calling convention
that accepts a single parent PackageParser.Package, and internally
fans out to handle all "leaf" packages under that parent.
In previous releases, we started installing apps using a new
directory-based layout, where all app code, unpacked native libraries,
and optimized code is bundled together. So now we only have a single
path to measure for code size. This fixes several outstanding bugs
that were causing sizes to be miscounted for apps supporting multiple
architectures.
Fix a subtle bug in PackageSettings that would cause "notLaunched"
to be parsed incorrectly.
Bug: 27828915, 27197819
Change-Id: Ia582cf3550553292bde4bb4313367111332913ec
Let apps invoking the system chooser specify components to filter out
such as themselves; this will prevent duplicate nonsensical UX where
it doesn't make sense for an app to share to itself.
Similarly, let apps provide their own Direct Share targets for when
they do want to let users share via their own internal services in the
same UI. These options can be used together.
Also fix a bug where a lingering binder reference from a remote
ChooserTargetService that hasn't been GC'd in the remote process could
keep an active reference to a ChooserActivity instance.
Bug 28073484
Change-Id: Ib613b1153b49dfedf79574b1af7c45379eceec24
During package installation, we were parsing the APK twice; once
in the context of the PackageInstaller and once in the context
of the PackageManager. Instead, the installer should just pass
the certificates to be used further in the process.
If the PackageManager doesn't receive certificates [or, if there's
an error using them], it will fallback to re-parsing the APK.
Bug: 27502465
Change-Id: I94ce551af54eaa9916228e933134debe50867d21
This clarifies the usage of setPriority() for receiver filters.
Should also adjust the XML description of android:priority to
better describe the new behaviour for activity filters
Bug: 26417683
Change-Id: I96b2d90d71640041e232c401cf6e6838dbdbfeab
Tracing for cert collection in PackageManagerService was only
catching one of a couple usages. Move tracing lower in the
call stack to ensure tracing exists for all calls.
Also added a new tag to differentiate between verifying v1 & v2
signatures.
Bug: 27502465
Change-Id: Ie29f326e44f32cdbea1572714689c82f07ca12ba
...for monitoring content providers
- Improve media provider change reporting so that observers can
avoid spurious reports of the top-level content directory changing.
- Fix a bug where collected content changes while a job was running
were not being properly propagated to the next job.
Change-Id: I29e3c2960e6fec75b16ee3ee6588d47342bf8c75
The real solution is to use ContextCompat, but we can't reference support
library from framework. C'est la vie.
Bug: 27727320
Change-Id: Ib9bcd5f2bdce1996f02fd44877df9ba202b26edc
There are now three rules that guard intent filter priorities:
1) Only privileged applications will be granted a >0 priority
filter [previously, _all_ system applications could do this]
2) There are certain actions that are considered protected [eg
ACTION_VIEW, ACTION_SEND, ...] and even privileged applications
will NOT be granted a >0 priority filter. There is one, and
only one, exception for the SetupWizard.
3) Updates will NOT be granted a priority greater than the priority
defined on the system image.
Bug: 27450489
Change-Id: Ifcec4d7a59e684331399abc41eea1bd6876155a4
Adds PROTECTION_LEVEL_SETUP, a privileged permission for use only by
the setup wizard.
Bug: 20016740
Change-Id: Ib95e349c54d5d12465bf43162975dfb628ef2434
Generally we return info for the latest installed package; which could
either be a built-in [i.e. on the /system partition] package or a user
updated package. In certain circumstances, we want to be able to get
the version on the /system partition regardless of whether or not the
user has updated it. We do this by passing MATCH_FACTORY_ONLY to
getPackageInfo().
Bug: 27469181
Change-Id: I8dd1d110e2d72e5c6f024812d0b5d15d8b217347
Remove some Context methods that leaked through. Add lint rule to
recommend using List<? extends Parcelable> instead of Parcelable[].
Bug: 27932224, 27930145, 27932911
Change-Id: Ia302de46cdb0c5101fa175a09316df91aeefcf0d
This patch moves the updating of packages before performing fstrim,
which runs asynchronously anyway, and stops showing the UI dialog.
Bug: 27350503
Change-Id: I6fceda10d7696f9badb97978fb9dc7927d698a4b
- Pinned shortcuts need to know not only which package
has pinned them, but also on which user's, due to work profile.
- Launcher can always launch shortcuts that it has pinned.
Bug 27548047
Change-Id: I23b4e7dfbb6ecc42099d31008bcfd61d44e2c7fb
Adds documentation, renames Layout to WindowLayout and
splits #minimalSize to #minimalWidth and #minimalHeight.
Bug: 27528326
Change-Id: Idb440cb081a14ccdc83309284e906454633c4504
Now that CE data isn't available until after a user is unlocked, we
need to delay the PRE_BOOT_COMPLETED broadcasts. This is done by
adding a new RUNNING_UNLOCKING user state to the UserController
lifecycle.
We now track the last fingerprint a user was logged in under, and we
dispatch PRE_BOOT receivers when that fingerprint changes. To work
around battery pull issues, we only persist the updated fingerprint
once all PRE_BOOT receivers have finished. This is less granular
than the original solution, but it's still correct. We only consider
a user as "logged in" once it transitions into the RUNNING_UNLOCKED
state.
When starting a process, track if the user was "unlocked" when
started, so that we only spin up unaware providers in processes
started before user unlock.
Add generic IProgressListener to communicate PRE_BOOT progress and
strings up to lock screen. For now, LockSettingsService just blocks
until finished, but it could display these strings in the future.
Bug: 27220885
Change-Id: I349439776b885acd32f6a578d8951ffd95640be2
The current build process may currently strip APK Signature Scheme v2
signatures from prebuilt APKs to be installed on the system or vendor
partitions. However, it leaves intact the signature scheme rollback
protections introduced by APK Signature Scheme v2. Due to a bug, when
the system extracts signer certificates from preinstalled APKs, it
encounters the rollback protection and aborts the extraction process.
This manifests itself as some preinstalled packages not appearing as
installed.
This change makes the system ignore signature scheme rollback
protections when extracting certificates from preinstalled APKs. This
is fine because the process of extracting certificates from
preinstalled APKs does not care about validity/integrity of signatures
and the APKs. It only cares about extracting signer certificates.
Bug: 27829513
Change-Id: I3bed463e776b057e93a0fce915db4014946be1f9
Introduce a mapping between dexopt reasons and compiler filters. Use
reasons in package manager and other classes, where possible.
Change PackageDexOptimizer to accept a compilation filter. Adapt for
the split-out profile merging. Pass compilation filter to installd.
Bug: 27689078
Change-Id: I8c0ea6f10fbfdbd096adecc52abfd2466d048fdc
Don't set a name for the system user and always return a localized
name until the user explicitly sets a name.
Bug: 27814125
Change-Id: I7972a45d77c07d9efbd67d5b360bacee46247a66
