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
When accessibility services such as talkback are enabled, and the
user tries to start the non-accessibility enrollment flow, present
a confirmation dialog.
Fixes: 152633740
Test: Enable talkback, start enrollment
1) Accessibility flow --> no dialog, as expected
2) Non-accessibility flow --> new dialog shown
Test: No talkback, start enrollment. No dialog shown in either case
Change-Id: I0cd07a9d0012f6c9bea36e74365a6707755d3ab7
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
Allows it to be used in more projects
Bug: 154161590
Test: Manually opened each setting that was impacted
Change-Id: Ife59074e5f8ffa76c2c81cca4022ca200bb59526
Fixes: 151576034
Test: Wipe device, go past fingerprint enrollment in SUW, press
back button. SUW should not get stuck
Change-Id: I9021946dd169acfa205e6bacc4c4581242452983
SUW is using activity result codes already. Let's stick with the old
behavior until/if there's a way to make it work nicely.
Fixes: 151058692
Test: Skip fingerprint in SUW. Fingerprint not shown again in SUW.
Change-Id: I3c52cddd568dc5ded6bf810272ffb77f0841c692
Fixes the following issues related to fingerprint/face in Setup Wizard:
- Ensures super.onStop() is called by all enrollment-related Activities
Test: Proceed through Setup Wizard on factory reset Pixel 3 XL
Before: Periodic crash dialogs and stuck on fingerprint enrollment
After: Able to proceed through wizard and enroll fingerprint normally
Bug: 147325159
Change-Id: I76eb8c944140aa68f78eaea3702f440102b779c6
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
Bug: 145601433
Test: adb shell am start -a android.settings.BIOMETRIC_ENROLL --ei "android.provider.extra.BIOMETRIC_MINIMUM_STRENGTH_REQUIRED" 1
Test: Log is seen
Change-Id: Ied5fba6de257f72a809536402d7afc8061570abe
- 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
The check logic of this preference requires a page loading prior to
slice auto convertion, so it is not suitable to become a slice.
Converting it to a slice will lead to an app crash.
Fixes: 145723632
Test: robotests
Change-Id: Ie6eafb244e9a1cc9267f6b747c8e357d239e688e
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
