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
(cherry picked from commit 6552bdd0ef)
Merged-In: 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
(cherry picked from commit 36609c18d1)
Merged-In: I3ce9894291ea1f1886f21980a86a92bfce38038a
* Only the Settings app can reset credentials
via com.android.credentials.RESET.
* com.android.credentials.INSTALL should still be
callable by CertInstaller.
Manual testing steps:
* Install certificate via Settings
* Verify unable to reset certificates via test app
provided in the bug (app-debug.apk)
* Verify able to reset certificates via Settings
* Verify com.android.credentials.INSTALL isn't changed
Bug: 200164168
Test: manual
Change-Id: I9dfde586616d004befbee529f2ae842d22795065
(cherry picked from commit 4c1272a921)
Merged-In: I9dfde586616d004befbee529f2ae842d22795065
There's an "Erase downloaded SIMs" option within reset options UI.
When reset EUICC, eSIM profile might get removed.
There's a security feature "Confirm SIM deletion" need to be applied in
this case.
Bug: 194145231
Test: local
Change-Id: I1798dfe347be7d0610a12fb79f103efece2ab240
(cherry picked from commit ebca15a861)
Fix: 195961101
Test: make RunSettingsRoboTests
Test: manual (enroll via settings and verify preferences enabled after enrolling)
Change-Id: Ie50cd862a42c96eb95f2156a33f34748b2b8b50c
This button will be on by default now, so remove the switch
Bug: 185618694
Test: build
Test: make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.display
Change-Id: Iecbeb590a5b750ec2fcf9c31fece5814241200b1
* Split screen into two halves, where the left
side includes the title and the right side
includes the recycler view, floating action
button and action buttons.
* https://screenshot.googleplex.com/6Co6kn2DyXZRGNZ
* https://screenshot.googleplex.com/6uwHAGuRHjNcStN
Bug: 189193577
Test: manual testing via TestDPC
RequestManageCredentialsTest
Change-Id: I9c82a7471c885658aacb40b22166ec801e2833ca
This patch updates the ResetCredentialsPreferenceController to check the
WIFI keystore namespace if called by the primary user.
Test: Install a WIFI certificate or key and watch the
"Clear credentials" button become enabled in the credential
storage dialog of Settings.
Bug: 189601008
Change-Id: I69828b64a7e3c707c27b4582d64ff0ddb863a4ff
- Also rename the extra of page transition.
- Remove useless code while starting activity from fragment.
Bug: 187542491
Test: robotest and manually went through trust agent flow.
Change-Id: I55419f23db7fa77281039e642bde5558c17dce0f
The flow of changing lock screen is combined with Settings and SUW pages
together where their implementation are different, which causes the
page-to-page transition inconsistent. Sub-setting pages will apply
shared axis transition while SUW pages will keep the slide in/out
transition. In order to make these 2 types of page work together, we
intent to use slide in/out transition in the lock screen.
Fix: 174434707
Test: visual verified
Change-Id: I827211e45bcbfdfc558c9d95e6814e62b339b4aa
When alternative fragment is shown for the security settings page, we
don't want to show search results that would lead to an unused security
settings page.
Test: manual
Test: atest SettingsUnitTests
Test: make RunSettingsRoboTests -j
Bug: 184613149
Change-Id: I525bd87d1ac6a24a7a26f59ae917e35ac39732e3
* Move all logics around aggregating password policies
to the controller
* Replace HIDE_DISABLED_PREFS and MINIMUM_QUALITY_KEY
with HIDE_INSECURE_OPTIONS as all call sites are just
using them to hide insecure screenlock options.
* Remove password policy aggregation logic from
ChooseLockPassword and make it use policies passed in.
* Remove padlock from disabled screen lock options,
per UX mock.
* Increase char limit for some strings
Bug: 177638284
Bug: 177641868
Bug: 182561862
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.password
Test: 1. set profile password quality/complexity and enroll device lock
2. set profile password quality/complexity and enroll work challenge
3. set parent password quality/complexity and enroll device lock
4. set parent password quality/complexity and enroll work challenge
5. set profile and parent password complexity, then enroll work challenge
6. set profile and parent password complexity, then unify work challenge
7. Enroll device lock during SUW
Change-Id: Iba1d37e6f33eba7b7e8e1f805f8e37aaec108404
Allows settings applications on other platforms to re-use values by
migrating to Settings.secure and moving HideNonSystemOverlayMixin to
SettingsLib.
Bug: 184967544
Test: atest SettingsUnitTests
Change-Id: If9aaeca29ebb8b481d75622934503e368d7435d3
As I no longer expect to be working on security-related settings, move
myself to the emeritus section.
Bug: 187395769
Test: N/A
Change-Id: Ic91dd36f6de39ef79f1ced90083e1c5c7836c651
There will be multiple biometrics authentications existing at the same
time, so we added a new page for multiple biometrics to control
biometrics settings.
Bug: 183449119
Test: manual test
Change-Id: I359082caf771e07dfd5b24973cb8a3cf372c1b30
Now with two preference controllers, one for enterprise device and one
for financed device, the search index issue (querying "Financed device
info" in Settings does not show a search result) is fixed. The financed
preference controller is used when the device is a financed device.
Otherwise, the enterprise preference controller is used.
Bug: 183551684
Test: Used a test device that is registered via ZT
Test: m RunSettingsRoboTests ROBOTEST_FILTER=EnterprisePrivacyPreferenceControllerTest
Test: m RunSettingsRoboTests ROBOTEST_FILTER=FinancedPrivacyPreferenceControllerTest
Test: m RunSettingsRoboTests ROBOTEST_FILTER=PrivacyPreferenceControllerHelperTest
Change-Id: I051144ec9004f86456285078ebb1c72266f80a55