Verify the input PAC Uri before performing follow-up actions.
Check if the URL is a valid URL to filter some invalid URLs since
these invalid URLs could not fall into any subclass of existing
URLConnections. When the PAC Uri is other invalid URL scheme, it
will cause an UnsupportedOperationException if there is no proper
subclass that implements the openConnection() method.
A malformed URL may crash the system.
Even it's a valid URL, some subclasses(e.g. JarURLConnection)
may not have openConnection() implemented. It will also hit the
problem, so convert the possbile exception from openConnection()
to re-throw it to IOException which is handled in the existing
code.
Bug: 219498290
Test: atest FrameworksNetTests CtsNetTestCases
Test: Test with malformed URL
Merged-In: I22903414380b62051f514e43b93af992f45740b4
Merged-In: I2abff75ec59a17628ef006aad348c53fadbed076
Change-Id: I4d6cec1da9cf3f70dec0dcf4223254d3da4f30a3
(cherry picked from commit 6390b37a3b)
This reverts commit 012cace2ee.
Reason for revert: This CL depends on ag/17823648, which is not merged into qt-qpr1-dev.
Change-Id: I503bcc1e979dd4db941cb7754f63a0dc35ce9682
Occasionally ILockSettings can fail to be initialized otherwise
Fixes: 232714129
Test: boot (and eventually bootstress/reboot-long)
Change-Id: I2f9f9bdba37f4ebfaea56c1a6662f0474ae8a002
Merged-In: I2f9f9bdba37f4ebfaea56c1a6662f0474ae8a002
(cherry picked from commit 8e278543bd)
This reverts commit 1ca6f8ddb8.
Reason for revert: DroidMonitor: Potential culprit for Bug 231171562 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: Ib5819de2ce4e60deae5676eed9947cbbb759be10
This CL makes the following modifcations:
1. Add LockPatternUtils.StrongAuthTracker to monitor
the lockdown mode status of the phone.
2. Call mListeners.notifyRemovedLocked with all the
notifications in the mNotificationList when entering
the lockdown mode.
3. Call mListeners.notifyPostedLocked with all the
notifications in the mNotificationList when exiting
the lockdown mode.
4. Dismiss the function calls of notifyPostedLocked,
notifyRemovedLocked, and notifyRankingUpdateLocked
during the lockdown mode.
The CL also adds corresponding tests.
Bug: 173721373
Test: atest NotificationManagerServiceTest
Test: atest NotificationListenersTest
Test: manually verify the paired device cannot receive
notifications when the host phone is in lockdown mode.
Ignore-AOSP-First: pending fix for a security issue.
Change-Id: I7e83544863eeadf8272b6ff8a9bb8136d6466203
Merged-In: I7e83544863eeadf8272b6ff8a9bb8136d6466203
(cherry picked from commit 3cb6842a05)
* changes:
[RESTRICT AUTOMERGE] Log to EventLog on prepareUserStorage failure
[RESTRICT AUTOMERGE] Ignore errors preparing user storage for existing users
[RESTRICT AUTOMERGE] UserDataPreparer: reboot to recovery for system user only
[RESTRICT AUTOMERGE] UserDataPreparer: reboot to recovery if preparing user storage fails
[RESTRICT AUTOMERGE] StorageManagerService: don't ignore failures to prepare user storage
Check user unlocked before write to /data/system_ce/0/snapshots
NPE happens when there is an orphaned session which we've
tried to prevent in all cases.
Log an error message if this situation happens.
Bug: 227342978
Test: atest CtsRootPackageInstallerHostTestCases
Change-Id: Ia21323926bd9db1a6f05461904deb45b4c3dd0bc
(cherry picked from commit 07e31dfb1e)
Merged-In: Ia21323926bd9db1a6f05461904deb45b4c3dd0bc
This addresses a security issue where the guest user can remove updates
for system apps.
With this CL, attempts to uninstall/downgrade system apps will fail if
attempted by a non-admin user.
This is a backport of ag/17352264.
Bug: 170646036
Test: manual, try uninstalling system app update as guest
Change-Id: I5bbaaf83d035c500bfc02ff4b9b0e7fb1e7c2feb
Merged-In: I4e959e296cca9bbdfc8fccc5e5e0e654ca524165
Unfortunately we can't rule out the existence of devices where the user
storage wasn't properly prepared, due to StorageManagerService
previously ignoring errors from mVold.prepareUserStorage, combined with
OEMs potentially creating files in per-user directories too early. And
forcing these broken devices to be factory reset upon taking an OTA is
not currently considered to be acceptable.
One option is to only check for prepareUserStorage errors on devices
that launched with T or later. However, this is a serious issue and it
would be strongly preferable to do more than that.
Therefore, this CL makes it so that errors are checked for all new
users, rather than all new devices. A field ignorePrepareStorageErrors
is added to the user record; it is only ever set to true implicitly,
when reading a user record from disk that lacks this field. This field
is used by StorageManagerService to decide whether to check for errors.
Bug: 164488924
Bug: 224585613
Test: Intentionally made a device affected by this issue by reverting
the CLs that introduced the error checks, and changing vold to
inject an error into prepareUserStorage. Then, flashed a build
with this CL without wiping userdata. The device still boots, as
expected, and the log shows that the error was intentionally
ignored. Tested that if a second user is added, the error is
*not* ignored and the second user's storage is destroyed before it
can be used. Finally, wiped the device and verified that it won't
boot up anymore, as expected since error checking is enabled for
the system user in that case.
Change-Id: I9bdd1a4bf5b14542adb901f264a91d489115c89b
(cherry picked from commit 60d8318c47)
Merged-In: I9bdd1a4bf5b14542adb901f264a91d489115c89b
With the next CL, old devices might contain a combination of old users
with prepareUserStorage error checking disabled and new users with
prepareUserStorage error checking enabled. Factory resetting the whole
device when any user fails to prepare may be too aggressive. Also,
UserDataPreparer already destroys the affected user's storage when it
fails to prepare, which seems to be fairly effective at breaking things
for that user (absent proper error handling by upper layers).
Therefore, let's only factory reset the device if the failing user is
the system user.
Bug: 164488924
Bug: 224585613
Change-Id: Ia1db01ab4ec6b3b17d725f391c3500d92aa00f97
(cherry picked from commit 4c76da76c9)
Merged-In: Ia1db01ab4ec6b3b17d725f391c3500d92aa00f97
StorageManager.prepareUserStorage() can throw an exception if a
directory cannot be encrypted, for example due to already being
nonempty. In this case, usage of the directory must not be allowed to
proceed. UserDataPreparer currently handles this by deleting the user's
directories, but the error is still ultimately suppressed and starting
the user is still allowed to proceed.
The correct behavior in this case is to reboot into recovery to ask the
user to factory reset the device. This is already what happens when
'init' fails to encrypt a directory with the system DE policy. However,
this was overlooked for the user directories. Start doing this.
Bug: 164488924
Bug: 224585613
Change-Id: Ib5e91d2510b25780d7a161b91b5cee2f6f7a2e54
(cherry picked from commit 5256365e65)
Merged-In: Ib5e91d2510b25780d7a161b91b5cee2f6f7a2e54
We must never leave directories unencrypted.
Bug: 164488924
Bug: 224585613
Change-Id: I9a38ab5cca1ae9c9ebff81fca04615fd83ebe4b2
(cherry picked from commit 50946dd15f)
Merged-In: I9a38ab5cca1ae9c9ebff81fca04615fd83ebe4b2
Currently SliceManagerService#checkSlicePermission does not verify the
caller's identity. This leads to a security vulnerability because
checkSlicePermission does more than checking the permission as opposed
to simply return a boolean value -- it additionally grants slice access
under a certain condition. A malicious app can spoof the calling package
to acquire slice access.
This CL verifies the caller before granting slice access.
Bug: 208232850, 179699767
Test: manual
Change-Id: I2539c9ff5ea977c91bb58185c95280b4d533a520
Merged-In: I2539c9ff5ea977c91bb58185c95280b4d533a520
(cherry picked from commit 5bd2196c53)
The top-focusable activity resides in the RESUMED state while the app
process is newly created and attached. The behavior may enable UI
hijacking attacks against apps implementing authentication.
This CL disallows the system to resume the activity for the case if it
is not visible or is occluded by other translucent tasks.
Bug: 211481342
Test: atest CtsWindowManagerDeviceTestCases:ActivityLifecycleTests
Change-Id: I7903494cf928b5b5613700262b7c5fff10f3c5a0
setBlocked is a hidden API, so apps should not be calling
the method, but fix up the data in case they do
Test: PreferencesHelperTest; manual with ApiDemos FGS
Bug: 209966086
Change-Id: Icc709a6b0d0a8c5f2d9243959992f1b6764354db
Merged-In: I8a27853c7ed05d9dfd38a3142fbbe185946c3992
setBlocked is a hidden API, so apps should not be calling
the method, but fix up the data in case they do
Test: PreferencesHelperTest; manual with ApiDemos FGS
Bug: 209966086
Change-Id: Icc709a6b0d0a8c5f2d9243959992f1b6764354db
Merged-In: I8a27853c7ed05d9dfd38a3142fbbe185946c3992
Before allowing the group to be deleted, by updating
the current check to the method that populates the channel
list
Test: NotificationManagerServiceTest
Bug: 209965481
Change-Id: I9db781c300e96e9c80bd5d21585b8be9b4db08c8
Merged-In: I9db781c300e96e9c80bd5d21585b8be9b4db08c8
(cherry picked from commit 331b617949)
Currently, when we abandon a staged session we mark it as destroyed and
then immediately clean it up. Cleaning up a staged session immediately
causes racing condition with pre-reboot verification.
In order to avoid the racing condition, we want to delay cleanup of
staged session until it is safe to do so. This means, the system will
be carrying around destroyed staged sessions internally.
Since there is now a gap between when a session is destroyed and when it
is cleaned up, the user can reboot in this window. As such, we need to
persist the mDestroyed field of session so that we know session is
destroyed after reboot and act accordingly.
Also, once a session is destroyed, theoretically it doesn't exist.
Carrying it around internally is an implementation details which
shouldn't be exposed externally. As such, we filter out destroyed
sessions before surfacing them to users.
Bug: 145925842
Bug: 67862680
Test: atest PackageInstallerSessionTest
Test: atest StagedInstallTest
Change-Id: I4ede6b7a4b5d861e5c73f13884c7aa86cf7633a2
Merged-In: I4ede6b7a4b5d861e5c73f13884c7aa86cf7633a2
(cherry picked from commit 731bd965fb)
