Need to make a copy of the LockscreenCredential in
onSaveInstanceState() since the credential will be
zeroized in onDestroy() while Bundle.putParcelable()
only keeps a reference of the object without any
copying.
Bug: 179108398
Test: manual
Change-Id: I090b691630f82406d1ae2f625dd2e0d578b83707
- Using GlifLayout api to set title and description
- Hide the header area for landscape mode
Bug: 179317709
Test: visual verified
1) Settings -> Security -> Screen lock -> Pattern
2) Try setting screen lock if there's no pattern
3) Rotate the screen during the settings flow and see if there's
an empty space leaving in the left side
4) Settings -> Security -> Fingerprint
5) Device will display a confirm lock pattern page
6) Rotate the screen and see if there's an empty space left
Change-Id: I16f614eceb873f40b7c48583223aedcbcbd7447d
FRP ConfirmDeviceCredentialActivity launched in initial setup flow should belong to internal flow, so it needs to set the external flag to false. It can transmit setup intent extra to the stencil library to make the screen be applied to the stencil and BC layout.
Bug: 171950236
Test: Manual test & RunSettingsGoogleRoboTests
Change-Id: Ia98d1bb4fc3a1687992b202b1e58afc1463efaf4
ConfirmLockPassword enforces that ForceVerifyPath
can only be set when caller is launching InternalActivity,
so the builder needs to launch that activity instead.
This is regressed from Idf6fcb43f7497323d089eb9c37125294e7a7f5dc
Bug: 179172552
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.password
Change-Id: I8e03fc69c4748d09f17c29edaa77594e233f79ea
When set, only enforce password requirement explicitly set device-wide.
As part of the change, restructure the code such that ChooseLockGeneric
becomes the central place for aggregating password requirements from
different parties, while ChooseLockPassword only enforces whatever
password reuirement it is told (by ChooseLockGeneric via intent extras)
Bug: 169832516
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password
Change-Id: I0acbea4819c13d4a8444c7b06928baccead18837
After applying collapsing toolbar in the Settings app, the toolbar title
will be shown in every subsetting pages. However some pages in the
security category don't need the title, like set screen lock page and
lock screen page. This CL is to disable these titles through overriding
isToolbarEnabled method.
Bug: 176883575
Test: manual test and visual verified
1) Navigate to Settings -> Security -> Screen lock ->
Pattern/PIN/Password
2) Observe and check if there is a duplicated title.
Change-Id: I6dfa4fbe1b5e2ac3582804ba1e125196f3bdba6c
Enforce a lock screen that adheres with the required complexity set by
the admin.
This is done by querying the DevicePolicyManager for the complexity set
for the given user, and merging it with the complexity from the "change
lock screen" intent (if any).
If the admin sets a higher complexity requirement than the app
triggering the lock screen change request, then the admin-set complexity
is enforced and the user is not shown information about the requesting
app.
Bug: 165573442
Test: Manually, set complexity using TestDPC and see it applies.
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password.ChooseLockGenericTest
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password.ChooseLockPasswordTest
Change-Id: If3f24f7430bdcbcd34265339f7d2a1ff82a44fc1
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
Bug: 161765592
Test: Accept/Reject/Lockout on the following
1) Owner profile
2) Managed profile with separate challenge
3) Managed profile with unified challenge
Change-Id: Ia7b670a29e9e8ee1fe65bd09965a454601a06871
This change adds the plumbing on Settings side for ConfirmLock*.
ChooseLock* will be done in a follow-up CL. The changes in this CL
are not invoked by any code path yet. This will also be integrated
in a follow-up CL.
Bug: 161765592
Perform the following with a local change to use
ChooseLockSettingsHelper#setRequestGatekeeperPassword(true)
Test: GK PW is received when setRequestGatekeeperPassword(true)
Test: GK PW + Challenge sent to GK, GK verifies and caller receives
GK HAT successfully
Change-Id: Ibd809784b5599343f34836bc5f3e709627b7f22a
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
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
Force a garbage collection and zeroize some fields after Activity finishes
Test: Goes through password change flow, then grab a heap dump via
adb shell 'am dumpheap $(pidof com.android.settings)
/data/local/tmp/settings.hprof'
And grep for password in the dump
Bug: 144537463
Change-Id: Idd0a04ada98900aeb2a6d20bb1270a4a4aec2cfd
This is a terminal case for both authentication as well as the
activity itself, so this should be safe.
Fixes: 158635014
Test: Builds
Change-Id: Ieef1ab305e6518dbc0ae34ad59d52da82895972a
On devices without PersistentDataBlock support, we should
always allow setting up password during provisioning.
Bug: 157451551
Test: make RunSettingsRoboTests
ROBOTEST_FILTER=com.android.settings.password
Test: On cuttlefish, file ACTION_SET_NET_PASSWORD before SUW completes
Change-Id: Ic7b5d99b38e6427750ce70fa7e38f7ef6054d4ad
In several circumstances, the ConfirmDeviceCredentialActivity
may be started while the device is being unlocked - particularly, when
the managed profile on the device has a separate challenge and the user
is attempting to start an activity associated with the locked, managed
profile. For example, by double-tapping a notification from the managed
profile or trying to reply to such a notification.
When the ConfirmDeviceCredentialActivity is started after the user has
entered the primary lockscreen challenge but before the keyguard is
fully dismissed, the activity may be started and immediately paused.
If the activity then calls finish() in onPause(), the biometric prompt
will disappear and the user will not have a chance to authenticate.
Fix the issue by only calling finish() in onPause() if the biometric
prompt has not been shown.
The flag indicating whether the activity is waiting for biometric
prompt or not needs to be cleared whenever the biometric prompt invokes
the callback, so that the activity will correctly call finish() if the
user does abort authentication.
Bug: 153689182
Bug: 141470517
Test: Manual, set up a work profile and double-tap a work notification
or try to Reply to a work GMail notification.
Change-Id: I9d3d3000b99d0eb4b44b90f5a0c2856db5f32144
This moves the dependency to PromptInfo, which isn't optimal but
is still much more readable / manageable
Bug: 149067920
Test: adb shell am start -a android.app.action.CONFIRM_DEVICE_CREDENTIAL
Change-Id: I7d9ba2084db76284d08f68dd2005190f06412a1e
* In Android R, the work challenge
UI was updated to the latest material
spec. The background and organization
color are no longer used and can be
removed.
Bug: 155464031
Test: Check Settings work challenge to
ensure code removal does not break
anything.
Change-Id: Ibc4dac2f47441751fde95485c223e61785f5aae8
* If organization name has been set for
a managed profile, work challenge
should display it as the header.
Bug: 155274026
Test: manual testing
Manual Testing Steps
* Set up device with managed profile
* Set organization name via TestDPC
* Go Settings > Security > Work profile security
and add a work profile lock
* Select 'Work profile lock' and verify
organization name is shown in header
Change-Id: I83209383fd2cf9179c34ccfdf8c097c379ec933e
Allows it to be used in more projects
Bug: 154161590
Test: Manually opened each setting that was impacted
Change-Id: Ife59074e5f8ffa76c2c81cca4022ca200bb59526
When unifying work profile challenge, keep the device lock
as long as it will still meet password requirement after unification.
If not, prompt the user to set a new device lock and only unify
work challenge after a compliant device lock is set.
Bug: 148630506
Fix: 149682344
Test: make RunSettingsRoboTests
ROBOTEST_FILTER='ChooseLockGenericTest|ChooseLockPasswordTest|ChooseLockPatternTest|LockUnificationPreferenceControllerTest'
Change-Id: I99cde2650902927f6a4cc7c0cc7c6016e0dc283f
- Assign metrics category to perferences at an earlier stage in
DashboardFragment for better usability.
Bug: 137559984
Test: robotest
Change-Id: Icd4185efa0e655be20c4b673a1380fa42140923f
CDCA is a transparent activity with the sole purpose of
requesting authentication. Since authentication is all drawn
by SystemUI, we should also stop this activity from drawing
the StatusBar.
Register to receive biometric system events (early user canceled),
so that we can finish() and start the activity transition
simultaneously. This fixes some navigation bar jank.
Bug: 148273355
Test: Set up a work profile, then install BiometricPromptDemo
Disable one-lock and set up a password/biometric for the
work profile. Lock/unlock screen, then open the work
profile version of the app. No status bar jank seen.
Change-Id: I54a352527ed007dcaf1bea14a51711e4022fe028
With an associated change to the UI of the BiometricPrompt credential
view, this commit preserves the current appearance of the CDC auth flow
by promoting the "details" string from the description to the subtitle
field of the prompt.
Test: Manually, using the TestDPC app
Bug: 152053691
Change-Id: If1d773f7f9a7b141520eac70a6cd64c09eb27f20
Allow LockScreenPattern to be launched in the pinning screen
If work profile lock is enabled and work app is pinned, users will get a
black/white screen on the phone. That's because Settings is prevented
from other apps launch any pages of Settings in the pinning mode.
In order to launch some pages of Settings from other apps, we add a
condition to the preventive mechanism and allow the activity inherited
from SettingsBaseActivity to override the condition to have the activity
to be launched from other apps in the pinning mode.
Bug: 137015265
Bug: 135604684
Test: manual test
Change-Id: I8070de79a83350d1658efcb19e983669dad0e673
(cherry picked from commit 077dd9b07f)
