am: cfb4721
* commit 'cfb472112dfac835950b4c53fdf921c569388114':
More work on issue #26390151: Add new JobScheduler API...
Change-Id: Idd203c9daba08a3498c8184028554d5136101085
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
am: 80d57ef
* commit '80d57efd94b7c394a39f78a2425d82aed5c75485':
Chaning LauncherActivityInfo to return a density specific non-badged icon
Change-Id: Idda2dec39ecb821578ba213b4046e5210a6bfe63
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
am: acc9468
* commit 'acc9468e3324046f6d7ce06de9a3d19e16849ba1':
Moving app process logging from AMS to PMS
Change-Id: I9dcd57ee35a3102b9e13bde64f24f56991dd2620
- 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
