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)
Added a toast message to inform the user that the color temperature
setting is applied once the display is off.
Bug:26110238
Change-Id: Ia773581eb441ed2f4ac44b20e611ad3700e8abbf
Some operators support Wi-Fi Calling only, not VoLTE.
They don't need "Cellular preferred" option.
In this case, set uneditalbe attribute for preferred preference.
Bug: 26299288
Change-Id: I58b44bbd85bb5ef436d32a5e34d7372532695b91
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)
