* If organization name has been set for
a managed profile, work challenge
should display it as the header.
Bug: 155274026
Test: manual testing
Manual Testing Steps
* Set up device with managed profile
* Set organization name via TestDPC
* Go Settings > Security > Work profile security
and add a work profile lock
* Select 'Work profile lock' and verify
organization name is shown in header
Change-Id: I83209383fd2cf9179c34ccfdf8c097c379ec933e
Allows it to be used in more projects
Bug: 154161590
Test: Manually opened each setting that was impacted
Change-Id: Ife59074e5f8ffa76c2c81cca4022ca200bb59526
When unifying work profile challenge, keep the device lock
as long as it will still meet password requirement after unification.
If not, prompt the user to set a new device lock and only unify
work challenge after a compliant device lock is set.
Bug: 148630506
Fix: 149682344
Test: make RunSettingsRoboTests
ROBOTEST_FILTER='ChooseLockGenericTest|ChooseLockPasswordTest|ChooseLockPatternTest|LockUnificationPreferenceControllerTest'
Change-Id: I99cde2650902927f6a4cc7c0cc7c6016e0dc283f
- Assign metrics category to perferences at an earlier stage in
DashboardFragment for better usability.
Bug: 137559984
Test: robotest
Change-Id: Icd4185efa0e655be20c4b673a1380fa42140923f
CDCA is a transparent activity with the sole purpose of
requesting authentication. Since authentication is all drawn
by SystemUI, we should also stop this activity from drawing
the StatusBar.
Register to receive biometric system events (early user canceled),
so that we can finish() and start the activity transition
simultaneously. This fixes some navigation bar jank.
Bug: 148273355
Test: Set up a work profile, then install BiometricPromptDemo
Disable one-lock and set up a password/biometric for the
work profile. Lock/unlock screen, then open the work
profile version of the app. No status bar jank seen.
Change-Id: I54a352527ed007dcaf1bea14a51711e4022fe028
With an associated change to the UI of the BiometricPrompt credential
view, this commit preserves the current appearance of the CDC auth flow
by promoting the "details" string from the description to the subtitle
field of the prompt.
Test: Manually, using the TestDPC app
Bug: 152053691
Change-Id: If1d773f7f9a7b141520eac70a6cd64c09eb27f20
For work challenges, do not reset incorrect password attempts if
challenge is resolved via biometric authentication. This is the
behaviour for personal keyguard and work challenge should be
consistent.
Bug: 139438785
Test: manual: enroll work challenge with fingerprint, set failed wipe
count (3) via TestDPC and attempt two failed attempts (via cmd
lock_settings). Resolve work challenge with fingerprint and attempt one
last failed attempt. Verify work profiel is wiped.
Change-Id: Ic64d3e44f3faa5adf8ac43db09e33c8403427990
The device management app may run before the end of device provisioning,
and it may start SetNewPasswordActivity. If this happens, use
ChooseLockGeneric instead of SetupChooseLockGeneric. Only use
SetupChoseLockGeneric if SetNewPasswordActivity was started by Setup
Wizard itself.
Fixes: 151552453
Test: atest com.android.settings.password.SetNewPasswordActivityTest
Test: atest com.android.settings.password.ChooseLockGenericTest
Test: Manually run consumer and enterprise device setup
Change-Id: I3b479ed18211d6625654f266fe692f07d0047e4f
Currently if a work profile with a separate lock is turned off
(a.k.a. in quiet mode), and the user has forgotten the password,
profile owner app cannot use DPM.resetPasswordWithToken because
the profile user is not running.
In BYOD case the user can remove and re-provision the profile but
in the new COPE mode (a.k.a. on an organization owned device with
work profile) it is not possible to remove the profile. So full
factory reset is required.
This CL allows the user to start the profile in locked state
(a.k.a direct boot mode) so that the admin can reset the password.
This CL adds "Forgot my password" button to work profile credential prompt
if all of the following conditions are true:
* Work profile is turned off
* Profile owner app is capable of running in direct boot mode.
* Profile owner app has an active password reset token.
* The device is an FBE device (otherwise profile will be unlocked).
Clicking this button starts the profile in locked state and shows an
activity to the user that instruct them to go to their IT admin.
Bug: 143516540
Test: manual
Change-Id: I832f7121b43e39161c5afa816f44ce89584b66e2
Invokes the new hidden API to allow the work authentication prompt to
supply specific text to BiometricPrompt for credential auth. This
allows the prompt to use work-specific language when verifying work
credentials, while retaining more generic language when authenticating
with biometrics.
Test: Work lock prompt shows "Enter your work ___" for credential
Test: Work lock prompt now shows "Verify it's you" for face
Bug: 149003660
Change-Id: Icab8e16702ca31d08fa8b0b00f0519c9a37f609f
* Updated text and description for PIN, password and pattern
* Added enterprise logo to work profile lock
Bug: 141290838
Test: Manual testing
atest com.android.systemui.biometrics.AuthBiometricViewTest
atest com.android.systemui.biometrics.AuthContainerViewTest
Change-Id: Iac6c9ca15e7446cbd7cce9fc1a1ac4e1c867bf31
* The incorrect string was being displayed when the user
was asked to enter their pin/password.
* Updated the string to include **work** instead of
**device** when entering a work pin/password.
Bug: 148211118
Test: Manual testing
Change-Id: I2239a5011dec62fd63574bbf75495548ddd0d907
CDCA no longer needs to cancel authentication in onPause. Since it
internally invokes BiometricPrompt, and BiometricPrompt's components e.g.
BiometricService and AuthController are aware of the "top-ness" of its
client, this code is redundant.
Fixes: 145991060
Test: Follow comment#3 in the bug above, repeat 10+ times
Test: Set up work profile, set up work profile password. Open work profile
app, but before entering password, swipe up to go to home screen.
Authentication is cancelled as expected.
Change-Id: I0b4d7d89cb9801ddbb6e3bd07f71191035cc75ec
* Updated FrameLayout of work profile lock in Settings to use GlifLayout
* Removed old background image of work profile lock
* Updated text for PIN, password and pattern
* Added enterprise logo to work profile lock
Bug: 141290838
Test: Manual testing
atest com.android.settings.password
Change-Id: Ie09974857b6c76a182a8075b9e1964a2e0af0de9
Test: Verified disabling fingerprint will not allow
the user to unlock work apps with fingerprint. (But can use fingeprint
within apps.)
Test: Verified disabling face and/or iris on a fingerprint device will
continue to
allow the user to unlock work apps with fingerprint.
Test: Verified disabling face on a face authentication device
will not allow the user to unlock work apps with face authentication.
(But can use face
authentication within apps.)
Test: Verified disabling fingerprint and/or iris on a face
authentication device will continue to allow the user to unlock work
apps with face authentication.
Change-Id: I2f72a85f39ec539e6c6bc2cf710ed2f5ebeb5f9a
- Search box is hidden if user set intent extra isSetupFlow true
Fixes: 135717823
Test: search box is hidden in the following command
adb shell am start -a android.settings.SETTINGS --ez isSetupFlow true
Change-Id: Ia3d955c9390d6b0eef9391b9b35b6a483eb63d26
Test: Verified disabling fingerprint will not allow
the user to unlock work apps with fingerprint. (But can use fingeprint
within apps.)
Test: Verified disabling face and/or iris on a fingerprint device will
continue to
allow the user to unlock work apps with fingerprint.
Test: Verified disabling face on a face authentication device
will not allow the user to unlock work apps with face authentication.
(But can use face
authentication within apps.)
Test: Verified disabling fingerprint and/or iris on a face
authentication device will continue to allow the user to unlock work
apps with face authentication.
Bug: 141382589
Change-Id: I74135dd9f6afb1b789302ad0af3daf8a73a4181b
If the user currently doesn't have a password and transitions
into another empty lockscreen (none -> swipe or swipe -> none),
there is no need to call setLockCredential.
Bug: 142701762
Test: Not yet :(
Change-Id: I553c8b30c7414775185d632660d962a73607baca
Previously, the biometrics were only cleared if the password was cleared from the Settings.
Moved the logic from the Settings app to the system server side.
Now, the biometrics will be removed no matter how the password is cleared (Settings, adb, TestDPC).
Bug: 130653263
Test: Atest LockSettingsServiceTests
manual testing from Settings, adb and TestDPC
Change-Id: I864b93404ec5cadb0685ac5d41376bf64ebde6f7
Bug: 140128468
Test: Verified with biometricpromptdemo that confirm device credential
still works correctly.
Change-Id: I0f608ba1256c696317402f56549452bf6933066b
Fixes: 132156012
Test: Verified with BiometricPromptDemo that talkback now
announces the correct password type for PIN/Pattern/Pass.
Change-Id: I3a04fe691140abba40396f95a601f863d87ee394
Removed the FooterPreferenceMixin from the ChooseLockGeneric page.
Fixes: 139269907
Test: manual test
Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password
Change-Id: I86e294015354c0a6a6311441892a770503382d1f
If user enters face settings but does not enter the password, then
turns off the screen, it's possible the challenge is invalidated. Instead,
we should finish() the device credential screen as well as FaceSettings.
This prevents
1) The user from being prompted for credential with lack of context
2) Credential returning a HAT that wraps an invalidated challenge
The user will be returned to the security settings screen, where they
have more context and can decide if they want to enter face settings again.
Fixes: 138273242
Test: 1) Open face settings, do not enter password
2) Press power button
3) Unlock keyguard
4) User is not presented with credential screen
Test: Go through SUW, turning on/off the screen at various security
screens. Able to enroll successfully
Change-Id: I3c3d4600138012821bb0eea7d2927df00011cdb0
Currently we always send cancel() if ConfirmDeviceCredentialActivity
goes into the background. However, if the biometric state is no longer
authenticating, requesting cancel() in this state will result in an
inconsistent state between BiometricService/client and
ConfirmDeviceCredentials.
BiometricService/client will receive the ERROR_CANCELED message incorrectly,
while ConfirmDeviceCredential is showing / pending user password. When
the password is entered, its result is ignored.
The correct behavior is for ConfirmDeviceCredentialActivity to invoke
cancel() only if it's still authenticating. Otherwise BiometricService
and its client will receive ERROR_CANCELED, instead of the actual password
auth result.
Bug: 138279856
Test: BiometricPromptDemo, enable device credential fallback, get into
lockout state, successfully enter password. API result is
success instead of "canceled" now.
Change-Id: I6521e896d0402fe856dc85476f51149c9b3084a8
For devices which provide biometric authentication options, such as
fingerprint or face, we should be showing different content on the lock
setup screen during the corp account setup wizard. Namely, the title
should read "Choose screen lock", and the "Not now" option should be
changed to "Continue without [auth method]". However, we currently only
check for whether fingerprint authentication is available, leading to
incorrect text for devices with face authentication.
This CL fixes the issue by changing the introducing a private method to
check for any biometric authentication (currently just mForFingerprint ||
mForFace). It then uses this method in place of the existing
mForFingerprint checks in SetupChooseLockGeneric.
Test: On a device with fingerprint auth and one with face auth:
1. Set a work profile with TestDPC and add some password quality requirement
2. adb shell settings put global device_provisioned
3. adb shell am start -a android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD
4. Verify that the correct content is now shown (screenshot/xZPVtpa3j3Z)
5. Verify that setting lock with and without biometric auth still works
Fixes: 136556653
Change-Id: I46d3c964f05986aa97cc8ed77fe0ac125337ddd0
If the calling app has admin rights (DA/DO/PO), don't display footer
text that the calling app is 'recommending' that a password is set.
Fixes: 131888973
Test: atest com.android.settings.password.SetNewPasswordActivityTest --verbose
Test: atest com.android.settings.password.ChooseLockGenericTest --verbose
Test: manual
Change-Id: I32785d33e6425416fc1dbba24540ece8917b58f3
Converting to Soong will move some code from directly compiled
into the app to compiled into an Android library and then
shared between the app and the tests. This will cause resource
IDs in the library to become non-final, which means they can
no longer be used in case statements. Convert affect case
statements to if blocks.
Test: m RunSettingsRoboTests
Change-Id: I25742a374f06d3fa4decbfc0d223a350acc50881
These classes are casting view to LinearLayout unnecessarily. Later we
might change the root view away from LinearLayout. The cast will cause
crash.
Bug: 132182711
Test: go through SUW.
Change-Id: Iea31882f8edea0c87ef8e95b4da9b6bffa8ea7d0
