This is a direct reimplementation in L of fixes applied to N in
these two commits:
8dc8d37c1de8741d23d2
Bug 19285814
Change-Id: I59bcc8f1d41c426e9da635bea9ad1d7c6756d5aa
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
Disallow existing and newly created guest users from
changing Wifi settings.
BUG: 27411179
TEST: Flashed device, switched to existing guest user, and verified
that Wifi settings are disabled.
TEST: Flashed device, created new guest user, and verified that Wifi
settings are disabled.
Change-Id: Ia1bf4cce0369017b62f69d317c7ab2e30e3949b3
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)
These framework permission strings were being used as arbitrary labels
that mapped to netd permissions that have completely different meaning.
This leads to confusion, so use different strings.
This is being cherry picked from lmp-mr1-dev to lmp-dev to fix failures
when creating restricted networks due to prior back-port a120442.
Bug: 21900139
Bug: 18194858
Change-Id: Ib3ec377ab26ce904d3d4678f04edec6cb1260517
(cherry picked from commit 0f8f120839)
With this change:
1. NOT_RESTRICTED should be removed from NetworkRequests that bring up
special restricted carrier networks (e.g. IMS, FOTA).
2. NetworkRequests without NOT_RESTRICTED require CONNECTIVITY_INTERNAL
permission to register
3. Binding sockets to networks without NOT_RESTRICTED requires
CONNECTIVITY_INTERNAL permission
Bug:21637535
Change-Id: I5991d39facaa6b690e969fe15dcbeec52e918321
(cherry picked from commit 487ffe7d3d)
* Applications must now have ...permission.REAL_GET_TASKS to
be able to get process information for all applications.
* Only the process information for the calling application will be
returned if the app doesn't have the permission.
* Privilages apps will temporarily be able to get process information
for all applications if they don't have the new permission, but have
deprecated ...permission.GET_TASKS.
Bug: 20034603
Change-Id: I67ae9491f65d2280adb6a81593693d499714a216
(cherry picked from commit 9dbaa54f68)
...rather than only during the OS's "time to start the persistent apps"
boot phase. This closes a window of opportunity during which a
persistent app container may be live without having been properly
noted as such, because it wound up being launched prior to the
[rather late] boot phase at which the persistent apps are directly
enumerated and bookkeeping for them established.
Bug 20855725
Change-Id: I41822b412de4540dbdeab300b38089303678f76c
In some cases it is possible for the AppToken.allAppWindows list to
get out of sync with the list of windows known to WMS if the client
doesn't call Session.remove(Window). This can lead to an NPE when
the animation threads runs and the display for the window has been
removed.
Bug: 19972099
Change-Id: Ifdf9ff2364b96757bba0539394c4a682f64577c9
We now make sure, when scanning post-factory app installs, that we do not
accidentally activate a "leaked" or otherwise superfluous APK tree that the
scan algorithm happens to encounter before the one that we expect a priori
based on the persisted package-installation state. When we find such an
extraneous installation we ignore it in favor of the expected one, similarly
to the policy used when collecting system-bundled packages that have been
updated.
Even if we find an unexpected APK for the package, if the expected one
turns out to be absent we fall back to the existing "we thought this app
was present and now it isn't" logic.
Bug 19602471
Change-Id: I141a93661946176c05d8cf52a123bdf75c8eef74
Larger OTAs (750 MB tested) are taking 3-4 minutes
to write, due to the O_SYNC needed to ensure that
the data is actually committed to disk prior to
reboot.
Bug: 18750317
Change-Id: Idfab3ffd0276df4548f69a09c72ad6f4a344b6e6
(cherry picked from commit 01c06dfb07)
Ensures that the playback device turns on display output signal
upon receiving CEC command <User Control Pressed>.
Bug: 19518981
Change-Id: I4f898380c9ffc071da2357a51e61309ae5d233f5
(cherry picked from commit 9b8507c52a)
