The key used to show the migration information related to
the accessibility floating menu.
Bug: 175365399
Test: atest SettingsProviderTest
Change-Id: Ifabc412b990c72ad345bab2d5d8539a57bd6ca5d
Revert "Add an exception for Settings.Secure.NFC_PAYMENT_DEFAULT..."
Revert submission 14326766-b/174151290
Reason for revert: potential test error for b/186717555
Reverted Changes:
I97fcd5550:[SettingsProvider] Remove @Readable for NFC_PAYMEN...
I6e55bef75:Add an exception for Settings.Secure.NFC_PAYMENT_D...
Bug: 186717555
Bug: 182283321
Bug: 174151290
Change-Id: Ib84c57b855ffe10870fda2568a7499746f0d2335
A new requirement to add A11y shortcut for One Handed Mode feature
- The shortcut action is enter or exit one handed mode
- ONE_HANDED_MODE_ACTIVATED = 0 /* false */ : STATE_NONE
- ONE_HANDED_MODE_ACTIVATED = 1 /* true */ : STATE_ACTIVE
Compare to enabled or disabled (ONE_HANDED_MODE_ENABLED)
- ONE_HANDED_MODE_ENABLED = 0 /* false */ : Disable function
- ONE_HANDED_MODE_ENABLED = 1 /* true */ : Enabled function
Test: manual
Test: make
Bug: 182425480
Change-Id: Iee911631a6734af7eb742e1206d2b9b75b694969
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
