According to Activity#isInMultiWindowMode() API design,
When the Task is in fullscreen windowing mode, and the app is in
ActivityEmbedding split (two activities split left and right),
Activity.isInMultiWindowMode() == true.
With the reason, we should consider additional condidion for
foldable device in unfolded mode, while settings activities
config to embedded activity, we can't only count on
isInMultiWindowMode() for split-screen mode
Bug: 278176550
Bug: 276938441
Test: atest CombinedBiometricProfileSettingsTest
Test: atest FingerprintSettingsFragmentTest
Test: manaul go to split screen mode and try to enroll face
Test: manual unfold device and enroll finger or face
Change-Id: I02bd223f27889e74e67b73051531a5b4554f3de1
When FaceSettings or FingerprintSettings are closed because of onStop(),
this information can't been passed back to previous Preference screen,
CombinedBiometricSettings, because handlePreferenceTreeClick() from
AbstractPreferenceController class only can launchActivity() throguh
preference's Context.
In order to recevice the activity result code from FaceSettings or
FingerprintSettings, add handleBiometricPreferenceTreeClick() method in
BiometricStatusPreferenceController. Then CombinedBiometricSettings uses
this method to show FaceSettings or FingerprintSettings through
launchActivityForResult().
Bug: 263057093
Test: atest BiometricNavigationUtilsTest
Test: Manually open camera through double-click power key on different
pages inside "Face & Fingerprint Unlock"
Change-Id: I99167739766ad5ea5f204b0f0543ba6ad18fac31
Test: atest CombinedBiometricProfileSettingsTest
Test: atest FingerprintSettingsFragmentTest
Test: manaul test- go to split screen mode and try to enroll
face
Bug: 276938441
Change-Id: I45e859b453700aa79f7774fb5deda81b1f30e5a5
When the user has face id registered but failed enrolling in
device lock state, lead users directly to the confirm deletion
dialog in Face Unlock settings.
- When receiving a face id re-enroll extra intent data, lead users
directly to the confirm deletion dialog in Face Unlock settings.
Bug: 233069240
Test: manually force enrolling face id fail, then doing test steps:
1. Receive notification that face unlock needs to be re-enrolled
2. Tap it then entering device
3. Check if showing the confirm deletion dialog in Face Unlock
settings.
Change-Id: I4eb09cf4a7d92a1dd9866c5c8b938aeb8c7eddf5
Update the visibility of button in onStart to avoid missing check
state if Fragment & Activity were restarted
Bug: 269553342
Test: 1. enroll face
2. go to settings > Security privacy > device lock > face & fingerprint unlock
3. Eenter screen lock
4. Click face unlock > delete face model
5.re-enroll face
6.check the UI of face unlock detailed page
Change-Id: I152467afe2cc90932a53fe73b541e97b5b742831
Update the visibility of button in onCreate & onActivityResult to
avoid button flicker
Bug: 191112124
Test: Reference reproduce step in b/191112124
Change-Id: I68e42433631db27e3f8f03ab4fc68e2326852f9b
This removes the top-level UI switch on some of the boolean preference settings.
Bug: 193438173
Test: atest com.android.settings.biometrics
Change-Id: If1cd2cb9ae456021fcdf0efc5002db4a083b9689
Ensures that the lockscreen bypass preference toggle shown on the face
unlock settings screen always uses the correct user ID. This fixes an
issue where the preference toggle for a guest user would use the
primary user's setting when multiple biometrics are supported.
Test: Manual:
1. Turn on Settings > System > Multiple users > Use multiple users
2. Add a guest account and switch to it
3. Enroll a face for Face Unlock on the guest account
4. From the Face Unlock settings screen, toggle "Skip lock screen"
5. Ensure that face bypasses lock screen iff this toggle is on
6. Switch back to the owner account and repeat steps 3-5
Fixes: 193488905
Change-Id: I2da4ce466fe0446cccc9119c90bd322daf627339
Do a few things in this cl
- Use correct way to work with controller.
- Refactor xml file.
- Separate content of footer to two parts.
- First paragraph should become top intro.
- Rest should keep in footer.
Test: Build apk and see the screen
Bug: 173087905
Change-Id: Icb16dedf6b36542b833527471579aaadb5407d87
Screenshot: https://screenshot.googleplex.com/92Jx6zKyTZU8LJa.png
1) Adds a layout for multi-biometric selection in BiometricEnrollActivity
2) Adds widgets for checkboxes
3) Shows ConfirmLock*/ChooseLock* for multi-biometric devices in
BiometricEnrollActivity
4) finish()'s when loses foreground
5) Adds default string for ChooseLock* and multi-biometrics, e.g.
"Set up Password + Biometrics", as well as associated plumbing
to bring the user back to BiometricEnrollActivity once the
credential is enrolled
6) When max templates enrolled, checkbox becomes disabled and
description string is updated
Bug: 162341940
Bug: 152242790
Fixes: 161742393
No effect on existing devices with the following:
Test: adb shell am start -a android.settings.BIOMETRIC_ENROLL
Test: SUW
Test: make -j RunSettingsRoboTests
Exempt-From-Owner-Approval: Biometric-related change
to EncryptionInterstitial
Change-Id: I855460d50228ace24d4ec5fbe330f02ab406cc02
LockSettingsService returns a handle to the gatekeeper password
instead of the password itself now. As such, update areas of code
accordingly.
Bug: 161765592
Test: RunSettingsRoboTests
Run the following on face/fingerprint devices
Test: Remove credential
adb shell am start -a android.app.action.SET_NEW_PASSWORD
Set up credential + fingerprint
Test: Remove credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ChooseLock* logic in FingerprintSettings
Test: Set up credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ConfirmLock* logic in FingerprintSettings
Test: Remove device credential, enroll fingerprint/face. Succeeds.
This tests the ChooseLock* returning SP path from
BiometricEnrollIntro
Test: With credential and fingerprint/face enrolled, go to
fingerprint/face settings and enroll. This tests the
ConfirmLock* path in Fingerprint/FaceSettings
Test: Remove device credential, enroll credential-only, enroll
fingerprint/face separately. Succeeds. This tests the
ConfirmLock* returning SP path in BiometricEnrollIntro
Test: In SUW, set up credential, then biometric. This tests
the ChooseLock* path in SUW
Test: In SUW, set up credential, go back, then set up biometric.
This tests the ConfirmLock* path in SUW
Change-Id: Ibc71ec88f8192620d041bfd125f400371708b296
Biometric enrollment will not request a Gatekeeper HAT during
initial credential setup or credential confirmation anymore.
Instead, it is broken down into the following steps now.
Bug: 161765592
1) Request credential setup / confirmation to return a
Gatekeeper Password
2) Biometric enrollment will generate a challenge
3) Biometric enrollment will request LockSettingsService to
verify(GatekeeperPassword, challenge), and upon verification,
the Gatekeeper HAT will be returned.
Since both LockSettingsService and Biometric enroll/settings
make use of biometric challenges, this allows us to make the
challenge ownership/lifecycle clear (vs. previously, where
LockSettingsService has no idea who the challenge belongs to).
Exempt-From-Owner-Approval:For files not owned by our team,
(StorageWizard), this change is just a method rename
Test: RunSettingsRoboTests
Run the following on face/fingerprint devices
Test: Remove credential
adb shell am start -a android.app.action.SET_NEW_PASSWORD
Set up credential + fingerprint
Test: Remove credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ChooseLock* logic in FingerprintSettings
Test: Set up credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ConfirmLock* logic in FingerprintSettings
Test: Remove device credential, enroll fingerprint/face. Succeeds.
This tests the ChooseLock* returning SP path from
BiometricEnrollIntro
Test: With credential and fingerprint/face enrolled, go to
fingerprint/face settings and enroll. This tests the
ConfirmLock* path in Fingerprint/FaceSettings
Test: Remove device credential, enroll credential-only, enroll
fingerprint/face separately. Succeeds. This tests the
ConfirmLock* returning SP path in BiometricEnrollIntro
Test: In SUW, set up credential, then biometric. This tests
the ChooseLock* path in SUW
Test: In SUW, set up credential, go back, then set up biometric.
This tests the ConfirmLock* path in SUW
Change-Id: Idf6fcb43f7497323d089eb9c37125294e7a7f5dc
The multitude of slightly different launchConfirmationActivity(*)
methods are a big unsustainable pyramid. It's too difficult to
read, too difficult to track which clients are interested in which
parameters, and too difficult to add new parameters, since we need to
1) Read through all of them and find one that's the closest
2) Try not to affect other callers, so potentially add yet another
3) Modify the internal paths, which all basically call each other
until it reaches the biggest launchConfirmationActivity which
has ALL of the parameters
This change should have no behavioral change.
Note: CredentialStorage doesn't need returnCredentials anymore as of
ag/6073449
Test: make -j56 RunSettingsRoboTests
Test: Manually traced code paths for each invocation. A few hidden
dependencies (such as explicitly setting challenge=0 with
hasChallenge=true) were found. Left them the way they were in
case they were intended
Test: Enroll face, fingerprint
Test: Enable developer options
Test: Change to PIN, Pattern, Password, then back to PIN (so each
type requests confirmation)
Test: adb shell am start -a android.app.action.CONFIRM_DEVICE_CREDENTIAL,
authenticate
Test: adb shell am start -a android.app.action.CONFIRM_FRP_CREDENTIAL
(shows confirm credential screen)
Fixes: 138453993
Change-Id: Ic82ef3c3ac2e14d624281921f2d816bcdacbd82b
The internal implementation of generate/revoke in system_server is now
asynchronous. To keep existing clients working, the manager classes
introduce a blocking version of the generateChallenge calls. This change
updates Settings to use the backward-compatible blocking calls.
Bug: 157790417
Test: Enroll fingerprint/face
Test: After enrollment, toggle setFeature or do subsequent enrollment
in face/fingerprint settings
Change-Id: Ib4dfdc5f12530b938ab9b1745f5a19cd9e2eceee
Sometimes Settings Search show the items that are not supported by
the hardware. e.g. FaceLock.
Add log to check the HW status when the problem occurred.
Bug: 156667203
Test: watch the log output.
Change-Id: Ie6a89f338aac6f7bdefc69fc84cfa5bf848ed015
In current design, we only check the hardware support for face unlock to
show/hide the face unlock results in Settings Search. However the face
settings page is not launchable when the user doesn't enroll the face
unlock. It will cause user confused that face unlock results is no
response when they click them. Therefore, it's more making sense to add
enrolled status checking to index the face unlock results.
Test: manual and robotests
Fixes: 157954564
Change-Id: I5dd36e15fe48d537ee499c73cc172fc913b39554
setActiveUser is removed from the @hide API surface and is no longer
necessary. The framework ensures that the correct user is set without
an explicit call, since userId is sent as a parameter to each of the
methods already.
Bug: 157790417
Test: See testing from frameworks/base change (12/n) from the same
gerrit topic
Change-Id: Id88b818ed0bb1f75f18ac8e9ba7aff2a9b80b319
Add the check condition in the getNonIndexableKeys to
check if the FaceManager exist or not.
Fixes: 147076221
Test: manual
Change-Id: I898c936403ce90869a9da28aa14297eb6bf5d730
Currently, there are some biometric security setting and enrollment
screens which remain open after the user has backgrounded them. This
means that they can later be resumed without requiring the user to
confirm their device credential as normal.
This commit fixes the issue in AOSP by adding logic to the affected
biometric enrollment/setting activities in to finish() with
RESULT_TIMEOUT in onStop(). We don't want to finish() these activities
prematurely if the user is currently in a wizard setup flow, however. In
that case, this commit ensures that the newly added logic will not run.
Test: Pixel 3 - Background at each step of fingerprint enroll => finish
Test: Pixel 3 - Rotate at each step of fingerprint enroll => no finish
Test: Pixel 3 - Proceed though fingerprint setup wizard => no change
Bug: 142544519
Change-Id: I8ec0fa1e30bafe097d9dc82991ff786ebf24844b
- Index the delete face unlock preference and set up face unlock preference.
Fixes: 147031175
Test: manual
Change-Id: Ia984a116947d0c2e6a909f53914d081e25496f87
- FaceSettingsLockscreenBypassPreferenceController's preference key
is different from that in xml. Use DashboardFragment generic way to
create PreferenceController which bind the preference key defined in
xml.
- Also refine the way of fixing b/140878309
Fixes: 145893081
Test: manual check FaceSettings and Notification Settings
Change-Id: Ia80e755e3f86b44e771b0cf80c9bf53a8ef8f430
Bug: 140878309
Test: the option is not grayed out for secondary user.
Change-Id: I2413aa3c634e89a90d104e9ad60df15e49c75ed2
(cherry picked from commit e17caeea3f)
- We destoryed the MediaPlayer when VideoPreference is onPause().
When VideoPreference is onResumed, MediaPlayer always start from
pause state, we don't need a data save/restore current video state.
Bug: 143270527
Test: robolectric, manual
Change-Id: I544e933e4237f6d92aeff8a7eb04b52e89d74a4a
- Use SettingsLib Indexable
- Directly use resource id in getPreferenceScreenResId
Bug: 135053028
Test: roboletric
Change-Id: I05f493b55e8b6e2091301e9231ba5615215618e6
- Add function getXmlResourceId, Fragments don't need to write
xml resource id twice.
- Remove getPreferenceControllers from Indexable.java. Because it will
move to SettingsLib later for other apps which don't need this function
Bug: 135053028
Test: robolectric
Change-Id: I1e74519aecdea3dde64a5aea79f08d766dbc0003
Users may have trouble finding this setting in face auth.
Heard this from dogfood/executive feedback and customer support discussion.
So add Skip Lock Screen preference in
Display > Lock screen display > What to show >
and
App & Notifications > Notifications > Lock Screen >
Bug: 138458558
Test: robotest & manual
Change-Id: I10e420821423821743d65b00c8b7e6d4d1224e00
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
