Active Unlock was guarded behind a feature flag for two main purposes.
1) To select the unlock intent or biometric failure layout. We've
settled on unlock intent, so we no longer need the biometric failure
codepath.
2) To guard the feature rollout. However, the additional platform guard
is not necessary, since this feature availability is still guarded
based on whether the secure settings are flipped to valid targets.
In order to keep the scope of this CL small, useBiometricFailureLayout
always returns false. Another CL will clean up all areas where it and
useUnlockIntentLayout are referenced.
Test: make RunSettingsRoboTests
Bug: b/280306741
Change-Id: I331afe9654b72249d461007c087e7f81783d7625
Change the title of the preference to reflect that Active Unlock can
also be used to unlock the device.
Test: make RunSettingsRoboTests
Bug: b/271782800
Change-Id: Ie227e6dddfc024235fc3568899ef151f14f17696
Update onRetryPrefenceTreeClick to check for the active unlock
preference. If biometrics are not enrolled and we're using the
biometric failure model, launch the biometric setup flow. Otherwise,
launch the component directly.
Test: manual flag flip, confirm activity launches
Bug: 266441818
Change-Id: I8f3ce8f8366b65aad622d33ff7f99f5c82aae3e8
Update the security summary, intro, and unlock your phone summary when
Active Unlock is enabled and enrolled on the device.
Test: make RunSettingsRoboTests
Test: manually flip flags, confirm combined page has updated strings
Bug: 264812018
Change-Id: I2843e9f3aa0f38a9f2ebb18d60fed6293f9ce36e
Modify BiometricsSettingBase to also track if the hardware is supported
and if the controller is a work profile controller. If the hardware is
supported and active unlock is enabled, non-work profile controllers
will still be displayed.
Test: make RunSettingsRoboTests
Test: manually flip flags on device with active unlock, confirm new
layout used
Bug: 264813302
Change-Id: Idb0e994453d4fd5c078c45f87d5d8cee339053a2
