Updating the Settings app to allow setting the value off for key
HAPTIC_FEEDBACK_INTENSITY. This setting state is also copied onto
HAPTIC_FEEDBACK_ENABLED setting, so both should be in sync after this
change.
Similar logic is applied between RING_VIBRATION_INTENSITY and
VIBRATE_WHEN_RINGING.
This will not disable the hardware feedback since that one is controlled
by a separate setting key now.
The "vibrate for calls" was also removed and the single toggle for
"vibrate first then ring gradually" was moved into the "Vibration &
haptics" page.
Bug: 185351540
Test: [HapticFeedback|NotificationVibration|RingVibration][Intensity|Toggle]PreferenceControllerTest
and manual testing of the AOSP settings app
Change-Id: I9c94cef331a1500a1272a601ba32667ca995ddab
This change makes it such that bubble settings will only be available once
the app has sent a bubble notification.
Test: atest BubbleSummaryPreferenceControllerTest
Bug: 178387292
Change-Id: I459ffcedc4194d953e8b7170937e2eb5334d1422
- Show the illustration and QS tile label text
- Dynamic update popup window width by content
- Support the auto close timer API
Bug: 210353709
Test: make RunSettingsRoboTests ROBOTEST_FILTER=AccessibilityQuickSettingsTooltipWindowTest
Change-Id: I8e0d3ff4ef6a48a54ef1e80724002d2cd28d7ac3
Test: Make sure behavior is correct as it was in
search flow, higlight flow, regular settings flow, split screen flow.
Bug: 204399167
Change-Id: I7fc29c8cdbfc6682963591f4ff805070bea4ca22
With FDE (Full Disk Encryption), secure start-up (i.e. requiring a PIN /
pattern / password to boot the device) was incompatible with
accessibility services. Thus, the accessibility settings would ask the
user to disable secure start-up when enabling an accessibility service.
Now that FDE support has been removed in favor of FBE (File Based
Encryption), this is no longer necessary. Remove it.
Bug: 208476087
Change-Id: I5f6e512f223df63e1b4d1c181fc8b3fe683dcd5f
Some strings used in the Settings UI have "crypt_keeper" in their names,
but they aren't specific to FDE, which is no longer supported. They are
still used to report the encrypted status of the device on devices that
use FBE, or the unencrypted status of the device on devices that don't
have encryption enabled at all. Rename these strings appropriately.
Test: On Cuttlefish with and without encryption enabled, tested visiting
the "Encryption & credentials" settings.
Bug: 208476087
Change-Id: Ic63910c870837f5b37e4407ba5b3c7629e925c17
FDE support has been removed in favor of FBE, so remove the FDE settings
from the "Encryption & credentials" page of the Settings app.
For now I didn't change the way the page appears on devices that don't
use FDE; as before, it still lists "Encrypt phone", followed by either
"Encrypted" or "Phone not encrypted" with no changeable settings. Note
that the strings used for this have "crypt_keeper" in their names but
aren't specific to FDE; the next CL will rename them.
Test: On Cuttlefish with and without encryption enabled, tested visiting
the "Encryption & credentials" settings.
Bug: 208476087
Change-Id: I3ce9894291ea1f1886f21980a86a92bfce38038a
Since Android 10, new devices have been required to use FBE (File Based
Encryption) instead of FDE (Full Disk Encryption). FDE support was
already removed from system components such as init and vold.
Therefore, the CryptKeeper activity is no longer needed. Remove it.
Note: this CL only removes CryptKeeper itself, i.e. the activity which
runs at boot time on devices that are using FDE or are being encrypted
with FDE in-place. Later CLs will remove FDE-specific code from the
Settings app.
Bug: 208476087
Change-Id: I4aaf795e8cee1ff3cdd55a41c975273c8faeefa9
This adds a config resource to specify whether restricted profiles
should be offered as an option when a new user is added. This replaces
the previous check if a device is voice capable, and will be defaulted
to false.
Bug: 202854971
Test: make RunSettingsRoboTests -j40 ROBOTEST_FILTER="com.android.settings.users.UserCapabilitiesTest"
Change-Id: If090fe8d902d6521acfde8c26e801aa4fc4f5ff4
based on the type of active Security Settings
Test: atest SettingsUnitTests:SecurityAdvancedSettingsTest
Bug: 206001340
Change-Id: I7bdac4b26653eedb45e3e2f056e6804a6c16cb18
Bug: 196180536
Test: * connect to a EAP-TLS network with TOFU option
* make RunSettingsRoboTests ROBOTEST_FILTER=WifiConfigController2Test
Change-Id: I30b55d835bd073d604bddd235f2425bdc8b647af
Code refactor for clean up some internal dependencies.
Bug: 213836977
Test: Junit VpnPreferenceControllerTest
Change-Id: Ib6684c7b84bd04d9c1a015fa78d2c0ac5f1773c8
This is a no-op refactoring.
These functions are deprecated and replaced by
NetworkTemplate#Builder, use public API instead.
Test: make RunSettingsLibRoboTests
Bug: 204830222
Change-Id: Idc2a09d8e3789ca2c7a97691cfad4b2e2b417f0d
When UserManager.DISALLOW_ADD_WIFI_CONFIG is set to true.
- Disable the "Add network" item in the Internet settings.
- Activity action API for ACTION_WIFI_ADD_NETWORKS should not be
permitted and the user shouldn’t see a prompt for approval
Bug: 203169077
Test: make RunSettingsRoboTests ROBOTEST_FILTER=NetworkProviderSettingsTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=AddAppNetworksActivityTest
Change-Id: I18d7703b5972bfbc12dca10b6432d756813abace
Move some logic out of constructor to reduce the loading when launch UI.
Bug: 213836977
Test: Junit VpnPreferenceControllerTest
Change-Id: I90c7770f529b4710196697886e566dfe1be629e4
In onReceive of AppRestrictionsFragment.java, there is a possible way to
start a phone call without permissions due to a confused deputy.
This could lead to local escalation of privilege with no additional
execution privileges needed.
We should not allow the restrictionsIntent to startActivity simply
because it resolves to multiple activities.
Instead, we should call resolveActivity and check the result's package
name is same as current package name, then it is safe to startActivity.
Bug: 200688991
Test: manual verify
Change-Id: Iaa2d3a9497c3266babe0789961befc9776a4db7a
Merged-In: Iaa2d3a9497c3266babe0789961befc9776a4db7a
(cherry picked from commit 359512cd95)
In onReceive of AppRestrictionsFragment.java, there is a possible way to
start a phone call without permissions due to a confused deputy.
This could lead to local escalation of privilege with no additional
execution privileges needed.
We should not allow the restrictionsIntent to startActivity simply
because it resolves to multiple activities.
Instead, we should call resolveActivity and check the result's package
name is same as current package name, then it is safe to startActivity.
Bug: 200688991
Test: manual verify
Change-Id: Iaa2d3a9497c3266babe0789961befc9776a4db7a
Merged-In: Iaa2d3a9497c3266babe0789961befc9776a4db7a
(cherry picked from commit 359512cd95)
In onReceive of AppRestrictionsFragment.java, there is a possible way to
start a phone call without permissions due to a confused deputy.
This could lead to local escalation of privilege with no additional
execution privileges needed.
We should not allow the restrictionsIntent to startActivity simply
because it resolves to multiple activities.
Instead, we should call resolveActivity and check the result's package
name is same as current package name, then it is safe to startActivity.
Bug: 200688991
Test: manual verify
Change-Id: Iaa2d3a9497c3266babe0789961befc9776a4db7a
Merged-In: Iaa2d3a9497c3266babe0789961befc9776a4db7a
(cherry picked from commit 359512cd95)
In onReceive of AppRestrictionsFragment.java, there is a possible way to
start a phone call without permissions due to a confused deputy.
This could lead to local escalation of privilege with no additional
execution privileges needed.
We should not allow the restrictionsIntent to startActivity simply
because it resolves to multiple activities.
Instead, we should call resolveActivity and check the result's package
name is same as current package name, then it is safe to startActivity.
Bug: 200688991
Test: manual verify
Change-Id: Iaa2d3a9497c3266babe0789961befc9776a4db7a
Merged-In: Iaa2d3a9497c3266babe0789961befc9776a4db7a
(cherry picked from commit 359512cd95)
