This CL removes the existing TestApi
WindowManager#setForceCrossWindowBlurDisabled and replaces it
with Settings.Global#ENABLE_WINDOW_BLURS.
Bug: 14186649
Test: m && atest BlurTests
Change-Id: Ia15b7932ea973a9ed195c507558cdc71f194b366
Remove references to Settings.System.DATE_FORMAT and mark it as clearly
deprecated.
It was probably made obsolete some time before kitkat. There were still
some references in view code up to lollipop (removed in change
Ib77a8e7727d027cae39d5e6f431cac1d1ff8a121). During marshmallow / nougat
there were no references, then references were added in backup code in
oreo. This change is intended to make it more obvious that this setting
is obsolete.
Bug: 185884644
Test: build only
Change-Id: I12441541bc3ca0e012cee64d4c784a0ce8233715
Update SettingsProtoDumpUtil / secure.proto to reference the new (user
scoped) location_time_zone_detection_enabled setting that has been added
for S. This has been added in a "DateTime" message to reflect the
SettingsUI structure.
For consistency with secure.proto and the settings strings, global.proto
and the associated SettingsProtoDumpUtil code has updated to rename the
"Auto.time" and "Auto.time_zone" proto fields to "DateTime.auto_time"
and "DateTime.auto_time_zone". This is a binary compatible change as
the field IDs have not been changed.
Note: The "time_12_24" and "date_format" settings, which are user-scoped
settings from "Settings.System" have been left for a future release
besides some minor docs improvements. See bug 185884644.
This change also improve the docs for settings that are associated with
date and time.
Bug: 151304765
Bug: 185884644
Test: build / treehugger
Change-Id: If2daf3f530bd1add7a0a5cc3260221ea3ad8952d
Both device controls and wallet have moved to new areas outside of the
power menu. In step 1, we are deprecating the device controls settings,
as the user can now fully control availability within the new Quick
Settings device controls tile.
Bug: 185597511
Test: atest ControlsControllerImplTest ControlsComponentTest DeviceControlsTileTest ControlsRequestDialogTest
Change-Id: Ifdbb83dfd35263d62c9fd3dc67699769f9c9f408
* Move bubbles setting from the global table to the secure
table, this should be a per-user setting
* Update step in SettingsProvider that adds the secure
setting based on the value of the previous global, or if
the user is managed, it checks if the owner of the managed
user has a secure setting & uses the value from that to
insert the new setting.
* Adds the secure setting to the "cloned to profile"
group since it should follow the setting of the profile
owner.
* PreferencesHelper tracks this value per-user.
Bug: 173408780
Test: atest PreferencesHelperTest NotificationManagerServiceTest BubbleExtractorTest
Change-Id: I261364890fcc54fb2791e628b41c07aeddde3974
Remove the AsUser portion of the name and the userhandle argument to
comply with api guidelines, and instead take the user from the context
that's passed in instead.
Fixes: 179727265
Test: atest CallLogTest
Change-Id: Iad614f333d7bae1baab41b3d643688338a60d4c2
Device default value set in config_keyChordPowerVolumeUp in
config.xml; can be overridden for all users with
Settings.Global.KEY_CHORD_POWER_VOLUME_UP.
Value may be one of:
0 - no-op
1 - vibrate mode (current AOSP default behavior)
2 - launch assistant
Bug: 179673796
Test: adb shell settings put global key_chord_volume_up <0, 1, or 2>
adb shell dumpsys window | grep mPowerVolUpBehavior
adb shell input keycombination POWER VOLUME_UP
Change-Id: I0e03155bdbe61d9fdd6838fe2c860749cf360907
This was originally introduced as an @hide API, but was exposed as part
of changes to app links. The old constant value was maintained, but it
can be migrated to the standard format and Settings can just catch
both.
Bug: 184370492
Test: manual, test app that launches using action
Change-Id: I904bd816da6c20a1dfdb207f8d4d486bb7be5cd5
Methods were moved from TimeZoneDetector to TimeManager in commit
02d943f44d. This commit updates comments
to track.
Bug: 159891384
Test: None - comment change
Change-Id: I96c4c248f98041f88ff3372b575114c277b80620
When an app is proxying access to runtime permission protected
data it needs to check whether the calling app has a permission
to the data it is about to proxy which leaves a trace in app ops
that the requesting app perofmed a data access. However, then the
app doing the work needs to get the protected data itself from the
OS which access gets attributed only to itself. As a result there
are two data accesses in app ops where only the first one is a
proxy one that app A got access to Foo through app B - that is the
one we want to show in the permission tracking UIs - and one
for the data access - that is the one we would want to blame on
the calling app, and in fact, these two accesses should be one -
that app A accessed Foo though B. This limitation requires fragile
one off workarounds where both accesses use the same attribution
tag and sys UI has hardcoded rules to dedupe. Since this is not
documented we cannot expect that the ecosystem would reliably
do this workaround in apps that that the workaround in the OS
would be respected by every OEM.
This change adds a mechaism to resolve this issue. It allows for
an app to create an attribution context for another app and then
any private data access thorugh this context would result in a
single app op blame that A accessed Foo though B, i.e. we no longer
have double accounting. Also this can be nested through apps, e.g.
app A asks app B which asks app C for contacts. In this case app
B creates an attribution context for app A and calls into app C
which creates an attribution context for app B. When app C gets
contacts the entire attribution chain would get a porper, single
blame: that C accessed the data, that B got the data from C, and
that A got the data form B. Furthermore, this mechanism ensures
that apps cannot forget to check permissions for the caller
before proxying private data. In our example B and C don't need
to check the permisisons for A and B, respectively, since the
permisisons for the entire attribution chain are checked before
data delivery. Attribution chains are not forgeable preventing
a bad actor to create an arbitrary one - each attribution is
created by the app it refers to and points to a chain of
attributions created by their corresponding apps.
This change also fixes a bug where all content provider accesses
were double counted in app ops due to double noting. While at
this it also fixes that apps can now access their own last ops.
There was a bug where one could not pass null getting the attributed
ops from a historical package ops while this is a valid use case
since if there is no attribution everything is mapped to the null
tag. There were some app op APIs not being piped thorough the app
ops delegate and by extension through the app ops policy. Also
now that we have nice way to express the permission chain in a
call we no longer need the special casing in activity manager to
handle content provider accesses through the OS. Fixed a bug
where we don't properly handle the android.os.shell calls with
an invlaid tag which was failing while the shell can do any tag.
Finally, to ensure the mechanims is validated and works end-to-end
we are adding support for a voice recognizer to blame the client
app for the mic access. The recognition service can create a blaming
context when opening the mic and if the mic is open, which would
do all permission checks, we would not do so again. Since changes
to PermissionChercker for handling attribution sources were made
the CL also hooks up renounced permissoins in the request permission
flow and in the permission checks.
bug:158792096
bug:180647319
Test:atest CtsPermissionsTestCases
atest CtsPermissions2TestCases
atest CtsPermissions3TestCases
atest CtsPermissions4TestCases
atest CtsPermissions5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Change-Id: Ib04585515d3dc3956966005ae9d94955b2f3ee08
Revert "Revert "Hide long-press home animation when disabled by ..."
Revert submission 13998375-revert-13958909-mrcasey-lph-GNUFFHLQXH
Reason for revert: Reverting these CLs did not fix the test b/183684181
Reverted Changes:
Iac13fc450:Revert "Hide long-press home animation when disabl...
Ieb43607a8:Revert "Add setting for touch gesture and long-pre...
Change-Id: Ia92b0a1f19dc7423fe1b3796e14582169e58d203
Revert "Hide long-press home animation when disabled by setting"
Revert submission 13958909-mrcasey-lph
Reason for revert: Possible test breakage b/183684181
Reverted Changes:
Iaaf39e76a:Hide long-press home animation when disabled by se...
I24ee67cf1:Add setting for touch gesture and long-press home ...
Change-Id: Ieb43607a8010b843fc643979953a266cbb84788f
Added new APIs to DisplayManager to set the user disabled HDR formats,
and get/set if user disabled formats should be ignored or not.
These new settings are stored in Settings.Global.
Modified the implementation of Display#getHdrCapabilities to not return
the formats disabled by user.
Bug: 172905874
Test: atest CtsDisplayTestCases
Change-Id: I4841af251ee0e4938614b154d0c5239814ea7cd9
Merged-In: I4841af251ee0e4938614b154d0c5239814ea7cd9
This is configured by the system config resource,
config_systemSpeechRecognizer, which also provides the default
VoiceRecognitionService and the holder for the SYSTEM_SPEECH_RECOGNIZER
role.
InputMethodManagerService updates the new DEFAULT_VOICE_INPUT_METHOD
setting and handles changes to the config_systemSpeechRecognizer value.
No updates are made through the Settings UpgradeController because any
updates that would be needed are already handled by the logic for config
value changes.
Testing:
1. Enable DEBUG logging in InputMethodManagerService.
2. $ m -j && adb remount && adb shell stop && adb sync && adb shell start
3. $ adb shell settings get secure enabled_input_methods; \
adb shell settings get secure default_input_method; \
adb shell settings get secure disabled_system_input_methods; \
adb shell settings get secure default_voice_input_method
4. Check logcat to make sure nothing looks suspect.
Cases tested:
- IME wasn't already in the enabled IME list
- IME was already enabled
- no value for config_systemSpeechRecognizer
- new user added
- locale changed
- config package doesn't have an IME
- update without config value, then set a config value
- config value updated (when both values had valid IMEs)
- combinations of the above cases, as appropriate
Bug: 175480456
Test: manual - see above
Test: atest InputMethodUtilsTest
Test: atest CtsInputMethodTestCases --retry-any-failure
Change-Id: I1abdc145e3d5969fbb69811df2ca2e35c7a177e1
This will enforce the readable tests for changes made to Settings.java.
Test: atest
BUG: 183530680
Change-Id: Ie91350b29c10868cecd2c2fe4eba378278b3cb23
With the changes for app links v2, apps need a way to link users into
the domain selection screen if the app relies on opening web links
for some functionality.
To achieve that, this exposes the existing action,
ACTION_APP_OPEN_BY_DEFAULT_SETTINGS, from android.provider.Settings
and removes the permission needed to launch the relevant Activity,
since it's no longer required.
Note that this will also require a change to remove the enforcement
from the Activity declaration, which will be a follow up.
Bug: 178648367
Test: none, unhide API
Change-Id: I73231b9b4686ee67490ffe1526542b2f59c8089b
