Since the SetupChooseLockPattern include header icon
header title, header sub-title, pattern state description,
LockPatternView and FooterBar, there was a limited room
for LockPatternView especially in the confirm steps which
both header title and pattern description occupy 2 lines space.
Hance the PatternView size used to inconsistence in-between
1st draw and 2nd confirm draw, besides it's visual looks
jumping and small on some device which have smaller display.
This solution includes 3 changes:
1. Organized the pattern view message to leverage
header sub-title view, then we can resever more space.
(Set minHeight=2 for sub-title)
2. Set screen_lock_options button visibilty to GONE when
the stage in 2nd confirmation.(Previously it's INVISIBLE
and reserve additional space)
3. Let LockPatternView align bottom of FrameLayout to prevent
the view juming and flicker.
4. Clean up unused forAnyBiometric flag and code.
5. GlifLayout.getDescriptionTextView() == mHeaderView
Need setDescriptionText() to make the view from GONE -> VISIBLE
6. Polish the stage flow and ensure IntroductionStage show
correct message
7. Add ChooseLockPattern into embeded activity white list
Force show ChooseLockPattern in fullscreen in case the Pattern
view truncated in `NeedToConfirmStage` where the title showing
2 lines and push pattern view down, and get bad UX in the
device which integrate a shorter display.
8. Add test cases for all stage and polish legacy test code.
Test: make RunSettingsRoboTests ROBOTEST_FILTER= \
"com.android.settings.password.SetupChooseLockPatternTest"
Test: make RunSettingsRoboTests ROBOTEST_FILTER= \
"com.android.settings.password.ChooseLockPatternTest"
Bug: 249974175
Bug: 260027850
Change-Id: I868af9b14ba99af5d78a05f6c2a570ccc07aea15
Change <one> to <1> in string res file, and update related java files.
Test: Update, existing test still pass.
bug: 199230342
Change-Id: Idd0ba3c6adc060da21574d98f8ed765fae00cef8
Support for Full Disk Encryption was removed in Android 13, since now
File Based Encryption is always used instead. It turns out that I
missed a fairly large chunk of obsolete code: EncryptionInterstitial,
which is the screen that asks whether the device will require the
primary user's lockscreen credential when it starts up. This used to be
shown when setting the primary user's lockscreen credential, to
determine whether the full-disk encryption key would be tied to that
lockscreen credential or not. But now it's unused code.
This CL removes all this unused code.
This should not change any behavior, with one very minor exception:
Settings will no longer explicitly set the REQUIRE_PASSWORD_TO_DECRYPT
setting to 0 whenever the primary user's lockscreen credential is
changed. (This happened in SaveChosenLockWorkerBase.) This setting is
a @SystemApi, but it no longer has any meaning, since it is never set to
1 anymore. If there is a reason to keep it explicitly set to 0, instead
of unset, we should make LockSettingsService in system_server set it.
Test: Went through SUW, set a PIN, cleared the PIN, set a PIN again (all
using the UI). Nothing unusual seen.
Bug: 208476087
Change-Id: I039cc7a284e3f43e1e284970a5869958c909d1b7
Temporary remove the redundant padding from ChooseLockPattern and
ConfirmLockPattern as a workaround solution.
Bug: 243008023
Test: make and check visual on foldable
Test: make RunSettingsRoboTests
Change-Id: I0baa2be65b797ca70f9de43bc8c5e3187a2d28ad
Since legacy hideSoftInputFromWindow() for IME hiding animation
will be scheduled on the focus app's UI thread, so if activity
transition has running the animation on UI thread, the
IME hiding animation will be delayed until the animation finish.
Make sure calling WindowInsetsController#hide(ime()) before starting
activity transition to prevent flicker issue.
Bug: 204732064
Test: adb shell am start -a android.settings.BIOMETRIC_ENROLL
Test: SUW set/confirm pin and move to setup fingerprint(back and forth)
Test: make -j RunSettingsRoboTests
Change-Id: I33278dd5c993c0bc299ebd065011e5d18c7242e0
Prevent ChooseLockPassword and ChooseLockPatten being projected to
remote views, add FLAG_SECURE for these screens.
Bug: 179725730
Test: Check these 2 screens not projected to chromecast
Test: robo test for SetupChooseLockPatternTest ChooseLockPatternTest
SetupChooseLockPasswordTest ChooseLockPasswordTest
Change-Id: I7449a24427c966c1aa4280a7b7e7e70b60997cca
Root cause:
- The new added description TextView is too large
- sud_layout_description was add in sud_layout_content
instead of sud_layout_header.
Solution:
- Set string lockpassword_choose_your_pattern_description
to GlifLayout as it's description.(Header description)
Bug: 233666752
Fixes 239892091
Test: manual in setup flow, check choose lock pattern layouts
showing expectedly on both phone & tablet
Test: make RunSettingsRoboTests
Change-Id: Iabe503066434f8983dffb88d1c93f2bbf773b860
Since emulated FBE is no longer supported, isFileEncryptedNativeOnly()
and isFileEncryptedNativeOrEmulated() are the same as the new method
isFileEncrypted(). Replace all calls to these deprecated methods in
this repository with isFileEncrypted().
Bug: 232458753
Change-Id: I95beea86ef771396c2e08f2d6a643fdc629ad89f
Links are not allowed in footer preference title now, so splitting the
string in to title text and learn more text for set a separate work
lock message
Bug: 206083998
Bug: 231296099
Test: NA
Change-Id: Ic19b4b7a9c8239726b1d53cecad1e341458610cb
To distinguish the requirement between all numeric
and not all numeric when COMPLEXITY_HIGH.
Fix: 227149118
Fix: 173167839
Test: manual & robolectric
Change-Id: I1f682625d8e86963218dda43b626a9e55d169fb3
Many multi-user strings were duplicated between SettingsLib, Settings,
System UI and Car projects. This CL removes those duplicates.
List of singularized strings: "Guest", "Remove guest", "Add user",
"Remove guest?", "Too many incorrect attempts...."
Bug: 191386817
Test: NA
Change-Id: I8d9629a1a9628cab9f049df84f706bd04ee75cc2
This intent data was only used by CryptKeeperSettings, which has been
removed. This is also one of the only remaining users of the
StorageManager.CRYPT_TYPE_* constants which were only ever intended to
be used with vold's Full Disk Encryption APIs, which have been removed.
Bug: 208476087
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.password
(No regressions seen; 2 tests fail both before and after.)
Change-Id: Id6e2c0f5ecc79f7372b29393e66ffbd66d52d7a2
With FDE (Full Disk Encryption), secure start-up (i.e. requiring a PIN /
pattern / password to boot the device) was incompatible with
accessibility services. Thus, the accessibility settings would ask the
user to disable secure start-up when enabling an accessibility service.
Now that FDE support has been removed in favor of FBE (File Based
Encryption), this is no longer necessary. Remove it.
Bug: 208476087
Change-Id: I5f6e512f223df63e1b4d1c181fc8b3fe683dcd5f
(cherry picked from commit b4060ef65b)
Merged-In: I5f6e512f223df63e1b4d1c181fc8b3fe683dcd5f
With FDE (Full Disk Encryption), secure start-up (i.e. requiring a PIN /
pattern / password to boot the device) was incompatible with
accessibility services. Thus, the accessibility settings would ask the
user to disable secure start-up when enabling an accessibility service.
Now that FDE support has been removed in favor of FBE (File Based
Encryption), this is no longer necessary. Remove it.
Bug: 208476087
Change-Id: I5f6e512f223df63e1b4d1c181fc8b3fe683dcd5f
(cherry picked from commit b4060ef65b)
Merged-In: I5f6e512f223df63e1b4d1c181fc8b3fe683dcd5f
androidx.appcompat.app.AlertDialog will cause postiveButton and negativeButton become too close when the texts are longer.
Bug: 216442969
Change-Id: I39e84c1007c817399902034e853b2aeee1343adc
Test: visual verify
androidx.appcompat.app.AlertDialog will cause postiveButton and negativeButton become too close when the texts are longer.
Bug: 216442969
Change-Id: I39e84c1007c817399902034e853b2aeee1343adc
Test: visual verify
This property was copying the HAPTIC_FEEDBACK_ENABLED deprecated user
setting. Starting from Android T this setting will be applied by the
Vibrator service for vibration with USAGE_TOUCH.
Bug: 185351540
Test: manual
Change-Id: Ifeee5a56b80a04bcf605defe9a310374dce68146
With FDE (Full Disk Encryption), secure start-up (i.e. requiring a PIN /
pattern / password to boot the device) was incompatible with
accessibility services. Thus, the accessibility settings would ask the
user to disable secure start-up when enabling an accessibility service.
Now that FDE support has been removed in favor of FBE (File Based
Encryption), this is no longer necessary. Remove it.
Bug: 208476087
Change-Id: I5f6e512f223df63e1b4d1c181fc8b3fe683dcd5f
