Dialogs are not a part of view hierarchy so if the dialog loses focus, it cannot be reached by traversing.
When it is places within full-screen activity, then the focus is captured within activity and returns to the dialog. If the activity was embedded in the right side pane, like the dialog used to look, the dialog would be accessible by traversing but the focus would be granted to the left pane of Settings app. Therefore this UI change is required.
Bug: 376815882
Test: atest UserSettingsTest
Flag: android.multiuser.place_add_user_dialog_within_activity
Change-Id: If9f280573d2b0da8deedcdeaeffc9db6160f27a0
Really, profiles aren't expected to open Settings at all. But if they
do somehow, the overflow shouldn't appear.
Bug: 352542820
Flag: EXEMPT bugfix
Test: Try to access the overflow of the work profile by launching its Settings in
adb shell am start --user 10 'com.android.settings/.Settings\$UserSettingsActivity'
Change-Id: I5e4c095cda3e19fa5c63c2c550a526f5da8ec5c1
This prevents flickering if the preference is meant to be hidden.
Bug: 373269781
Test: manual
Flag: EXEMPT bugfix
Change-Id: Ibf1e1915e9ad872bdaaba30fb7fa9047665531f7
Bug: 371202325
Test: manual: 1. Open settings 2. Search "Add user" 3. Verify "Add supervised user" does not come up
Flag: EXEMPT bugfix
Change-Id: Iaf96bd8d7ffde4f9d09f14af1de422e1b1d39eda
If USER_TYPE_FULL_RESTRICTED is disallowed, addUserPreference is renamed to only mention user. But search results still state default name "Add user or profile". This change updates this entry in the search index.
Bug: 365899560
Test: atest UserSettingsTest#testGetRawDataToIndex_returnAllIndexablePreferences && atest UserSettingsTest#testGetRawDataToIndex_addRestrictedProfileAllowed_addUserTitleIsCorrect && atest UserSettingsTest#testGetRawDataToIndex_addRestrictedProfileDisallowed_addUserTitleIsCorrect
Flag: EXEMPT bugfix_only
Change-Id: I3c26180225491e4916141a3fca9d2e7ab36e8cfc
The toggle state used to be set on creation and only changed onSwitchToggled(). But the state can also change when restrictions are applied from outside of settings, or when user is added with toggle being off by default.
This change updates the state during execution of onResume() in Users Settings, which also aligns with the update strategy of other Toggles on this Settings page.
Bug: 362706097
Test: atest MultiUserSwitchBarControllerTest
Flag: EXEMPT bugfix
Change-Id: I8a994b2e0ddb672362e69653374b87f85ae1548c
Before multiple admins were introduced, only main user could be an admin and that status was not modifiable. But now it can be updated for non-main admins of the device. So it is important to refresh this value to keep it up to date.
Bug: 359466920
Test: atest UserCapabilitiesTest
Flag: EXEMPT bugfix_only
Change-Id: If39ad24b10daf6886f402926b3bab23b50201c98
In the process of creating a user through the Settings app, if the current user has the DISALLOW_GRANT_ADMIN restriction, the dialogue for granting ADMIN privileges will be hidden after this implementation. This action ensures that even if child users can create SECONDARY users, they cannot create ADMIN users.
Design doc: go/unicorn-hsum
Bug: 357819541
Test: manually verified the user is not allowed to create ADMIN user when DISALLOW_GRANT_ADMIN restriction is applied.
Flag: android.multiuser.unicorn_mode_refactoring_for_hsum_read_only
Change-Id: I4b40f83b50d4de0af103d4f5ca400e42345144e0
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
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
Rather than use the raw Intent, we make a copy of it. See bug.
Bug: 330722900
Flag: EXEMPT bugfix
Test: manual
Test: atest com.android.settings.users.UserSettingsTest
com.android.settings.users.UserDetailsSettingsTest
Change-Id: Id74e4b7ae261f2916eedaef04a679f83409a4b67
Before this change these actions were hidden.
After this change, they are displayed but disabled which makes it more intuitive.
Bug: 336762423
Test: atest UserSettingsTest && atest UserDetailsSettingsTest
Flag: android.multiuser.new_multiuser_settings_ux
Change-Id: Ie07816b7d3817d12e78e1ec2692fcddea9328933
Before, when the restrictions were applied, the preferences that were restricted were hidden.
After this change, if admin applies a restriction, the preference is displayed as disabled and Policy Transparency Dialog is displayed
Bug: 338226475
Test: atest UserSettingsTest && atest UserDetailsSettingsTest
Flag: android.multiuser.new_multiuser_settings_ux
Change-Id: I1b5aeeeec7accde278ff3e46ea3d64c91d8400db
The name "Allow multiple users" is too ambiguous. It sounds like by toggling it off, the feature is completely disabled. In fact, it only hides user switcher. In conjunction with hiding other users from the list, it makes it appear as all the users get deleted when the toggle is off. On the contrary, users might be running in background when the toggle is off.
After this change, the new name better represents the intention behind this toggle, as well as makes the UI more intuitive. The users are not being hidden anymore. But switching preference gets disabled.
Since the toggle can only be enabled or disabled by owner (after this refactoring), it means that Owner has full control over multiuser settings and is able to perform actions on users without having to enable the toggle.
Bug: 336762423
Test: atest UserSettingsTest && atest UserDetailsSettingsTest
Flag: android.multiuser.new_multiuser_settings_ux
Change-Id: Id9d507039b58d3df66fe78710409716fd4816890
Before this change, Delete action was disabled for all uninitialized secondary users.
Bug: 341840847
Test: atest UserDetailsSettingsTest
Change-Id: Icd43836f577dd061d267f6fb75658c35a0c47589
Only let main user (Owner) change state of the toggle
Bug: 336764498
Test: atest MultiUserSwitchBarControllerTest
Change-Id: Ib694d1cb4685764c64633efc090765b470a0a015
Currently, if Settings applies CALLS or SMS restrictions to a user, that
restriction doesn't propogate to its child profiles. It should.
This is actually a no-op right now, since it's not possible to have a
profile on a user that isn't the Admin user anyway. But one day such a
thing may be allowed, so this implementation is more future-proof and
safer.
Test: Manual verification that applying the restriction continues to
work properly a full user
Test: UserDetailsSettingsTest
Bug: 261469887
Change-Id: Ib19cecbd37b6efc90f9655565295e7856427f049
Send information to avatar sync service that user selected confirm or cancel on edit user info dialog
Bug: 320656026
Test: manual
Change-Id: I84356b844d47ea7c07f662691f1e48eaca56b7d8
Revert submission 25262217-fix_mu_for_cope
Reason for revert: This issue requires a different approach to the solution.
Reverted changes: /q/submissionid:25262217-fix_mu_for_cope
Change-Id: Ic6e8afd76cb0af88612cf5a6cd34a0c7f50759c4
When multi-user feature not supported in framework, SettingsIntelligence should not build the index of multiple users for searching.
Return empty list when multi-user feature not supported during building search index.
Change-Id: Id2fb8f2066784d63bbfd5c396da88b04306a3563
Bug: 310108420
Bug: 304359233
Test: set up device in COPE mode and check toggle in Settings -> System -> Multiple Users
Change-Id: I0edd58651f94c9f9a51349025a29e33a1e1a9c14
Switch and SwitchCompat are both CompoundButton.
Using CompoundButton in Java will helps migration in the future.
Bug: 306658427
Test: manual - on affected pages
Change-Id: I7cdc2601879a85d33f77239e38263320d5a6984e
SwitchPreference and SwitchPreferenceCompat are both TwoStatePreference.
Using TwoStatePreference in Java will helps migration in the future.
Bug: 306771414
Test: manual - check Settings pages
Change-Id: I84e1d7b09451106797c2b23d127855c6976678ca
Revert submission 24420426-multi_toggle
Reason for revert: This change needs to be done along with some other UI changes to avoid confusion
Reverted changes: /q/submissionid:24420426-multi_toggle
Change-Id: Ife2e03d0090fefcb4c1fa53dd007336759eb1bc7
