Setting shares system uid and can be used to bypass different security
checks.
We add proper handling for intents which resolve toexported=true
activities with permission filed.
Added nested preferences filtering.
Bug: 33123882
Test: manual tests
Change-Id: I3ba9c768fc4f8093dcf2eadc17f14c506ec5c327
Merged-In: Ib5bab7989fc44b4391f9050c6b18f81c58c09cf6
Setting shares system uid and can be used to bypass different security
checks.
We add proper handling for intents which resolve toexported=true
activities with permission filed.
Added nested preferences filtering.
Bug: 33123882
Test: manual tests
Change-Id: Ib5bab7989fc44b4391f9050c6b18f81c58c09cf6
Remove the learn more link during setup wizard, because HelpUtils is
returning null for the intent while the device is not provisioned.
Bug: 31246856
Change-Id: I4cf5c282f170188aef98a02d3b96af5e63ea7f39
- Prevent external tiles from system apps
- Don't let user settings run
- Disable help
Bug: 29194585
Change-Id: I74ab8aaab62d62cc4dbbdf3164429a503f3a572b
The privilege for an app to write to the system settings is protected
by an app-op signature permission. App-op permissions are special: if
the app-op is deny/allow we deny/allow write access; if the app-op is
default holding the permission determies write access. The settings
code assumes that CHANGE_NETWORK_STATE is an app op permission
(system|appop) while it is a normal permission which any app gets by
declaring it used in the manifest.
The side effect is that the state of the toggle in the UI for write
system settings will initially be in the wrong state if the app uses
both WRITE_SETTINGS and CHANGE_NETWORK_STATE. However, the code in
the public API an app uses to check write settings access would return
the opposite since it checks the WRITE_SETTINGS permission and its
app op. Hence, if an app requires write settings to start the user
will see in the settings UI it has access but the app will not have
access, so the app would prompt the user to allow write settings.
The non-obvious fix is for the user to toggle the setting off and on
to get the app op in the right state and be able to launch the app.
bug:25843134
Change-Id: I3d726a66c7f9857bc7dbd5946fdbb8f340c6eb4d
(cherry picked from commit 356fb2d10d)
(cherry picked from commit 119d589ea5)
Guard against FRP attacks by keeping the persistent data block
intact, if a factory reset has been issued during SUW.
Bug: 25290269
Change-Id: Id26b4c10235ad126632b71875592a4fa70a39b24
Guard against FRP attacks by keeping the persistent data block
intact, if a factory reset has been issued during SUW.
[resolves merge conflicts with ag/808069]
Bug: 25290269
Change-Id: Id26b4c10235ad126632b71875592a4fa70a39b24
+ In BT pairing dialog, uncheck checkbox for contact sharing by default
for devices not recognized as carkits at pair time.
Bug: 23607427
Change-Id: I7f1d40d86e713e248d3c225459be4895c4f75d76
(cherry picked from commit dbc47fb262)
+ In BT pairing dialog, uncheck checkbox for contact sharing by default
for devices not recognized as carkits at pair time.
Bug: 23607427
Change-Id: I7f1d40d86e713e248d3c225459be4895c4f75d76
Block access to development settings by tapping on the build number
in "About phone". Once SUW has completed, taps will be allowed.
Bug: 25290269
Change-Id: I9b2787712237f28fba446abab15a9e1c075d0419
Make sure the duration shown for z-ram is sane (the maximum of the
other process durations of that app).
Change-Id: I62c46b89f927b2c7c16f5c31f6910419b2bdd130
