The screens don't work as expected if they're launched in the work
profile. The reason for this is that Settings handle the user separately
with an extra inside the intent. I assume launching the actual screen in
a separate user is not supported.
Note that I've also:
1. Added a safeguard to make sure that the "active unlock" code path
only occurs in the profile parent — it seems preferrable (see
b/277877289#comment4)
2. Added the user id as an identifier on the intents lauched by the
entries. The reason we do this is to make sure the user id is taken
into account in the PendingIntent#equals implementation. This was
automatically taken care of when launching with the profile context,
but now that we launch everything in the profile parent context we
have to make sure the user id is taken into account
Bug: 278665241
Bug: 277877289
Test: manual
Change-Id: Idcaa31cd56ed64768aa8f069d30d2adeb7269099
We want to show this page as long as active unlock is enabled. The
underlying check of isAvailable checks if the appropriate biometrics are
available and updates the title accordingly.
Test: manual test, confirm combined page appears when active unlock on
Test: atest BiometricsSafetySourceTest
Bug: 264812908
Change-Id: I5da1c20d65b879751bdd615c14c2f8a71cc54d80
Settings already sends a SafetySourceIssue to Safety Center when the
user has not set a screen lock. This CL specifies the corresponding
notification for Safety Center to post for that issue.
Also specified the actionability of this issue as manual (although
this is the default so no functional change here, just for clarity).
Fix: 265799125
Bug: 260574754
Test: Manually
Change-Id: I9d579cdb8061d247e89031a5bc360f8fd5848277
Created a new MoreSecurityPrivacyFragment, a new
more_security_privacy_settings xml.
This more_security_privacy_settings xml is a created by merging
privacy_advanced_settings.xml and security_advanced_settings.xml and the
MoreSecurityPrivacyFragment is created by merging
PrivacyDashboardFragment and SecurityAdvancedSettings fragments.
Test: adb shell am start -a com.android.settings.security.MORE_SECURITY_PRIVACY_SETTINGS
Bug: b/261557620
Change-Id: I8729f4eaf25a31f91354383e7b6cb5e0fc7df976
Settings uses a system of intent extras to open subsettings pages. When
PendingIntents are created from these Intents, the system does not think
they are unique as extras are not included in this equality check. So
only one of them is likely to work.
A unique request code can be used to distinguish between them.
Bug: 238605613
Test: atest LockScreenSafetySourceTest
Change-Id: Ia59197eeb86e988d9ffbb86caff4bbda7b30f059
- use correct severity enum for issues
- update biomterics on lockscreen change
- clean up some nearby tests to use eq matcher instead of captor
Test: SettingsUnitTests
Test: Manually tested
Bug: 223170514
Bug: 222338885
Change-Id: I4e28a418473cbe7cd5d75daf0d62776654fa7917
