During a run of the setup wizard, a tester one time encountered a case
where the 'Accept Legal terms' screen followed by the Security screen
showed for a second time after already confirming the pattern in the
Security screen. The logs showed a crash in
FingerprintEnrollFindSensor.onActivityResult which could only have
happened if it was called with a requestCode of CONFIRM_REQUEST and a
resultCode of RESULT_OK, but a null Intent.
This isn't an expected flow, and AFAIK we haven't been able to reproduce
the original problem, but it seems reasonable to at least not crash in
settings, so this CL defends against that crash by just calling finish()
in this case, which means the caller who started the
FingerprintEnrollFindSensor will see the default result code of
Activity.RESULT_CANCELLED.
Bug: 80099085
Test: make -j RunSettingsRoboTests
Change-Id: I94401eabe295e4d5396cf7d324fbf1902dc45f6d
- After the user finished adding lock screen, if the user tries to skip
fingerprint setup, show a confirmation dialog
bug: 64092225
Test: Manually tested; robolectric tests also added
Change-Id: Iba5088a9db93153988942cf78f11077f427e50cb
Remove the next button (so the user has to touch the sensor to
proceed), and add a skip button.
Test: cd tests/robotests && mma
Bug: 62839648
Change-Id: I555948ac2f3235e08b91f0957aa8e0ce24535c08
Some illustration view can manage their own start-stop lifecycle and
doesn't need to be handled by the activity.
Make mAnimation null if the animation is not an instance of
FingerprintFindSensorAnimation.
Test: cd tests/robotests && mma
Bug: 38463695
Change-Id: I41989e5cb0639407f58d9c8edda0eef93adbf2e8
Test: There's a condition where FP enrollment fails and a fragment
transaction/commit occurs after onSaveInstanceState. We should be
using commitAllowingStateLoss() instead of commit()
I'm not able to repro this issue but from looking at the stack
trace this should fix the problem.
Fixes: 38432354
Change-Id: I56b9c8d2efc45e9d77f29b897280f5378c3a84a0
Consolidated the many variants of ChooseLock*.createIntent, so that
it will take the same set of arguments.
Also modified SetupChooseLock*.createIntent to modifyIntentForSetup,
which will take the intent created by ChooseLock* and modify it for
use with setup.
Test: cd tests/robotests && mma
Change-Id: I5ff033f459c33ec9980872a536b3996d89f2bbbb
Bug: 30681771
Test: SettingsUnitTests
Refactor visibility logging from InstrumentedFragment into a mixin. And
apply mixin in remaining fragments.
Change-Id: Ibbb59904336254a3e4bb9e8c7d0b36e5a6bc2622
Adds a pause command that doesn't destroy the video surface, and calls
onStop when we want to destroy the media player.
bug:26516460
Change-Id: If46d26088e81fdca6a73a663a48901bb5245acc8
Because there's no way to listen to the fingerprint
sensor without enrolling or authenticating, we start a short
enrollment session to detect first press of a finger to
advance to the next stage.
Change-Id: If242ade8729f34464171cda54deab0922ad85b1d
This adds an optional overlay to specify a per-device
movie to illustrate enrolling a fingerprint. To enable,
create a new layout overlay for
fingerprint_enroll_find_sensor_graphic.xml using
FingerprintLocationAnimationVideoView
Fixes bug 22954305
Change-Id: I59294f71617ecf7a9bf09603fc0b068cc5aa8ff9
When rotating the ConfirmDeviceCredentials Activity, it was launched again after
solving the challenge.
Bug: 23937676
Change-Id: Ic0852448f498c79d5448c72cbc31bb55d9bfeddb
- When finger can't be analyzed for enrollment
(FINGERPRINT_ERROR_UNABLE_TO_PROCESS), tell the user
to try again or use a different finger.
- When timeout is reached (FINGERPRINT_ERROR_TIMEOUT),
stop enrollment and ask the user to try again.
Fixes bug 23546104
Fixes bug 22708384
Change-Id: I879874b53dd0d928093fab1c92d0d4d68d73be28
instrument visibility on all fingerprint views
rename and delete action
add fingerprint action is implicit in flow
Bug: 22951001
Change-Id: I53f048f479e24754972b801598d5da393ba9d716
Show a skip button during enrolling in case the user entered the flow
accidentally. The skip button will send the result code RESULT_SKIP,
which is equal to RESULT_FIRST_USER + 1, back to the starting
activity.
Bug: 22666389
Change-Id: I230b04e5150214c31536ac282d56b7b490c85ac1
Forward the result in the enrolling screen from the finish screen,
so that if the user presses back in "Add another" after enrolling
the first fingerprint, it will return RESULT_CANCELED instead of
RESULT_FINISHED, and go back to find sensor screen.
This results in the following behavioral changes:
- RESULT_FINISHED will only be sent if the user presses "Done" in
FingerprintEnrollFinish. If the user clicks back in
FingerprintEnrollEnrolling, they will always go back to the
previous screen with RESULT_CANCELED, which would either be
FindSensor or FingerprintSettings.
- If the user presses back in FingerprintEnrollFinish, which is only
possible outside of Setup Wizard, they will be back in Find Sensor,
and pressing next will enroll an additional fingerprint.
- Edge case: if the user enrolled the maximum number of
fingerprints, and presses back, they will be bounced all the way
back to Settings > Security.
Bug: 22552741
Change-Id: Ifc5e8a9150491b4303e01ebd0fc17b6d39dd372d
