- Hide MobileDataSlice if the user is not allowed to configure mobile networks.
Bug: 310630794
Flag: EXEMPT bugfix
Test: manual test
atest -c MobileDataSliceTest
Change-Id: I35814733a915f011e284b082ce7a94898ce8a6fb
This change addresses a security gap where users with the "DISALLOW_GRANT_ADMIN" restriction could still grant admin privileges to others, potentially undermining supervised user models. We've extended the existing logic to ensure that restricted users cannot grant or receive admin privileges when the DISALLOW_GRANT_ADMIN restriction is in place. This prevents scenarios where supervised users could create new admins to bypass restrictions and factory reset the device.
In addition to the core functionality improvement, significant code refactoring has been done to untangle complex multiple if conditions. The logic for determining when admin status changes are allowed is now clearer and more readable, taking into account both the "current user" (initiating the change) and the "target user" (whose privileges are being modified).
Bug: 357056776
Test: atest UserDetailsSettingsTest and manually verified the user having DISALLOW_GRANT_ADMIN restriction is not allowed to change admin status of any other user.
Flag: android.multiuser.unicorn_mode_refactoring_for_hsum_read_only
Change-Id: If02c9355ee7ce285b5b7bcddae630d716d5bf333
As keyboard_category_enabled feature has launched, remove the feature
flag since it's unnessary.
And, this CL is the preparation of removing CATEGORY_KEYBOARD vibration
attribute and logic, remove the flag usage ing settings since no longer
need this flag.
Flag: EXEMPT flag removal
Bug: 332661766
Test: build
Test: atest KeyboardVibrationTogglePreferenceControllerTest
Change-Id: I19cecb977d52a74b26eea1f494052e0e852359c4
The original method name implied that the returned profiles were guaranteed to be connectable. However, it actually filters profiles based on user can access the profile in the UI and initiate the connection. Change the method name to getUiAccessibleProfiles() aligns the name with the actual behavior.
Flag: EXEMPT simple renaming
Bug: 356530795
Test: m
Change-Id: Ib7d29a4bf9c213ddcecc567864583165ab97a099
1. Hide the preview button when it's disabled
2. Change the text from “Done” to “Save” in the color selector dialog
Flag: EXEMPT simple UI change
Bug: 356978471
Test: manually, video attached on the bug
Test: atest FlashNotificationsPreviewPreferenceControllerTest
Change-Id: I2e6e697ad10f0207602d613085663cdd82521ea2
* Fix combinations of messages=all with other conversation values.
* Correctly display policies with CONVERSATION_SENDERS_ANYONE. An additional checkbox is included, but _only_ if the policy has CONVERSATION_SENDERS_ANYONE when shown.
* Changed updateState() to consider the possible cases one by one. Because multiple policies are mapped to the same checkbox states, the strategy of "checking whether the state matches what the checkbox wants to set" doesn't really work.
* Fix messages summary and circles to support CONVERSATION_SENDERS_ANYONE.
* Added a lot of tests (actually, hopefully ALL OF THEM) covering the user-visible behavior. :)
Fixes: 354658240
Test: atest ZenModesSummaryHelperTest ZenModePrioritySendersPreferenceControllerTest
Flag: android.app.modes_ui
Change-Id: I727496ca3eb820e4baaab942b61d2e57cdb491fc
After the code change of ag/28283226, they hide the LE Audio toggle for
LE Audio only device since turning off the profile may cause this device
no functioning. But the dual mode hearing devices(LE Audio + Asha) are
wrongly recognized as LE Audio only devices since
HearingAidProfile.accessProfileEnabled() return false. This make the
users lost the ability to switch between profiles they preferred.
Make HearingAidProfile.accessProfileEnabled() return true and hide the
Hearing Aid toggle by default since it's also meaningless to turn off
the Asha profile for Asha-only devices.
Flag: com.android.settingslib.flags.asha_profile_access_profile_enabled_true
Bug: 356530795
Test: manual checking the UI
Test: atest BluetoothDetailsProfilesControllerTest
Change-Id: Ica350b4c16c1b07945399bfee1038f7b0824baed
CachedBluetoothDevice can change its member variable mDevice, so we can
not rely on the CachedBluetoothDevice#getDevice when we add source to
it. This change will return BluetoothDevice instead of
CachedBluetoothDevice when fetchConnectedDevicesByGroupId, so that we
won't add source to unintended BluetoothDevice via
CachedBluetoothDevice#getDevice.
Fix: 350877510
Test: atest
Flag: com.android.settingslib.flags.enable_le_audio_sharing
Change-Id: I4ee41b8f1449e7176f0a05a7dd4e59034c161824
When wep not supported, wep is always not allowed, so we should show
unchecked toggle for "Allow WEP networks"
Bug: 356326814
Flag: EXEMPT bug fix
Test: manual - on Network preferences
Test: atest WepNetworksPreferenceControllerTest
Change-Id: I408434fbbf48e1010710ecf3bf9f7988e521b076
This isn't a real image yet (just draws a diagonal gradient), but should now be roughly ready for inserting the correct drawables based on the mode whenever those are available.
Bug: 332730534
Test: manual, SetupInterstitialActivityTest
Flag: android.app.modes_ui
Change-Id: I45a78950f671a989258a85525a7a8ee0c445a332
This covers both the case of navigating to the mode page through the mode aggregator menu as well as if an app sends an intent to go to the mode.
The interstitial visuals are not done yet; in particular, the image is just a gray box for now.
Manual tests done:
- visually verifying the interstitial page in both portrait and landscape
- accessing the mode page from modes list, confirming interstitial pops up
- accessing enabled and disabled-by-user mode page from modes list (no interstitial)
- getting to the mode page from intent through an app
- accessing enabled and disabled-by-user mode pages from app intent (no interstitial)
- adjusted display and font size (it looks bad with max display & font size, maybe not much to be done)
Bug: 332730534
Test: manual, ZenModeFragmentTest, SetupInterstitialActivityTest
Flag: android.app.modes_ui
Change-Id: I21f13b0842d5b118a341f7d85e8fcac947ca3a06
Physical keyboard options category is hidden when there is no hardware
keyboard. It's related preferences are hidden in this case. Hence those
preferences shouldn't be searchable.
Bug: 351047456
Test: manually search "bounce keys", "sticky keys" and "slow keys",
they're not searchable when invisible on Accessibility page
Test: atest
Flag: com.android.settings.accessibility.fix_a11y_settings_search
Change-Id: I1eb465dd34e59d856bb1fa7c06bc253971a8c8d0
This reverts commit 0359aaeb47.
Reason for revert: <Potential culprit for b/356564046 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.>
Change-Id: I980838773078d822d20608e5975a26cf8dbed2be
If EnforcedAdmin is null, calling setDisabledByEnforcedAdmin does not disable the setting. So if this restriction was applied by a source different than admin, the toggle was still active for users to change (even non-main).
After this change, the restriction is correctly processed both when it is applied by admin or by some other source.
Bug: 356387759
Test: atest MultiUserSwitchBarControllerTest
Flag: android.multiuser.fix_disabling_of_mu_toggle_when_restriction_applied
Change-Id: I5d38e250359ccbee67ac747f1d8a0a2143f4c216
Keeps accessibility activity preference as inheriting from
RestrictedPreference since it shares lots of behavior with the
accessibility service perference (same base class), but always
calls setEnabled(true) for activities.
Fix: 331990900
Flag: com.android.settings.accessibility.never_restrict_accessibility_activity
Test: atest RestrictedPreferenceHelperTest
Change-Id: I39971bc3f65aa630fa62a0e31132f177fd21b635
Test: Verified manually with a device that if face/fingerprint are not
present they do not show up.
Fixes: 350599580
Flag: EXEMPT bugfix
Change-Id: I6a691d2985e4839336e9c08dfa6c97abe23f43f2
