1. remove the dependence of setupwizardlib.
2. add to use setupcompat and setupdesign.
3. modify new footer button in following up cl.
Bug: 120805516
Bug: 120872944
Test: RunSettingsRoboTests
Change-Id: I463dd35b799d4250b2aabce0cb0b8102cf9dd7d6
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
Bug: 110589286
Test: manual
Test: make -j56 RunSettingsRoboTests
Test: setting up new fingerprint still works
Change-Id: I1b7d2bb6bb417dae2c99e5abeb68d3f694cb3cb8
Currently minimum password length policy is queried twice:
1. When constructiong the intent in
ChooseLockGenericFragment.getIntentForUnlockMethod and then
passed into setPasswordLengthRange in getLockPasswordIntent
2. in ChooseLockPasswordFragment.processPasswordRequirements via
LockPatternUtils.getRequestedMinimumPasswordLength().
These two values are then combined in processPasswordRequirements
using Math.max(), which doesn't make sense since it is the same
value.
With this CL it is only queried once in processPasswordRequirements.
+ cleaned up code filling in unused list.
+ removed unused extras, since they are never set anywhere.
Bug: 30558331
Test: atest ChooseLockPasswordTest
Test: atest SetupChooseLockPasswordTest
Test: atest ChooseLockGenericTest
Test: manual, set password policy and change password.
Change-Id: Ifc4946d5b3b26131da01178fa9c827de7a52c7c6
When a number of min length of a string is singular,
the definition of <plurals> can show a localization with a correct
grammar for singular.
Bug: http://b/78537276
Test: Manual
Change-Id: Ic5d94078f1c80a81a37ff7c11d5d5e106a764bed
This is part of the fix that upgrades the hashing of password history
to a more secure design.
Bug: 32826058
Test: manual
Change-Id: Ib022c8db1f7b63f75b69d0177fa5f6be528a83c5
Fix the previously-missing case where the user elects to set
a password (instead of PIN), but still sets a numeric password
that contains repeated sequence which should be blocked by admin
policy.
Bug: 72039850
Test: Set NUMERIC_COMPLEX password quality, then attempt to
enroll a repeating numeric PIN as lockscreen *password*
Change-Id: I7c7525716b37a5330147b899b80026ca71c3ce0c
Fixes: 70561469
Test: try to setup a password/pin, but type in a wrong pw/pin
when confirming. the button should stay as "confirm" instead of
reverting to "next"
Change-Id: Iea570c2d869b9d561b26046d30d08f40abca0c93
- for fragments that do not implement the preference screen, change them
to inherit from InstrumentedFragment instead.
Change-Id: I791c2634024bd2c248efea955be5c680180d735c
Fixes: 68277111
Test: make RunSettingsRoboTests
If the password is valid by all other checks, see if it is present on
the blacklist and disallow it if it is.
Test: set a password blacklist, try and set a blacklisted password and
see an explanation, set a non-blacklisted password successfully.
Test: make ROBOTEST_FILTER=ChooseLockPasswordTest RunSettingsRoboTests
Bug: 63578054
Fix: 65659151
Change-Id: Id155b824ad4b5839c23b6f5fd3fdfdcfc78c3df1
Currently the only way mUserPassword can be set is when it comes
from onActivityResult. This way when the user chooses "Continue
without Pixel Imprint", and we switch ChooseLockGeneric->InternalActivity,
mUserPassword becomes null (it is not preserved in intent extras).
And then this null is used in getLockPasswordIntent which causes the issue.
Another issues is that when the user chooses to use fingerprint,
mHasChallenge is set to true and password is not forwarded to
ChooseLock(Password|Pattern). I changed the intent builders so that both
old password and challenge can be sent at the same time, so the password
is not lost when fingerprint is set.
Bug: 67672081
Test: cd packages/apps/Settings/tests/robotests/ && mma
Test: manual, adb shell am start -a android.app.action.SET_NEW_PASSWORD,
tried setting pin/password with and without fingerprint.
Test: manual, tried to change lock via Settings -> Security&Location
Test: manual, set pin + fingerprint in Setup Wizard, FBE and FDE devices
Test: manual, set pin + added account, used pin to unlock FRP in SUW
Change-Id: I38d56d84f95c63fef24c2aa1a031d629f22756a1
The source string was removed but there are still references to it.
Updating the references as well in this CL.
Test: mma with ANDROID_AAPT_IGNORE on locale files
Bug: 64763091
Change-Id: I43ef63207e884cbaa92ff3853b0f1fd690cf05f8
Use fingerprint icon when lock screens are loaded on
fingerprint setup's behalf.
bug: 63809908
Test: Manually tested and verified. Also added robolectric tests
Change-Id: I773a1eec2466e7ab626cc3330f5ce987a21b048f
Currently The activity not requesting showSoftInput() and hence keypad
doesn't show up.
Activity.onResume(), we should call ImeAwareEditText.scheduleSoftInput()
to request schedule ShowSoftInput() when EditText gains focus.
Fixes: 63582564
Test: Manually launch com.google.android.setupwizard/.SetupWizardTestActivity
Change-Id: Ib75ba0f361b8b46c3b717cc1ffb864726958ed82
Hide the screen lock options button in the confirmation stage of
SetupChooseLockPassword, so the user cannot skip out of that screen
while the screen lock is being saved.
Test: Manual
Bug: 63526104
Change-Id: I8ee8938f3ddcd9f0ff3b1812fcae667eddaf09ab
These screens are used whenever setting or confirming the
lockscreen PIN or password. Set them to a consistent textSize (24sp)
and a consistent fontFamily.
Would have set the fontFamily in the style, but unfortunately
setInputType is called on the TextViews after inflation which blows
away the fontFamily. Instead, we set it in code right after that
call.
Change-Id: I77c3f94e2b1ce6d1f19697394c5caa09aac423b0
Fixes: 62873478
Test: manual
Move the applyThemeResource calls up from the setup wizard specific
subclasses up to the settings classes so that it will get GLIF v2
theme on devices that request it.
Test: Manual
Bug: 62906814
Change-Id: I6ff4ff8d9ed3e6090b35b4ae7197e5d01f5a61f8
- "Continue" in choose lock flows are renamed to "Next"
- "Done" in fingerprint enroll finish screen is renamed to "Next"
during setup flow.
Test: Manual
Bug: 62839648
Change-Id: I3ea77b759b654d7c1da1f7b545781c9dfd74caa3
So that setup wizard can show PIN option by default.
Test: Added Robolectric and instrumentation tests
Bug: 38509560
Change-Id: Id72744dd444b9b026ca5f28f230bae3bec254b2f
(cherry picked from commit 0f897d79f6)
When setting up fingerprint's backup screen lock, show a different
header text that says
"To use fingerprint, set {PIN/pattern/password}" instead of
"Choose your {PIN/pattern/password}".
Test: Manual. Existing tests pass
Bug: 62187833
Change-Id: If1084e64b99291a0eda63c174793b5a091ab4bae
Instead of a separate headerText view, change the header in the
GlifLayout directly.
Test: Manual. Existing tests pass
Bug: 38180862
Change-Id: I02d692870f5e2230ccae87a5ac2aee4def8f61af
- Added "Screen lock options" button in PIN screen, controlled by
extra EXTRA_SHOW_OPTIONS_BUTTON, which will create a dialog to ask
the user to choose another screen lock type.
- Extracted ScreenLockType enum and ChooseLockGenericController that
can be shared by ChooseLockGeneric and the dialog
ChooseLockTypeDialogFragment.
- The intent extra EXTRA_SHOW_OPTIONS_BUTTON will be set if
ChooseLockGeneric screen starts ChooseLockPassword /
ChooseLockPattern without asking the user. (Although the extra is
ignored by ChooseLockPattern currently)
- Fix layout alignment for the password entry field to remove the
extra 4dp padding on the sides.
Test: cd tests/robotests && mma
Bug: 35442933
Bug: 38002299
Change-Id: I877fbe08a0c05bb97175e1cbf0260ea6dbda22e2
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
